From sunilkumarsinha9@gmail.com Mon Apr 2 04:46:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CA821F889D for ; Mon, 2 Apr 2012 04:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXLOavnlu1qo for ; Mon, 2 Apr 2012 04:46:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8181321F889B for ; Mon, 2 Apr 2012 04:46:05 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1203613yhk.31 for ; Mon, 02 Apr 2012 04:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JVKjtxVuPjimbjIYn5f5gG6QljSpl6imEH1vInsvQJg=; b=KFLr01PUgky7rvT7tpGg6qT/iUZLafCO1hVcX4C9jOGvXXRalkWhc4dZZggAYHD+pw DIHIQii2KU30C+3bYdvMLieCFzBfq5+2hGkipQCSVVUc27y//xB+VlW9vtWYjsUooEvn 0kjX4Wm4v+j1IePccOVXuzo5GL7NBUdD5gg6bCPl2Ay7iVBH8pAWWdUuwBGA/VCRaJpD HQ9LazUCWMS4sUq/Uxim6OIB043JVVZIf3JLrcSkkJFdvjf8HrCbXC9DRgICyCf43lBP lGSu997nOj6um/lYglRcqYt3r4dRa4jtV5pxFcnA3ruuWtgXCS+/XCnAy/9DA3gR7M74 nXOQ== MIME-Version: 1.0 Received: by 10.60.28.137 with SMTP id b9mr11787223oeh.57.1333367164997; Mon, 02 Apr 2012 04:46:04 -0700 (PDT) Received: by 10.182.51.201 with HTTP; Mon, 2 Apr 2012 04:46:04 -0700 (PDT) In-Reply-To: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> Date: Mon, 2 Apr 2012 17:16:04 +0530 Message-ID: From: sunil sinha To: Mary Barnes , Cullen Jennings , Gonzalo Camarillo , dispatch@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c4ae39917c04bcb0bc62 X-Mailman-Approved-At: Mon, 02 Apr 2012 06:44:54 -0700 Cc: amardeep sinha , Subhrajyoti De Subject: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:48:42 -0000 --e89a8ff1c4ae39917c04bcb0bc62 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear All, I have just made revision 3 of =91draft-sinha-dispatch-sip-continuation-option=92 available following offl= ine discussion. Biggest addition is the new section 7.6 and 7.7 which aims to further inter-working scenario. You can find the HTML formatted version here: http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 I am looking forward to hearing about any concerns you may have. Thanks & Regards, sunil kumar sinha ---------- Forwarded message ---------- From: Date: Mon, Apr 2, 2012 at 3:41 PM Subject: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt To: sunilkumarsinha9@gmail.com Cc: sinha.amardeep@gmail.com, de_subhrajyoti@yahoo.co.uk A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt has been successfully submitted by Sunil Kumar Sinha and posted to the IETF repository. Filename: draft-sinha-dispatch-sip-continuation-option Revision: 03 Title: The Continue Header Field for the Session Initiation Protocol (SIP) Creation date: 2012-04-02 WG ID: Individual Submission Number of pages: 23 Abstract: Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favorable state to receive a call or not. This document defines an optional tag "continue" and a header "Continue" to address the purpose. The "Continue" header field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. The IETF Secretariat --e89a8ff1c4ae39917c04bcb0bc62 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear All,

I have just made revision 3 of =91draft-sinha-dispatch-sip-continuation-opt= ion=92 available following offline discussion. Biggest addition is the new section 7.6 and 7= .7 which aims to further inter-working scenario.

You can find the HTML formatted version here:
http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuatio= n-option-03


I am looking forward to hearing about any concerns you may have.

Thanks & Regards,
sunil kumar sinha





---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for = draft-sinha-dispatch-sip-continuation-option-03.txt
To: sunilkumarsinha9@gmail.com
Cc: sinha.amardeep@gmail.com, de_subhrajyoti@yahoo.co.uk


A new version of I-D, draft-sinha-dispatch-sip-continuation-option-= 03.txt has been successfully submitted by Sunil Kumar Sinha and posted to t= he IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sinha-dispatch-sip-continuation-option
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 The Continue Header Field for the Session Initia= tion Protocol (SIP)
Creation date: =A0 2012-04-02
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 23

Abstract:
=A0 Before placing a call, it is quite often useful for the Caller to
=A0 know whether a Callee is in favorable state to receive a call or
=A0 not. This document defines an optional tag &quot;continue&quot= ; and a header
=A0 &quot;Continue&quot; to address the purpose. =A0The &quot;= Continue&quot; header field is
=A0 to confirm the session continuity with the Callee from the Caller
=A0 after an option for session continuity is placed by the Callee based =A0 on the unfavorable state of the Callee. =A0This functionality is neede= d
=A0 to resolve the unwillingness of the Callee to receive any call. An
=A0 option is given to the Callee by the Service Provider or by the
=A0 Handset Manufacturer or by the Carrier to establish this requirement.<= br>




The IETF Secretariat

--e89a8ff1c4ae39917c04bcb0bc62-- From Ranjit.Avasarala@Polycom.com Mon Apr 2 07:52:45 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518D621F85ED for ; Mon, 2 Apr 2012 07:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTfRWeV-b3xG for ; Mon, 2 Apr 2012 07:52:42 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id EEBEC21F85E6 for ; Mon, 2 Apr 2012 07:52:20 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Mon, 2 Apr 2012 22:52:18 +0800 From: "Avasarala, Ranjit" To: sunil sinha , "Barnes, Mary" , Cullen Jennings , Gonzalo Camarillo , "dispatch@ietf.org" Date: Mon, 2 Apr 2012 22:50:16 +0800 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Thread-Index: Ac0Q1tMzpnRw7b2tRlecUok9N/T31AACRdLg Message-ID: <1F2A2C70609D9E41844A2126145FC09804BC2DC3CA@HKGMBOXPRD22.polycom.com> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3CAHKGMBOXPRD22p_" MIME-Version: 1.0 Cc: amardeep sinha , Subhrajyoti De Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:52:45 -0000 --_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3CAHKGMBOXPRD22p_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sunil I have a basic query - if a callee is unwilling to receive a particular cal= l, he or she can cancel the call. so in that case why is a new header "Cont= inue" required? isn't it a unnecessary overhead? Regards Ranjit ________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of su= nil sinha [sunilkumarsinha9@gmail.com] Sent: Monday, April 02, 2012 5:16 PM To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.org Cc: amardeep sinha; Subhrajyoti De Subject: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-= sip-continuation-option-03.txt Dear All, I have just made revision 3 of =91draft-sinha-dispatch-sip-continuation-opt= ion=92 available following offline discussion. Biggest addition is the new = section 7.6 and 7.7 which aims to further inter-working scenario. You can find the HTML formatted version here: http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 I am looking forward to hearing about any concerns you may have. Thanks & Regards, sunil kumar sinha ---------- Forwarded message ---------- From: > Date: Mon, Apr 2, 2012 at 3:41 PM Subject: New Version Notification for draft-sinha-dispatch-sip-continuation= -option-03.txt To: sunilkumarsinha9@gmail.com Cc: sinha.amardeep@gmail.com, de_subhrajyo= ti@yahoo.co.uk A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt h= as been successfully submitted by Sunil Kumar Sinha and posted to the IETF = repository. Filename: draft-sinha-dispatch-sip-continuation-option Revision: 03 Title: The Continue Header Field for the Session Initiation Proto= col (SIP) Creation date: 2012-04-02 WG ID: Individual Submission Number of pages: 23 Abstract: Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favorable state to receive a call or not. This document defines an optional tag "continue" and a hea= der "Continue" to address the purpose. The "Continue" he= ader field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. The IETF Secretariat --_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3CAHKGMBOXPRD22p_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Sunil
 
I have a basic query - if a callee is u= nwilling to receive a particular call, he or she can cancel the call. so in= that case why is a new header "Continue" required? isn't it a un= necessary overhead?
 
 
Regards
Ranjit
 
From: dispatch-bo= unces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of sunil sinha [sunilk= umarsinha9@gmail.com]
Sent: Monday, April 02, 2012 5:16 PM
To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.= org
Cc: amardeep sinha; Subhrajyoti De
Subject: [dispatch] Fwd: New Version Notification for draft-sinha-di= spatch-sip-continuation-option-03.txt

Dear All,

I have just made revision 3 of =91draft-sinha-dispatch-sip-continuation-opt= ion=92 available following offline discussion. Biggest addition is the new = section 7.6 and 7.7 which aims to further inter-working scenario.

You can find the HTML formatted version here:
http://tools.ietf.org/html/draft-sinha-dispat= ch-sip-continuation-option-03


I am looking forward to hearing about any concerns you may have.

Thanks & Regards,
sunil kumar sinha





---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for draft-sinha-dispatch-sip-continuation= -option-03.txt
To: sunilkumarsinha9@gmail.co= m
Cc: sinha.amardeep@gmail.com, de_subhrajyoti@yahoo.co.uk


A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt h= as been successfully submitted by Sunil Kumar Sinha and posted to the IETF = repository.

Filename:        draft-sinha-dispatch-sip-continuation-= option
Revision:        03
Title:           The Continue Header Field for the= Session Initiation Protocol (SIP)
Creation date:   2012-04-02
WG ID:           Individual Submission
Number of pages: 23

Abstract:
  Before placing a call, it is quite often useful for the Caller to   know whether a Callee is in favorable state to receive a call or
  not. This document defines an optional tag &quot;continue&qu= ot; and a header
  &quot;Continue&quot; to address the purpose.  The &= quot;Continue&quot; header field is
  to confirm the session continuity with the Callee from the Caller   after an option for session continuity is placed by the Callee based=
  on the unfavorable state of the Callee.  This functionality is = needed
  to resolve the unwillingness of the Callee to receive any call. An   option is given to the Callee by the Service Provider or by the
  Handset Manufacturer or by the Carrier to establish this requirement= .





The IETF Secretariat

--_000_1F2A2C70609D9E41844A2126145FC09804BC2DC3CAHKGMBOXPRD22p_-- From pkyzivat@alum.mit.edu Mon Apr 2 10:47:19 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52BA21F85B4 for ; Mon, 2 Apr 2012 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNYztlEicaNL for ; Mon, 2 Apr 2012 10:47:19 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC75821F856A for ; Mon, 2 Apr 2012 10:47:18 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id t5jA1i0020QuhwU5A5nKSn; Mon, 02 Apr 2012 17:47:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id t5nJ1i01p07duvL3N5nJ72; Mon, 02 Apr 2012 17:47:19 +0000 Message-ID: <4F79E624.7070200@alum.mit.edu> Date: Mon, 02 Apr 2012 19:47:16 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:47:20 -0000 Sunil, Looking back, I see that you had replied to my comments on the earlier version of this draft and I never responded. To summarize, the problem I have with this draft is that you leap to a particular mechanism to solve a problem without having justified why that solution is better than other possible solutions to the same problem. And also without having sufficiently motivated people about why this is a problem that needs solving. Your latest update, with the ISDN interoperability example, suggests that ISDN interoperability might be driving the way you frame the problem. If so it would be good for you to explain that. It still seems to me that this could be solved with less new mechanism. The Priority header, plus an existing response (e.g. 403 Forbidden plus an exiting or new Warning header) or a new response code. Thanks, Paul On 4/2/12 1:46 PM, sunil sinha wrote: > Dear All, > > I have just made revision 3 of > ‘draft-sinha-dispatch-sip-continuation-option’ available following > offline discussion. Biggest addition is the new section 7.6 and 7.7 > which aims to further inter-working scenario. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 > > > I am looking forward to hearing about any concerns you may have. > > Thanks & Regards, > sunil kumar sinha > > > > > > ---------- Forwarded message ---------- > From: ** > > Date: Mon, Apr 2, 2012 at 3:41 PM > Subject: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > To: sunilkumarsinha9@gmail.com > Cc: sinha.amardeep@gmail.com , > de_subhrajyoti@yahoo.co.uk > > > A new version of I-D, > draft-sinha-dispatch-sip-continuation-option-03.txt has been > successfully submitted by Sunil Kumar Sinha and posted to the IETF > repository. > > Filename: draft-sinha-dispatch-sip-continuation-option > Revision: 03 > Title: The Continue Header Field for the Session Initiation > Protocol (SIP) > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > Before placing a call, it is quite often useful for the Caller to > know whether a Callee is in favorable state to receive a call or > not. This document defines an optional tag "continue" and a > header > "Continue" to address the purpose. The "Continue" > header field is > to confirm the session continuity with the Callee from the Caller > after an option for session continuity is placed by the Callee based > on the unfavorable state of the Callee. This functionality is needed > to resolve the unwillingness of the Callee to receive any call. An > option is given to the Callee by the Service Provider or by the > Handset Manufacturer or by the Carrier to establish this requirement. > > > > > > The IETF Secretariat > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From amardeep_sinha@rediffmail.com Sun Apr 8 22:17:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF2C21F84F1 for ; Sun, 8 Apr 2012 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca9ozsdACYA1 for ; Sun, 8 Apr 2012 22:17:49 -0700 (PDT) Received: from rediffmail.com (f5mail-224-155.rediffmail.com [114.31.224.155]) by ietfa.amsl.com (Postfix) with SMTP id ED6FD21F84E6 for ; Sun, 8 Apr 2012 22:17:47 -0700 (PDT) Received: (qmail 4403 invoked by uid 510); 9 Apr 2012 05:17:43 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=bQ7+ut3fYIQpLB7cpIZ8OynwhIkB1HvtnM7u4cmgww17D5x7OWmpHZcp5dZo6TklaTrhFlirQ37IzoYujiENCCvXMJbW7rlfrdY8ZKZkGZZKYgFIxBwFBu17pbIRCfM4db0B4+u0N3NOGHvj22foutwIXlLKCRUntsVjnPg0nX4= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150206.4F8270F8.00D6,ss=1,re=-2.300,fgs=0 X-REDF-OSEN: amardeep_sinha@rediffmail.com Date: 9 Apr 2012 05:17:42 -0000 MIME-Version: 1.0 To: , , , , , Received: from unknown 72.163.217.103 by rediffmail.com via HTTP; 09 Apr 2012 05:17:42 -0000 Message-ID: <1333947169.S.15724.19553.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 584, 342.f5-224-169.1333948662.10508@webmail.rediffmail.com> in-reply-to: <1333378370.S.12220.6621.H.WUF2YXNhcmFsYSxSYW5qaXQAUmU6IFtkaXNwYXRjaF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24_.RU.rfs221, rfs221, 214, 727.f5-224-147.1333947169.27689@webmail.rediffmail.com> From: "amar deep" Content-Type: multipart/alternative; boundary="=_cfe320ac3e6d05e95d6d67f0d04c8ca7" Subject: Re: [dispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for=09draft-?= =?utf-8?q?sinha-dispatch-sip-continuation-option-03=2Etxt?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 05:17:50 -0000 --=_cfe320ac3e6d05e95d6d67f0d04c8ca7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Ranjit, The main idea behind having CONTINUE header is to make call-setup successful, as far as possible, beyond time-zone boundaries & other feature setting (like DnD,non-availability presence status, etc). Call should not get BLOCKED/FAIL becz of these VoIP features, unless and until callee intentionally wants not to proceed with call-setup from an incoming call. Thanks, Amardeep -- Original Message -- > > From: "Avasarala, Ranjit" Ranjit.Avasarala@Polycom.com > To: sunil sinha sunilkumarsinha9@gmail.com, "Barnes, Mary" Mary.Barnes@Polycom.com, Cullen Jennings fluffy@cisco.com, Gonzalo Camarillo gonzalo.camarillo@ericsson.com, "dispatch@ietf.org" dispatch@ietf.org > Cc: amardeep sinha sinha.amardeep@gmail.com, Subhrajyoti De de_subhrajyoti@yahoo.co.uk > Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt FollowRediff Deal ho jaye!to get exciting offers in your city everyday. Hi Sunil I have a basic query - if a callee is unwilling to receive a particular call, he or she can cancel the call. so in that case why is a new header "Continue" required? isn't it a unnecessary overhead? Regards Ranjit From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of sunil sinha [sunilkumarsinha9@gmail.com] Sent: Monday, April 02, 2012 5:16 PM To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.org Cc: amardeep sinha; Subhrajyoti De Subject: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Dear All, I have just made revision 3 of ďż˝draft-sinha-dispatch-sip-continuation-optionďż˝ available following offline discussion. Biggest addition is the new section 7.6 and 7.7 which aims to further inter-working scenario. You can find the HTML formatted version here: http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 I am looking forward to hearing about any concerns you may have. Thanks & Regards, sunil kumar sinha ---------- Forwarded message ---------- From: Date: Mon, Apr 2, 2012 at 3:41 PM Subject: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt To: sunilkumarsinha9@gmail.com Cc: sinha.amardeep@gmail.com, de_subhrajyoti@yahoo.co.uk A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt has been successfully submitted by Sunil Kumar Sinha and posted to the IETF repository. Filename: draft-sinha-dispatch-sip-continuation-option Revision: 03 Title: The Continue Header Field for the Session Initiation Protocol (SIP) Creation date: 2012-04-02 WG ID: Individual Submission Number of pages: 23 Abstract: Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favorable state to receive a call or not. This document defines an optional tag "continue" and a header "Continue" to address the purpose. The "Continue" header field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. The IETF Secretariat _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Amar --=_cfe320ac3e6d05e95d6d67f0d04c8ca7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Ranjit,

The main idea behind having CONTINUE header is to make call-setup successfu= l, as far as possible, beyond time-zone boundaries & other feature setting = (like DnD,non-availability presence status, etc).

Call should not get BLOCKED/FAIL becz of these VoIP features, unless and un= til callee intentionally wants not to proceed with call-setup from an incom= ing call.

Thanks,
Amardeep


-- Original Message --
>

>
From: "Avasarala, Ranjit" Ranjit.Avasarala@Polycom.com
>
To: sunil sinha sunilkumarsinha9@gmail.com, "Barnes, Mary" Mary.Barnes@Poly= com.com, Cullen Jennings fluffy@cisco.com, Gonzalo Camarillo gonzalo.camari= llo@ericsson.com, "dispatch@ietf.org" dispatch@ietf.org
>
Cc: amardeep sinha sinha.amardeep@gmail.com, Subhrajyoti De de_subhrajyoti@= yahoo.co.uk
>
Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispa= tch-sip-continuation-option-03.txt


FollowRediff Deal ho jaye!to get exciting offers in your city everyday.







Hi Sunil

I have a basic query - if a callee is unwilling to receive a particular cal= l, he or she can cancel the call. so in that case why is a new header "Cont= inue" required? isn't it a unnecessary overhead?



Regards
Ranjit




From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of su= nil sinha [sunilkumarsinha9@gmail.com]

Sent: Monday, April 02, 2012 5:16 PM

To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.org

Cc: amardeep sinha; Subhrajyoti De

Subject: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-= sip-continuation-option-03.txt






Dear All,



I have just made revision 3 of =EF=BF=BDdraft-sinha-dispatch-sip-continuati= on-option=EF=BF=BD available following offline discussion. Biggest addition= is the new section 7.6 and 7.7 which aims to further inter-working scenari= o.




You can find the HTML formatted version here:

http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03<= br />

I am looking forward to hearing about any concerns you may have.



Thanks & Regards,

sunil kumar sinha








---------- Forwarded message ----------

From:

Date: Mon, Apr 2, 2012 at 3:41 PM

Subject: New Version Notification for draft-sinha-dispatch-sip-continuation= -option-03.txt

To: sunilkumarsinha9@gmail.com

Cc: sinha.amardeep@gmail.com,
de_subhrajyoti@yahoo.co.uk





A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt h= as been successfully submitted by Sunil Kumar Sinha and posted to the IETF = repository.



Filename: draft-sinha-dispatch-sip-continuation-option

Revision: 03

Title: The Continue Header Field for the Session Initiation Protocol (= SIP)

Creation date: 2012-04-02

WG ID: Individual Submission

Number of pages: 23



Abstract:

Before placing a call, it is quite often useful for the Caller to

know whether a Callee is in favorable state to receive a call or

not. This document defines an optional tag "continue" and a head= er

"Continue" to address the purpose. The "Continue" head= er field is

to confirm the session continuity with the Callee from the Caller

after an option for session continuity is placed by the Callee based

on the unfavorable state of the Callee. This functionality is needed

to resolve the unwillingness of the Callee to receive any call. An

option is given to the Callee by the Service Provider or by the

Handset Manufacturer or by the Carrier to establish this requirement.











The IETF Secretariat








_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



Amar

Follow Rediff= Deal ho jaye! to get exciting offers in your city = everyday.
--=_cfe320ac3e6d05e95d6d67f0d04c8ca7-- From amardeep_sinha@rediffmail.com Sun Apr 8 22:22:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273221F8534 for ; Sun, 8 Apr 2012 22:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, J_CHICKENPOX_42=0.6, SARE_SUB_ENC_UTF8=0.152, SARE_URGBIZ=0.725, UNPARSEABLE_RELAY=0.001, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+DPUjp6JZC6 for ; Sun, 8 Apr 2012 22:21:58 -0700 (PDT) Received: from rediffmail.com (f5mail-224-131.rediffmail.com [114.31.224.131]) by ietfa.amsl.com (Postfix) with SMTP id E0FAE21F84B5 for ; Sun, 8 Apr 2012 22:21:56 -0700 (PDT) Received: (qmail 4792 invoked by uid 510); 9 Apr 2012 05:21:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=GDMNgSrSVGj6fj0Suv04H0U4RxFXv4wkFHQqRG0D+f4ABYixhRwwPIaqehoUEfWEJFfjGIVfJp7BBB+9GF6NA25ZzaZmjgtU9gJMcA2wbcLjjfaH/eTjm/7l39tIiayoJCcQyhEfOqp2qPNbo/Stui9/j4Hk5ihMawDo/hi9zIo= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150201.4F8271F1.018B,ss=1,re=-2.300,fgs=0 X-REDF-OSEN: amardeep_sinha@rediffmail.com Date: 9 Apr 2012 05:21:53 -0000 MIME-Version: 1.0 To: , , Received: from unknown 72.163.217.103 by rediffmail.com via HTTP; 09 Apr 2012 05:21:52 -0000 Message-ID: <1333947130.S.10083.16336.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 401, 114.f5-224-169.old.1333948912.23738@webmail.rediffmail.com> in-reply-to: <1333388849.S.7212.7312.H.TlBhdWwgS3l6aXZhdABSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I_.RU.rfs223, rfs223, 865, 19.f5-224-103.1333947130.27689@webmail.rediffmail.com> From: "amar deep" Content-Type: multipart/alternative; boundary="=_73d8d3c008554899798ee632c569c38a" Subject: Re: [dispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-si?= =?utf-8?q?nha-dispatch-sip-continuation-option-03=2Etxt?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 05:22:00 -0000 --=_73d8d3c008554899798ee632c569c38a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Paul, Problem : -REQ-1: Callee wants no urgent call for him should get rejected when he set DnD status =ON, & he fail to notice beep/flash over the phone. -REQ-2: Caller wants call to get connected only if callee is free/available – for normal/urgent/emergency call -REQ-3: Caller don’t wants call to get connected to Callee when is BUSY – for Normal call -REQ-4: Caller wants call to get connected what so ever is state of callee is – for urgent/emergency call Problem-Solution justification with Continue -Why problem need to be solved: -Based on call type(normal/urgent/emergency), caller can make decision to go with call setup or not -Based on callee status, caller can make decision to go with call setup or not -Decision of have call setup successful based on call priority is vested within Caller decision not on feature configuration Using Priority header: -Using Priority headers is not run time bases, its depends on call service and pre-configured call setting -Initial request from caller is MARKED if it’s a high priority call or not – mainly addressing emergency situation.The priority header filed mainly address to “resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end system resources and SIP proxy resources. “. -It doesn’t address above Requirement/problem, wherein call is made high-priority based on callee availability/willingness and caller decision about call catergory based on call-type Using 403 Forbidden /or New Response Code: -For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX, make call discontinue irrespective of call-type urgency normal/urgent/emergency -Response code of 3XX, 4XX, 5XX & 6XX category – don’t give option to caller to make decision for call continuation or for termination ISDN interoperability: -This section is added at 7.6 and 7.7 section of the draft document, to state that this feature is not limited only from VoIP call -This feature proposed within the draft document, works across network type as well. Thanks, Amardeep -- Original Message -- > > From: Paul Kyzivat pkyzivat@alum.mit.edu > To: dispatch@ietf.org > Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt FollowRediff Deal ho jaye!to get exciting offers in your city everyday. Sunil, Looking back, I see that you had replied to my comments on the earlier version of this draft and I never responded. To summarize, the problem I have with this draft is that you leap to a particular mechanism to solve a problem without having justified why that solution is better than other possible solutions to the same problem. And also without having sufficiently motivated people about why this is a problem that needs solving. Your latest update, with the ISDN interoperability example, suggests that ISDN interoperability might be driving the way you frame the problem. If so it would be good for you to explain that. It still seems to me that this could be solved with less new mechanism. The Priority header, plus an existing response (e.g. 403 Forbidden plus an exiting or new Warning header) or a new response code. Thanks, Paul On 4/2/12 1:46 PM, sunil sinha wrote: > Dear All, > > I have just made revision 3 of > �draft-sinha-dispatch-sip-continuation-option� available following > offline discussion. Biggest addition is the new section 7.6 and 7.7 > which aims to further inter-working scenario. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 > > > I am looking forward to hearing about any concerns you may have. > > Thanks & Regards, > sunil kumar sinha > > > > > > ---------- Forwarded message ---------- > From: ** > Date: Mon, Apr 2, 2012 at 3:41 PM > Subject: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > To: sunilkumarsinha9@gmail.com > Cc: sinha.amardeep@gmail.com , > de_subhrajyoti@yahoo.co.uk > > > A new version of I-D, > draft-sinha-dispatch-sip-continuation-option-03.txt has been > successfully submitted by Sunil Kumar Sinha and posted to the IETF > repository. > > Filename: draft-sinha-dispatch-sip-continuation-option > Revision: 03 > Title: The Continue Header Field for the Session Initiation > Protocol (SIP) > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > Before placing a call, it is quite often useful for the Caller to > know whether a Callee is in favorable state to receive a call or > not. This document defines an optional tag "continue" and a > header > "Continue" to address the purpose. The "Continue" > header field is > to confirm the session continuity with the Callee from the Caller > after an option for session continuity is placed by the Callee based > on the unfavorable state of the Callee. This functionality is needed > to resolve the unwillingness of the Callee to receive any call. An > option is given to the Callee by the Service Provider or by the > Handset Manufacturer or by the Carrier to establish this requirement. > > > > > > The IETF Secretariat > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Amar --=_73d8d3c008554899798ee632c569c38a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Paul,

Problem :
-REQ-1: Callee wants no urgent call for him should get rejected when he set= DnD status =3DON, & he fail to notice beep/flash over the phone.
-REQ-2: Caller wants call to get connected only if callee is free/available= =E2=80=93 for normal/urgent/emergency call
-REQ-3: Caller don=E2=80=99t wants call to get connected to Callee when is = BUSY =E2=80=93 for Normal call
-REQ-4: Caller wants call to get connected what so ever is state of callee = is =E2=80=93 for urgent/emergency call

Problem-Solution justification with Continue -Why problem need to be solved= :
-Based on call type(normal/urgent/emergency), caller can make decision to g= o with call setup or not
-Based on callee status, caller can make decision to go with call setup or = not
-Decision of have call setup successful based on call priority is vested wi= thin Caller decision not on feature configuration

Using Priority header:
-Using Priority headers is not run time bases, its depends on call service = and pre-configured call setting
-Initial request from caller is MARKED if it=E2=80=99s a high priority call= or not =E2=80=93 mainly addressing emergency situation.The priority header= filed mainly address to =E2=80=9Cresources that may become scarce and cong= ested during emergencies. These resources include gateway resources, circui= t-switched network resources, IP network resources, receiving end system re= sources and SIP proxy resources. =E2=80=9C.
-It doesn=E2=80=99t address above Requirement/problem, wherein call is made= high-priority based on callee availability/willingness and caller decision= about call catergory based on call-type

Using 403 Forbidden /or New Response Code:
-For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX, mak= e call discontinue irrespective of call-type urgency normal/urgent/emergen= cy
-Response code of 3XX, 4XX, 5XX & 6XX category =E2=80=93 don=E2=80=99t give= option to caller to make decision for call continuation or for termination=

ISDN interoperability:
-This section is added at 7.6 and 7.7 section of the draft document, to sta= te that this feature is not limited only from VoIP call
-This feature proposed within the draft document, works across network type= as well.

Thanks,
Amardeep

-- Original Message --
>

>
From: Paul Kyzivat pkyzivat@alum.mit.edu
>
To: dispatch@ietf.org
>
Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispa= tch-sip-continuation-option-03.txt


FollowRediff Deal ho jaye!to get exciting offers in your city everyday.
Sunil,



Looking back, I see that you had replied to my comments on the earlier

version of this draft and I never responded.



To summarize, the problem I have with this draft is that you leap to a

particular mechanism to solve a problem without having justified why

that solution is better than other possible solutions to the same

problem. And also without having sufficiently motivated people about why
this is a problem that needs solving.



Your latest update, with the ISDN interoperability example, suggests

that ISDN interoperability might be driving the way you frame the

problem. If so it would be good for you to explain that.



It still seems to me that this could be solved with less new mechanism.
The Priority header, plus an existing response (e.g. 403 Forbidden plus
an exiting or new Warning header) or a new response code.



Thanks,

Paul



On 4/2/12 1:46 PM, sunil sinha wrote:

> Dear All,

>

> I have just made revision 3 of

> =EF=BF=BDdraft-sinha-dispatch-sip-continuation-option=EF=BF=BD available = following

> offline discussion. Biggest addition is the new section 7.6 and 7.7

> which aims to further inter-working scenario.

>

> You can find the HTML formatted version here:

> http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-0= 3

>

>

> I am looking forward to hearing about any concerns you may have.

>

> Thanks & Regards,

> sunil kumar sinha

>

>

>

>

>

> ---------- Forwarded message ----------

> From: ** >

> Date: Mon, Apr 2, 2012 at 3:41 PM

> Subject: New Version Notification for

> draft-sinha-dispatch-sip-continuation-option-03.txt

> To: sunilkumarsinha9@gmail.com

> Cc: sinha.amardeep@gmail.com ,

> de_subhrajyoti@yahoo.co.uk

>

>

> A new version of I-D,

> draft-sinha-dispatch-sip-continuation-option-03.txt has been

> successfully submitted by Sunil Kumar Sinha and posted to the IETF

> repository.

>

> Filename: draft-sinha-dispatch-sip-continuation-option

> Revision: 03

> Title: The Continue Header Field for the Session Initiation

> Protocol (SIP)

> Creation date: 2012-04-02

> WG ID: Individual Submission

> Number of pages: 23

>

> Abstract:

> Before placing a call, it is quite often useful for the Caller to

> know whether a Callee is in favorable state to receive a call or

> not. This document defines an optional tag "continue" and a
> header

> "Continue" to address the purpose. The "Continue"

> header field is

> to confirm the session continuity with the Callee from the Caller

> after an option for session continuity is placed by the Callee based

> on the unfavorable state of the Callee. This functionality is needed

> to resolve the unwillingness of the Callee to receive any call. An

> option is given to the Callee by the Service Provider or by the

> Handset Manufacturer or by the Carrier to establish this requirement.
>

>

>

>

>

> The IETF Secretariat

>

>

>

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.org

> https://www.ietf.org/mailman/listinfo/dispatch



_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch


Amar

Follow Rediff= Deal ho jaye! to get exciting offers in your city = everyday.
--=_73d8d3c008554899798ee632c569c38a-- From pkyzivat@alum.mit.edu Mon Apr 9 06:02:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7F21F86FF for ; Mon, 9 Apr 2012 06:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhPoO42hThWF for ; Mon, 9 Apr 2012 06:02:08 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3D21F855A for ; Mon, 9 Apr 2012 06:02:01 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta08.westchester.pa.mail.comcast.net with comcast id vp1u1i0050ldTLk58p21Bv; Mon, 09 Apr 2012 13:02:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id vp201i00w07duvL3Qp217S; Mon, 09 Apr 2012 13:02:01 +0000 Message-ID: <4F82DDC6.4000704@alum.mit.edu> Date: Mon, 09 Apr 2012 09:01:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: amar deep References: <1333947130.S.10083.16336.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 401, 114.f5-224-169.old.1333948912.23738@webmail.rediffmail.com> In-Reply-To: <1333947130.S.10083.16336.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 401, 114.f5-224-169.old.1333948912.23738@webmail.rediffmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 13:02:09 -0000 On 4/9/12 1:21 AM, amar deep wrote: > Hi Paul, > > Problem : > -REQ-1: Callee wants no urgent call for him should get rejected when he > set DnD status =ON, & he fail to notice beep/flash over the phone. Do you have a standard definition of DnD status? Or is your DnD mechanism proprietary? > -REQ-2: Caller wants call to get connected only if callee is > free/available – for normal/urgent/emergency call > -REQ-3: Caller don’t wants call to get connected to Callee when is BUSY > – for Normal call > -REQ-4: Caller wants call to get connected what so ever is state of > callee is – for urgent/emergency call > > Problem-Solution justification with Continue -Why problem need to be solved: > -Based on call type(normal/urgent/emergency), caller can make decision > to go with call setup or not > -Based on callee status, caller can make decision to go with call setup > or not > -Decision of have call setup successful based on call priority is vested > within Caller decision not on feature configuration > > Using Priority header: > -Using Priority headers is not run time bases, its depends on call > service and pre-configured call setting I don't understand your comment about the Priority header. It seems to me that you can obtain all the behaviors you describe in your requirements and in your problem solution justification simply by the caller setting the Priority header and the callee taking it into account. > -Initial request from caller is MARKED if it’s a high priority call or > not – mainly addressing emergency situation.The priority header filed > mainly address to “resources that may become scarce and congested during > emergencies. These resources include gateway resources, circuit-switched > network resources, IP network resources, receiving end system resources > and SIP proxy resources. “. You seem to be describing the Resource-Priority header, not the Priority header. They are different. > -It doesn’t address above Requirement/problem, wherein call is made > high-priority based on callee availability/willingness and caller > decision about call catergory based on call-type > > Using 403 Forbidden /or New Response Code: > -For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX, > make call discontinue irrespective of call-type urgency > normal/urgent/emergency > -Response code of 3XX, 4XX, 5XX & 6XX category – don’t give option to > caller to make decision for call continuation or for termination You have two choices of how to use these mechanisms to accomplish your objective: 1) if the caller knows a priori that the call is high priority then he can instruct his phone to include a suitable Priority header value in the call initially. 2) the caller can always try calls first with normal priority. If the call fails with a response code that indicates that it was rejected because its priority was insufficient, then the phone can report this to the user, who can retry the call with the priority set appropriately. There are numerous possibilities for how the user interface would look for this. The exact code used to indicate that the call was rejected for insufficient priority can be refined if you want to pursue this approach. Thanks, Paul > ISDN interoperability: > -This section is added at 7.6 and 7.7 section of the draft document, to > state that this feature is not limited only from VoIP call > -This feature proposed within the draft document, works across network > type as well. > > Thanks, > Amardeep > > -- Original Message -- > > > > > > From: Paul Kyzivat pkyzivat@alum.mit.edu > > > To: dispatch@ietf.org > > > Subject: Re: [dispatch] Fwd: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > > > FollowRediff Deal ho jaye!to get exciting offers in your city everyday. > Sunil, > > > > Looking back, I see that you had replied to my comments on the earlier > > version of this draft and I never responded. > > > > To summarize, the problem I have with this draft is that you leap to a > > particular mechanism to solve a problem without having justified why > > that solution is better than other possible solutions to the same > > problem. And also without having sufficiently motivated people about why > > this is a problem that needs solving. > > > > Your latest update, with the ISDN interoperability example, suggests > > that ISDN interoperability might be driving the way you frame the > > problem. If so it would be good for you to explain that. > > > > It still seems to me that this could be solved with less new mechanism. > > The Priority header, plus an existing response (e.g. 403 Forbidden plus > > an exiting or new Warning header) or a new response code. > > > > Thanks, > > Paul > > > > On 4/2/12 1:46 PM, sunil sinha wrote: > > > Dear All, > > > > > > I have just made revision 3 of > > > �draft-sinha-dispatch-sip-continuation-option� available following > > > offline discussion. Biggest addition is the new section 7.6 and 7.7 > > > which aims to further inter-working scenario. > > > > > > You can find the HTML formatted version here: > > > > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 > > > > > > > > > I am looking forward to hearing about any concerns you may have. > > > > > > Thanks & Regards, > > > sunil kumar sinha > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > From: ** > > > > Date: Mon, Apr 2, 2012 at 3:41 PM > > > Subject: New Version Notification for > > > draft-sinha-dispatch-sip-continuation-option-03.txt > > > To: sunilkumarsinha9@gmail.com > > > Cc: sinha.amardeep@gmail.com , > > > de_subhrajyoti@yahoo.co.uk > > > > > > > > > A new version of I-D, > > > draft-sinha-dispatch-sip-continuation-option-03.txt has been > > > successfully submitted by Sunil Kumar Sinha and posted to the IETF > > > repository. > > > > > > Filename: draft-sinha-dispatch-sip-continuation-option > > > Revision: 03 > > > Title: The Continue Header Field for the Session Initiation > > > Protocol (SIP) > > > Creation date: 2012-04-02 > > > WG ID: Individual Submission > > > Number of pages: 23 > > > > > > Abstract: > > > Before placing a call, it is quite often useful for the Caller to > > > know whether a Callee is in favorable state to receive a call or > > > not. This document defines an optional tag "continue" and a > > > header > > > "Continue" to address the purpose. The "Continue" > > > header field is > > > to confirm the session continuity with the Callee from the Caller > > > after an option for session continuity is placed by the Callee based > > > on the unfavorable state of the Callee. This functionality is needed > > > to resolve the unwillingness of the Callee to receive any call. An > > > option is given to the Callee by the Service Provider or by the > > > Handset Manufacturer or by the Carrier to establish this requirement. > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Amar > > > > Follow *_Rediff Deal ho jaye! > _* > to get exciting offers in your city everyday. > From prvs=4446c6b78f=jbakker@rim.com Mon Apr 9 07:47:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7DE21F873C for ; Mon, 9 Apr 2012 07:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IAWWvjeq2Cx for ; Mon, 9 Apr 2012 07:47:28 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 31DCB21F873B for ; Mon, 9 Apr 2012 07:47:27 -0700 (PDT) X-AuditID: 0a412830-b7fcb6d000001866-9b-4f82f67e4344 Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id B5.52.06246.E76F28F4; Mon, 9 Apr 2012 14:47:26 +0000 (GMT) Received: from XCT104ADS.rim.net (10.67.111.45) by XHT107CNC.rim.net (10.65.12.217) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 9 Apr 2012 10:47:26 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.01.0339.001; Mon, 9 Apr 2012 09:47:25 -0500 From: John-Luc Bakker To: Paul Kyzivat , "Gonzalo.Camarillo@ericsson.com" Thread-Topic: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) Thread-Index: AQHNDEA4nHIjIWeYK0SVL4/+gfx+D5aS+qkQ Date: Mon, 9 Apr 2012 14:47:23 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsXC5chzU7fuW5O/wfu3ZhZLJy1gtdi0fCWT xYoNB1gdmD3+vv/A5PHr61U2jyVLfjIFMEc1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifb KvmkpifmKAQUZZYlJlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlx KWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlO92ETp6MRZ8eMRW8s63omtnP3MD42aiL kZNDQsBEYlXnQyYIW0ziwr31bF2MXBxCAr1MEi9mrGaCcJYySrxYtwgqs4lRYmX7dBaQFjYB dYmtK7Yzg9giArkSTRc+MoLYzALaEv+vr2MEaRAWmMMo8XfODDBHRGAuo8Tb7U/ZITqMJHov TgGyOThYBFQkXs1OAQnzCrhJzFnXALXtDqNEW+9esG2cAu4S1/fcZgWxGYGO/X5qDRPENnGJ W0/mQz0hILFkz3lmCFtU4uXjf6wQtqLE45ZuFoh6HYkFuz+xwVy6bOFrZojFghInZz4BqxES kJFobdvFNoFRYhaSFbOQtM9C0j4LSfsCRpZVjIK5GcUGZobJecl6RZm5enmpJZsYwSlHw2AH 44S9WocYBTgYlXh4JR82+QuxJpYVV+YeYpTgYFYS4S16BhTiTUmsrEotyo8vKs1JLT7EaAEM oYnMUtzJ+cB0mFcSb2xggMJREueNvV3rLySQDkxZ2ampBalFMK1MHJwgo7mkRIqBiSe1KLG0 JCMelB7ji4EJUqqBcfqMH7d3n2a8flL4zruNx6dsO7FY4O2G7+JSrPnvMxcKOHxyjvi4YL7m 28L5L+0aH0nGyj/bK/689tdaO+kpkY6pF9dXvqlf9EqTQ3fuWu7fcQxNxoHT9Lfef+QozpIc MOvAS5GuM0x+y55tOcy/WtzJKVrLq+V9a3YE8/N9FRc5UnbFnjmyOFmJpTgj0VCLuag4EQBy lLJwbQMAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:47:29 -0000 Dear Paul, Gonzalo, I received an editorial comment on this draft. The draft is referring to sec= tions 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and 4= .2.3. Have you had an oppertunity to further digest the draft in light of our prev= ious offline discussion? Kind regards, John-Luc -----Original Message----- From: John-Luc Bakker Sent: Tuesday, March 27, 2012 12:37 PM To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com Cc: dispatch@ietf.org Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: [dispa= tch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) Dear all, I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handli= ng available following offline discussion. Biggest addition is the new secti= on 2.1 which aims to further motivate the need for the ID. You can find the HTML formatted version here: http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-0= 8 I am looking forward to hearing about any concerns you may have. Kind regards, John-Luc -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of John-Luc Bakker Sent: Tuesday, March 20, 2012 1:53 PM To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com Cc: dispatch@ietf.org; sipping Subject: Re: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-h= andling-07.txt Hi, Thanks, Paul for reviewing the draft. Appologies for having delayed this response. Let me address first the question about this being a SIPPING draft: I intend= to ask Gonzallo to sponsor this draft. To collect any further comments and= ensure visibility (sine the sipping list is obsolete), I have copied the DI= SPATCH list. See also inline with . -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Saturday, December 03, 2011 12:11 PM To: John-Luc Bakker Cc: sipping Subject: Re: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.= txt I'm commenting on this on the (now obsolete) sipping list because this has sipping in its name. This may not be the best place. I suppose an alternative is rai. ISTM that there are three degrees of freedom here for identifying how to process these bodies: - content-disposition - content-type - the actual content of the body Of these, the content-disposition is the most heavy weight in terms of mechanism, while the actual content of the body is the least heavy-weight. So, I wonder why you have chosen to use one content-type, that seems to already contain distinct representations for the differing behaviors of interest, and yet use distinct content-dispositions. I think you could use a single content-disposition and get the same effect. I guess multiple content-dispositions might make sense if they are processed by different entities, so that only the intended entities need decode the body. The reason for having two content dispositions is because there are dif= ferent behaviors for the same content-type when received by different entiti= es. There are two different entities that apply a different behavior when r= eceiving the body, say behavior A and behavior B. However, XML elements pres= ent in the body trigger behavior A (in the abstract of the draft, behavior (= 2)) by entity A and if not present, no further behavior by entity A is speci= fied in this draft. Other XML elements present in the body trigger one of a= set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by= entity B and if not present, no further behavior by entity B is specified i= n this draft. It would also make sense if the same identical body representation was processed differently based on the content-disposition. The bodies triggering the different behaviors are indeed not identical.= However, the content-dispositions are processed by different entities,= which is a reason for proposing these content-disposition values. But I don't think either of those is the case here. So I would find it helpf= ul if this draft explained why it chooses to use multiple content-dispositio= ns. The draft illustrates that, in IMS, different entities receive bodies w= ith the content-type, and apply different behaviors. The draft further sugge= sts that the applicability of these values may be limited to IMS. Do you see= a need for a general discussion of this approach since the applicability is= limited to IMS? I also think it would be useful to say something about how you expect the handling parameter to be used with these dispositions. If handling=3Drequired (the default) is used, then any UA that gets this must fail the request unless it is able to handle the body. If handling=3Doptional is specified, then that need not be so. The handling parameter is mentioned in RFC 3261 and this draft refers t= o that RFC. RFC 3261 refers to RFC 3204. This draft does not change the beha= vior and interpretation of the parameter and its values. It should not be ne= cessary to repeat what has already been documented in RFC 3261. Do you see d= ifferent behavior that goes beyond what has been documented? Thanks, Paul On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > Title : Specification of 3GPP IM CN Subsystem XML body handling > Author(s) : John-Luc Bakker > Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > Pages : 7 > Date : 2011-12-02 > > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body used by 3GPP. The applicability of these content-disposition > values are limited to 3GPP IMS. The application/3gpp-ims+xml body > has the following three distinct uses: (1) for redirecting the > emergency session to use a different domain (e.g. using a Circuit > Switched call), (2) for delivering user profile specific information > from the SIP registrar to an Application Server, and (3) for causing > a UAC to attempt to re-register with the IMS. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body= -handling-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-= handling-07.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From manjugd@gmail.com Mon Apr 9 22:15:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CF121F8782 for ; Mon, 9 Apr 2012 22:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuTs7mDxzb6R for ; Mon, 9 Apr 2012 22:15:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 276CD21F8809 for ; Mon, 9 Apr 2012 22:15:02 -0700 (PDT) Received: by iazz13 with SMTP id z13so8252570iaz.31 for ; Mon, 09 Apr 2012 22:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hMtTtolZW05kpOpzJoXRUfbJmui1da4vzKdNKKlgnWI=; b=GlO6Foza26B0H8oeIBc+JgKF3Z5mWeZ2vernF3oCr/x1Q0QfBwF63hCNBbv5XmpP1z DtzOZCvdIPBXIKun5+Ad/VWBcvGP3Xptjy0urBbH5oxjjoSmhiFZF7fPJK/uYXjVWCUI pY9XtvNNG2SIuCUNPdLUYB+EByDOyOPP4V0W/Vpv2zugX4LhWAxjRk0outhkNN1Hp3dE OB0TuAihRxH5REKSTceNDFwEekKHBCf8RjZt4jEupSZxs6JrUCgTo1Jlhdmq+XTkZQEo P5YZlECZyknvFwYJgLT71dlKVdunoa83asoaPg5aduwaT2mzxiynefGPaNyhq3kwnZ2Y CXBg== MIME-Version: 1.0 Received: by 10.50.185.201 with SMTP id fe9mr1054977igc.47.1334034901793; Mon, 09 Apr 2012 22:15:01 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Mon, 9 Apr 2012 22:15:01 -0700 (PDT) In-Reply-To: <4F79E624.7070200@alum.mit.edu> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <4F79E624.7070200@alum.mit.edu> Date: Tue, 10 Apr 2012 10:45:01 +0530 Message-ID: From: Manjunath To: Paul Kyzivat Content-Type: multipart/alternative; boundary=14dae9340d39707c6204bd4c34f8 Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:15:06 -0000 --14dae9340d39707c6204bd4c34f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Paul, *Query:* To summarize, the problem I have with this draft is that you leap to a particular mechanism to solve a problem without having justified why that solution is better than other possible solutions to the same problem.And also without having sufficiently motivated people about why this is a problem that needs solving. * [Answer]: For the type of problems we are addressing below i.e: - How do we know the exact mood/state of a callee to place a normal/Urgent/important call? - How can we make the callee to pick only URGENT/Important call from his favourite/buddy list which he feels is so important and ignore very less important call silently? - How can we avoid taking less important calls or avoid getting disturbed from callers when callee is in a good state of mind? Currently we do not have any techniques to solve all of these problems which still exists as of today. So with our proposed solution in this draft it is possible to solve all these problems at once.* *[Query]: *Your latest update, with the ISDN interoperability example, suggests that ISDN interoperability might be driving the way you frame the problem. If so it would be good for you to explain that. *[Answer]: we have added sections 7.6 and 7.7 in draft revision to state that this useful feature can not only be used for SIP call but can also be used with other interworking scenarios and with other network types. * *[Query]*: It still seems to me that this could be solved with less new mechanism. The Priority header, plus an existing response (e.g. 403 Forbidden plus an exiting or new Warning header) or a new response code. *[Answer]: So far with our SIP knowledge along with Telecom features implemented and available till to-day either using Priority Header OR with existing/new response code I believe we do not have an *exact* solution for the problems which we are describing here. For eg.: - The caller to know what is the mood/state of a callee? - The callee unnecessarily don=92t want to receive less important ca= ll from unknown user and get disturbed with his state of mind. - The callee can pick only URGENT/Important call from his favourite/buddy list which he feels is so important. Each of the mechanisms you described have their own limitations for instance if you look at Priority header it is not at all based on *dynamic* action and it purely depends on our call-settings(pre) and the type of the call-service. With the problem statement what we described in this draft it would not fulfill the *exact* solution what we are addressing here. Here we are trying to solve with less overhead mechanism by using existing response code for instance in 182 Queued by introducing optional continue header.** Depending upon favourable state and willingness of both the parties as far as possible and up-to the maximum extent we are making successful call establishment . ** If you have better approach to solve the exact set of problems that exists let us know we can use that technique. * Thanks - Manjunath* * On Mon, Apr 2, 2012 at 11:17 PM, Paul Kyzivat wrote= : > Sunil, > > Looking back, I see that you had replied to my comments on the earlier > version of this draft and I never responded. > > To summarize, the problem I have with this draft is that you leap to a > particular mechanism to solve a problem without having justified why that > solution is better than other possible solutions to the same problem. And > also without having sufficiently motivated people about why this is a > problem that needs solving. > > Your latest update, with the ISDN interoperability example, suggests that > ISDN interoperability might be driving the way you frame the problem. If = so > it would be good for you to explain that. > > It still seems to me that this could be solved with less new mechanism. > The Priority header, plus an existing response (e.g. 403 Forbidden plus a= n > exiting or new Warning header) or a new response code. > > Thanks, > Paul > > > On 4/2/12 1:46 PM, sunil sinha wrote: > >> Dear All, >> >> I have just made revision 3 of >> =91draft-sinha-dispatch-sip-**continuation-option=92 available following >> offline discussion. Biggest addition is the new section 7.6 and 7.7 >> which aims to further inter-working scenario. >> >> You can find the HTML formatted version here: >> http://tools.ietf.org/html/**draft-sinha-dispatch-sip-** >> continuation-option-03 >> >> >> I am looking forward to hearing about any concerns you may have. >> >> Thanks & Regards, >> sunil kumar sinha >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: ** >> >> >> Date: Mon, Apr 2, 2012 at 3:41 PM >> Subject: New Version Notification for >> draft-sinha-dispatch-sip-**continuation-option-03.txt >> To: sunilkumarsinha9@gmail.com >> > >> Cc: sinha.amardeep@gmail.com >> >, >> de_subhrajyoti@yahoo.co.uk >> > >> >> >> A new version of I-D, >> draft-sinha-dispatch-sip-**continuation-option-03.txt has been >> successfully submitted by Sunil Kumar Sinha and posted to the IETF >> repository. >> >> Filename: draft-sinha-dispatch-sip-**continuation-option >> Revision: 03 >> Title: The Continue Header Field for the Session Initiation >> Protocol (SIP) >> Creation date: 2012-04-02 >> WG ID: Individual Submission >> Number of pages: 23 >> >> Abstract: >> Before placing a call, it is quite often useful for the Caller to >> know whether a Callee is in favorable state to receive a call or >> not. This document defines an optional tag "continue" and a >> header >> "Continue" to address the purpose. The "Continue" >> header field is >> to confirm the session continuity with the Callee from the Caller >> after an option for session continuity is placed by the Callee based >> on the unfavorable state of the Callee. This functionality is needed >> to resolve the unwillingness of the Callee to receive any call. An >> option is given to the Callee by the Service Provider or by the >> Handset Manufacturer or by the Carrier to establish this requirement. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> ______________________________**_________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/**listinfo/dispatch >> > > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --14dae9340d39707c6204bd4c34f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Paul,

Query: To summarize, the problem I have with = this draft is that you leap to a particular mechanism to solve a problem without having justified=20 why that solution is better than other possible solutions to the same=20 problem.And also without having sufficiently motivated people about why=20 this is a problem that needs solving.

=A0
[Answer]: For the type of problems we are addressing below i.= e:
=A0

-=A0=A0=A0=A0=A0=A0=A0 How do we know the exact mood/state= of a callee to place a normal/Urgent/important call?

-=A0=A0=A0=A0= =A0=A0=A0 How can we make the callee to pick only URGENT/Important call from his=20 favourite/buddy list which he feels is so important and ignore very less important call silently?

-=A0=A0=A0=A0=A0=A0=A0 How can we avoid taking less important calls or = avoid=20 getting disturbed from callers when callee is in a good state of mind?
= =A0

Currently we do not have any techniques to solve all of these problems which=20 still exists as of today. So with our proposed solution in this draft=20 it is possible to solve all these problems at once.

=A0
[Query]: Your latest update, with the ISDN interop= erability=20 example, suggests that ISDN interoperability might be driving the way=20 you frame the problem. If so it would be good for you to explain that.
<= br>=A0

[Answer]: we have added sections 7.6 and 7.7 in draft revision to state that this useful feature can not only be used for SIP call but=20 can also be used with other interworking scenarios and with other=20 network types.

=A0
=A0

[Query]: It still seems to me that= this could be solved with less new mechanism. The Priority header, plus an=20 existing response (e.g. 403 Forbidden plus an exiting or new Warning=20 header) or a new response code.

=A0

[Answer]: So far with our SIP knowledge along with=20 Telecom features implemented and available till to-day either using=20 Priority Header OR with existing/new response code I believe we do not=20 have an *exact* solution for the problems which we are describing here.=20 For eg.:

-=A0=A0=A0=A0=A0=A0=A0 The caller to know what is the mood/state of a c= allee?

-=A0=A0=A0=A0=A0=A0=A0 The callee unnecessarily don=92t want to receive less important call from unknown user and get disturbed with his state of mind.

-=A0=A0=A0= =A0=A0=A0=A0 The callee can pick only URGENT/Important call from his favour= ite/buddy list which he feels is so important.

=A0

Each of the mechanisms you described have their own limitati= ons for instance if you look at Priority header=20 it is not at all based on *dynamic* action and it purely depends on our=20 call-settings(pre) and the type of the call-service. With the problem=20 statement what we described in this draft it would not fulfill the=20 *exact* solution what we are addressing here.

=A0Here we are trying to solve with less overhead mechanism by using=20 existing response code for instance in 182 Queued by introducing=20 optional continue header. Depending upon favourable state and willin= gness of both the parties as far as possible and up-to the maximum extent we are making successful=20 call establishment . If you have better approach to solve the exact set of problems that exists let us know we can use that technique.
=
Thanks
- Manjunath



= On Mon, Apr 2, 2012 at 11:17 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrot= e:
Sunil,

Looking back, I see that you had replied to my comments on the earlier vers= ion of this draft and I never responded.

To summarize, the problem I have with this draft is that you leap to a part= icular mechanism to solve a problem without having justified why that solut= ion is better than other possible solutions to the same problem. And also w= ithout having sufficiently motivated people about why this is a problem tha= t needs solving.

Your latest update, with the ISDN interoperability example, suggests that I= SDN interoperability might be driving the way you frame the problem. If so = it would be good for you to explain that.

It still seems to me that this could be solved with less new mechanism. The= Priority header, plus an existing response (e.g. 403 Forbidden plus an exi= ting or new Warning header) or a new response code.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


On 4/2/12 1:46 PM, sunil sinha wrote:
Dear All,

I have just made revision 3 of
=91draft-sinha-dispatch-sip-continuation-option=92 available followi= ng
offline discussion. Biggest addition is the new section 7.6 and 7.7
which aims to further inter-working scenario.

You can find the HTML formatted version here:
http://tools.ietf.org/html/draft-sinha= -dispatch-sip-continuation-option-03


I am looking forward to hearing about any concerns you may have.

Thanks & Regards,
sunil kumar sinha





---------- Forwarded message ----------
From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for
draft-sinha-dispatch-sip-continuation-option-03.txt
To: sunilku= marsinha9@gmail.com <mailto:sunilkumarsinha9@gmail.com>
Cc: sinha.ama= rdeep@gmail.com <mailto:sinha.amardeep@gmail.com>,
de_subhrajy= oti@yahoo.co.uk <mailto:de_subhrajyoti@yahoo.co.uk>


A new version of I-D,
draft-sinha-dispatch-sip-continuation-option-03.txt has been
successfully submitted by Sunil Kumar Sinha and posted to the IETF
repository.

Filename: =A0 =A0 =A0 =A0draft-sinha-dispatch-sip-continuation-optio= n
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 The Continue Header Field for the Session Initia= tion
Protocol (SIP)
Creation date: =A0 2012-04-02
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 23

Abstract:
=A0 Before placing a call, it is quite often useful for the Caller to
=A0 know whether a Callee is in favorable state to receive a call or
=A0 not. This document defines an optional tag &quot;continue&quot= ; and a
header
&quot;Continue&quot; to address the purpose. =A0The &quot;Conti= nue&quot;
header field is
=A0 to confirm the session continuity with the Callee from the Caller
=A0 after an option for session continuity is placed by the Callee based =A0 on the unfavorable state of the Callee. =A0This functionality is neede= d
=A0 to resolve the unwillingness of the Callee to receive any call. An
=A0 option is given to the Callee by the Service Provider or by the
=A0 Handset Manufacturer or by the Carrier to establish this requirement.<= br>




The IETF Secretariat



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

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

--14dae9340d39707c6204bd4c34f8-- From manjugd@gmail.com Mon Apr 9 22:48:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CABD21F875B for ; Mon, 9 Apr 2012 22:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEWJedOSTNS2 for ; Mon, 9 Apr 2012 22:48:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D721F8749 for ; Mon, 9 Apr 2012 22:48:52 -0700 (PDT) Received: by iazz13 with SMTP id z13so8291298iaz.31 for ; Mon, 09 Apr 2012 22:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FthNoGZ01F+WLnDNoVEXOv8a+A3t4B86n9nh16mWKrc=; b=FQUWIyHZ1kgNDK+HImvKJx1dgrdQZWaSp6ur6gwmAJsKp7y9xttVOLTMG6nRMZ4t1u 8nLIV+zQNl6s3suhd3HIOL7Pc/RlXTBKhDOXud+pxB70e2gvwftMDNoMc5igLRMFcRAI qVVbLzw96F7QE/0xyptOXDOVuj1IGpnm6WHws7LY9bec0+cHz8fw+e7QhsmLLhGAF5iZ dRPcHZMKmb39RjUI0ELZNebnguzIVDsuWNN0vvD0ipGjfkMBLo4Uiu92LCsPdHrGeuVW 6nyqOlGro6q1TM6AN3Ze6kAuVwPOGbLtIPdkF0de9k7lG012NzOMs7ToQ23cxqPnm93D oJZg== MIME-Version: 1.0 Received: by 10.50.186.166 with SMTP id fl6mr1111016igc.47.1334036931715; Mon, 09 Apr 2012 22:48:51 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Mon, 9 Apr 2012 22:48:51 -0700 (PDT) In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BC2DC3CA@HKGMBOXPRD22.polycom.com> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3CA@HKGMBOXPRD22.polycom.com> Date: Tue, 10 Apr 2012 11:18:51 +0530 Message-ID: From: Manjunath To: "Avasarala, Ranjit" Content-Type: multipart/alternative; boundary=14dae9340db16ea08c04bd4cad6f Cc: Cullen Jennings , "dispatch@ietf.org" , amardeep sinha , Subhrajyoti De , "Barnes, Mary" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:48:53 -0000 --14dae9340db16ea08c04bd4cad6f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ranjit, For this kind of *overhead* we have an option to leave a VM OR use a call Block feature facility available. Our idea here is to distinguish with the type of call we receive and depending on the type of call received we can have the control/intelligence whether to proceed with call setup successfully or not. Every call is important for everyone in this dynamic fast paced world.Our Goal is to make better communication for the next generation. If you see here we are trying to solve with less overhead mechanism by using existing response code for instance in "182 Queued" by introducing optional continue header. As far as possible and up-to the maximum extent we are making successful call establishment depending upon favourable state and willingness of both the parties. Thanks - Manjunath On Mon, Apr 2, 2012 at 8:20 PM, Avasarala, Ranjit < Ranjit.Avasarala@polycom.com> wrote: > Hi Sunil > > I have a basic query - if a callee is unwilling to receive a particular > call, he or she can cancel the call. so in that case why is a new header > "Continue" required? isn't it a unnecessary overhead? > > > Regards > Ranjit > > ------------------------------ > *From:* dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf > Of sunil sinha [sunilkumarsinha9@gmail.com] > *Sent:* Monday, April 02, 2012 5:16 PM > *To:* Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.org > *Cc:* amardeep sinha; Subhrajyoti De > *Subject:* [dispatch] Fwd: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > > Dear All, > > I have just made revision 3 of > =91draft-sinha-dispatch-sip-continuation-option=92 available following of= fline > discussion. Biggest addition is the new section 7.6 and 7.7 which aims to > further inter-working scenario. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-0= 3 > > > I am looking forward to hearing about any concerns you may have. > > Thanks & Regards, > sunil kumar sinha > > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Apr 2, 2012 at 3:41 PM > Subject: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > To: sunilkumarsinha9@gmail.com > Cc: sinha.amardeep@gmail.com, de_subhrajyoti@yahoo.co.uk > > > A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt > has been successfully submitted by Sunil Kumar Sinha and posted to the IE= TF > repository. > > Filename: draft-sinha-dispatch-sip-continuation-option > Revision: 03 > Title: The Continue Header Field for the Session Initiation > Protocol (SIP) > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > Before placing a call, it is quite often useful for the Caller to > know whether a Callee is in favorable state to receive a call or > not. This document defines an optional tag "continue" and a > header > "Continue" to address the purpose. The "Continue" > header field is > to confirm the session continuity with the Callee from the Caller > after an option for session continuity is placed by the Callee based > on the unfavorable state of the Callee. This functionality is needed > to resolve the unwillingness of the Callee to receive any call. An > option is given to the Callee by the Service Provider or by the > Handset Manufacturer or by the Carrier to establish this requirement. > > > > > > The IETF Secretariat > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --14dae9340db16ea08c04bd4cad6f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ranjit,

For this kind of *overhead* we have an option to leave a = VM OR use a call Block feature facility available.
Our idea here is to d= istinguish with the type of call we receive and depending on=A0 the type of= call received we can have the control/intelligence whether to proceed with= call setup successfully or not. Every call is important for everyone in th= is dynamic fast paced world.Our Goal is to make better communication for th= e next generation.

If you see here we are trying to solve with less overhead mechanism by = using existing response code for instance in "182 Queued" by intr= oducing optional continue header. As far as possible and up-to the maximum = extent we are making successful call establishment depending upon favourabl= e state and willingness of both the parties.

Thanks
- Manjunath

On Mon, Apr 2, = 2012 at 8:20 PM, Avasarala, Ranjit <Ranjit.Avasarala@polycom.co= m> wrote:
Hi Sunil
=A0
I have a basic query - if a callee is u= nwilling to receive a particular call, he or she can cancel the call. so in= that case why is a new header "Continue" required? isn't it = a unnecessary overhead?
=A0
=A0
Regards
Ranjit
=A0
From: dispatch-bounces@ietf.org [dispatch-bounce= s@ietf.org] On Behalf Of sunil sinha [sunilkumarsinha9@gmail.com]
Sent: Monday, April 02, 2012 5:16 PM
To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; dispatch@ietf.org
Cc: amardeep sinha; Subhrajyoti De
Subject: [dispatch] Fwd: New Version Notification for draft-sinha-di= spatch-sip-continuation-option-03.txt

Dear All,

I have just made revision 3 of =91draft-sinha-dispatch-sip-continuation-opt= ion=92 available following offline discussion. Biggest addition is the new = section 7.6 and 7.7 which aims to further inter-working scenario.

You can find the HTML formatted version here:
http://tools.ietf.org/html/draft-sinha-dispat= ch-sip-continuation-option-03


I am looking forward to hearing about any concerns you may have.

Thanks & Regards,
sunil kumar sinha





---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for draft-sinha-dispatch-sip-continuation= -option-03.txt
To: sunilku= marsinha9@gmail.com
Cc: sinha.ama= rdeep@gmail.com, de_subhrajyoti@yahoo.co.uk


A new version of I-D, draft-sinha-dispatch-sip-continuation-option-03.txt h= as been successfully submitted by Sunil Kumar Sinha and posted to the IETF = repository.

Filename: =A0 =A0 =A0 =A0draft-sinha-dispatch-sip-continuation-option
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 The Continue Header Field for the Session Initia= tion Protocol (SIP)
Creation date: =A0 2012-04-02
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 23

Abstract:
=A0 Before placing a call, it is quite often useful for the Caller to
=A0 know whether a Callee is in favorable state to receive a call or
=A0 not. This document defines an optional tag &quot;continue&quot;= and a header
=A0 &quot;Continue&quot; to address the purpose. =A0The &quot;C= ontinue&quot; header field is
=A0 to confirm the session continuity with the Callee from the Caller
=A0 after an option for session continuity is placed by the Callee based =A0 on the unfavorable state of the Callee. =A0This functionality is needed=
=A0 to resolve the unwillingness of the Callee to receive any call. An
=A0 option is given to the Callee by the Service Provider or by the
=A0 Handset Manufacturer or by the Carrier to establish this requirement.




The IETF Secretariat


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


--14dae9340db16ea08c04bd4cad6f-- From christer.holmberg@ericsson.com Tue Apr 10 04:43:01 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EA821F849A for ; Tue, 10 Apr 2012 04:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.124 X-Spam-Level: X-Spam-Status: No, score=-7.124 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXDzED29IObO for ; Tue, 10 Apr 2012 04:43:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3532721F8498 for ; Tue, 10 Apr 2012 04:43:00 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-c8-4f841cc2ed28 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.DB.03534.3CC148F4; Tue, 10 Apr 2012 13:42:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 10 Apr 2012 13:42:58 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Date: Tue, 10 Apr 2012 13:42:56 +0200 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Thread-Index: Ac0Q+Kj0upsKq3gxRcG6bgCzkoRzQwGE/FGQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42D3B369@ESESSCMS0356.eemea.ericsson.se> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <4F79E624.7070200@alum.mit.edu> In-Reply-To: <4F79E624.7070200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:43:01 -0000 Hi, Some initial questions: Q1. Why can't the caller, already when sending the initial INVITE, indicate= whether the call is important or not, in order for the callee to take prop= er actions? Why does the callee have to tell the caller to give that inform= ation? Q2. I don't think the usage of Require is correct. Require is used to manda= te support of a SIP extension, but in the PRACK/UPDATE the caller uses it t= o tell the callee that the call is important. Q3. In the draft, the 182 response contains SDP (section 7.x). But, I guess= the callee will not start reserving resources until it has decided whether= it is going to accept the call. Q4: In the ABNF (section 5), you don't need to define the same value with c= apital and small letters. Q5: I don't understand why the caller has to send PRACK in case of Continue= : no (section 7.2). Why not simply send CANCEL? Regards, Christer On 4/2/12 1:46 PM, sunil sinha wrote: > Dear All, > > I have just made revision 3 of > 'draft-sinha-dispatch-sip-continuation-option' available following=20 > offline discussion. Biggest addition is the new section 7.6 and 7.7=20 > which aims to further inter-working scenario. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-optio > n-03 > > > I am looking forward to hearing about any concerns you may have. > > Thanks & Regards, > sunil kumar sinha > > > > > > ---------- Forwarded message ---------- > From: ** > > Date: Mon, Apr 2, 2012 at 3:41 PM > Subject: New Version Notification for > draft-sinha-dispatch-sip-continuation-option-03.txt > To: sunilkumarsinha9@gmail.com > Cc: sinha.amardeep@gmail.com , > de_subhrajyoti@yahoo.co.uk > > > A new version of I-D, > draft-sinha-dispatch-sip-continuation-option-03.txt has been=20 > successfully submitted by Sunil Kumar Sinha and posted to the IETF=20 > repository. > > Filename: draft-sinha-dispatch-sip-continuation-option > Revision: 03 > Title: The Continue Header Field for the Session Initiation > Protocol (SIP) > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > Before placing a call, it is quite often useful for the Caller to > know whether a Callee is in favorable state to receive a call or > not. This document defines an optional tag "continue" and=20 > a header "Continue" to address the purpose. The=20 > "Continue" header field is > to confirm the session continuity with the Callee from the Caller > after an option for session continuity is placed by the Callee based > on the unfavorable state of the Callee. This functionality is needed > to resolve the unwillingness of the Callee to receive any call. An > option is given to the Callee by the Service Provider or by the > Handset Manufacturer or by the Carrier to establish this requirement. > > > > > > The IETF Secretariat > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Apr 10 05:44:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977DF21F85C0 for ; Tue, 10 Apr 2012 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22S3egKVe0ZP for ; Tue, 10 Apr 2012 05:43:59 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8821321F8589 for ; Tue, 10 Apr 2012 05:43:59 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id wBmM1i0041swQuc51Cjzcx; Tue, 10 Apr 2012 12:43:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id wCjz1i01007duvL3bCjzwG; Tue, 10 Apr 2012 12:43:59 +0000 Message-ID: <4F842B0E.9080308@alum.mit.edu> Date: Tue, 10 Apr 2012 08:43:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Manjunath References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <4F79E624.7070200@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:44:00 -0000 I made another reply on this thread yesterday that addresses most of what you bring up below - showing how to use Priority to meet your goals. Can you please comment on that? See: http://www.ietf.org/mail-archive/web/dispatch/current/msg04320.html Thanks, Paul On 4/10/12 1:15 AM, Manjunath wrote: > Hi Paul, > > _*Query:*_ To summarize, the problem I have with this draft is that you > leap to a particular mechanism to solve a problem without having > justified why that solution is better than other possible solutions to > the same problem.And also without having sufficiently motivated people > about why this is a problem that needs solving. > * > > [Answer]: For the type of problems we are addressing below i.e: > > > - How do we know the exact mood/state of a callee to place a > normal/Urgent/important call? > > - How can we make the callee to pick only URGENT/Important call > from his favourite/buddy list which he feels is so important and ignore > very less important call silently? > > - How can we avoid taking less important calls or avoid getting > disturbed from callers when callee is in a good state of mind? > > > Currently we do not have any techniques to solve all of these problems > which still exists as of today. So with our proposed solution in this > draft it is possible to solve all these problems at once.* > > > _*[Query]: *_Your latest update, with the ISDN interoperability example, > suggests that ISDN interoperability might be driving the way you frame > the problem. If so it would be good for you to explain that. > > > > *[Answer]: we have added sections 7.6 and 7.7 in draft revision to state > that this useful feature can not only be used for SIP call but can also > be used with other interworking scenarios and with other network types. > * > > > > _*[Query]*_: It still seems to me that this could be solved with less > new mechanism. The Priority header, plus an existing response (e.g. 403 > Forbidden plus an exiting or new Warning header) or a new response code. > > > > *[Answer]: So far with our SIP knowledge along with Telecom features > implemented and available till to-day either using Priority Header OR > with existing/new response code I believe we do not have an *exact* > solution for the problems which we are describing here. For eg.: > > - The caller to know what is the mood/state of a callee? > > - The callee unnecessarily don’t want to receive less important > call from unknown user and get disturbed with his state of mind. > > - The callee can pick only URGENT/Important call from his > favourite/buddy list which he feels is so important. > > > > Each of the mechanisms you described have their own limitations for > instance if you look at Priority header it is not at all based on > *dynamic* action and it purely depends on our call-settings(pre) and the > type of the call-service. With the problem statement what we described > in this draft it would not fulfill the *exact* solution what we are > addressing here. > > Here we are trying to solve with less overhead mechanism by using > existing response code for instance in 182 Queued by introducing > optional continue header.**Depending upon favourable state and > willingness of both the parties as far as possible and up-to the maximum > extent we are making successful call establishment . **If you have > better approach to solve the exact set of problems that exists let us > know we can use that technique. > * > Thanks > - Manjunath* > > > * > On Mon, Apr 2, 2012 at 11:17 PM, Paul Kyzivat > wrote: > > Sunil, > > Looking back, I see that you had replied to my comments on the > earlier version of this draft and I never responded. > > To summarize, the problem I have with this draft is that you leap to > a particular mechanism to solve a problem without having justified > why that solution is better than other possible solutions to the > same problem. And also without having sufficiently motivated people > about why this is a problem that needs solving. > > Your latest update, with the ISDN interoperability example, suggests > that ISDN interoperability might be driving the way you frame the > problem. If so it would be good for you to explain that. > > It still seems to me that this could be solved with less new > mechanism. The Priority header, plus an existing response (e.g. 403 > Forbidden plus an exiting or new Warning header) or a new response code. > > Thanks, > Paul > > > On 4/2/12 1:46 PM, sunil sinha wrote: > > Dear All, > > I have just made revision 3 of > ‘draft-sinha-dispatch-sip-__continuation-option’ available following > offline discussion. Biggest addition is the new section 7.6 and 7.7 > which aims to further inter-working scenario. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/__draft-sinha-dispatch-sip-__continuation-option-03 > > > > I am looking forward to hearing about any concerns you may have. > > Thanks & Regards, > sunil kumar sinha > > > > > > ---------- Forwarded message ---------- > From: ** > >> > Date: Mon, Apr 2, 2012 at 3:41 PM > Subject: New Version Notification for > draft-sinha-dispatch-sip-__continuation-option-03.txt > To: sunilkumarsinha9@gmail.com > > > > Cc: sinha.amardeep@gmail.com > >, > de_subhrajyoti@yahoo.co.uk > > > > > A new version of I-D, > draft-sinha-dispatch-sip-__continuation-option-03.txt has been > successfully submitted by Sunil Kumar Sinha and posted to the IETF > repository. > > Filename: draft-sinha-dispatch-sip-__continuation-option > Revision: 03 > Title: The Continue Header Field for the Session > Initiation > Protocol (SIP) > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > Before placing a call, it is quite often useful for the Caller to > know whether a Callee is in favorable state to receive a call or > not. This document defines an optional tag > "continue" and a > header > "Continue" to address the purpose. The > "Continue" > header field is > to confirm the session continuity with the Callee from the Caller > after an option for session continuity is placed by the > Callee based > on the unfavorable state of the Callee. This functionality > is needed > to resolve the unwillingness of the Callee to receive any > call. An > option is given to the Callee by the Service Provider or by the > Handset Manufacturer or by the Carrier to establish this > requirement. > > > > > > The IETF Secretariat > > > > _________________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/__listinfo/dispatch > > > > _________________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/__listinfo/dispatch > > > From dworley@avaya.com Tue Apr 10 10:56:10 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02CC11E8129 for ; Tue, 10 Apr 2012 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMBcBnzQZ6ll for ; Tue, 10 Apr 2012 10:56:09 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D071811E8123 for ; Tue, 10 Apr 2012 10:56:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABVzhE/GmAcF/2dsb2JhbABEDrkegQeCCQEBAQECARIoPQcLAgEIDQghBQshESUBAQQBEggTB4deAwYFnV6Taw2JU4okhVpjBJIGghGHaYUlhH2CMFM X-IronPort-AV: E=Sophos;i="4.75,400,1330923600"; d="scan'208";a="301211454" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Apr 2012 13:56:04 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Apr 2012 13:54:24 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 10 Apr 2012 13:56:04 -0400 From: "Worley, Dale R (Dale)" To: "amar deep" , "sunilkumarsinha9@rediffmail.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Date: Tue, 10 Apr 2012 13:55:44 -0400 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Thread-Index: Ac0WELPLvBCXC1qvT9qC4aSa7qOWpgBMnPJB Message-ID: References: <1333388849.S.7212.7312.H.TlBhdWwgS3l6aXZhdABSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I_.RU.rfs223, rfs223, 865, 19.f5-224-103.1333947130.27689@webmail.rediffmail.com>, <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> In-Reply-To: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:56:10 -0000 > From: Manjunath [manjugd@gmail.com] >=20 > [Answer]: For the type of problems we are addressing below i.e: >=20 > - How do we know the exact mood/state of a callee to place a > normal/Urgent/important call? As far as I can tell, you place great emphasis on the need for the callee to communicate his state to the caller. And that this is the reason that the "Priority" header in the INVITE is not a sufficient solution. This is not specified in a requirement in Amardeep's list of requirements. But I do not know of a justification that it is important for the callee to communicate his state to the caller. The caller knows before placing the call whether it is important enough to interrupt the callee. Knowing whether the callee is busy does not change that. One possibility is that ISDN can perform such an inquiry and it is desired to make SIP interwork directly with that ISDN capability. But despite the description in sections 7.6, I can find no reference to an ISDN implementation of this type of operation. ETSI TS 183 036 does not seem to contain the words "confirm", "confirmation", "urgent", or "emergency". The ISDN messages shown in section 7.6 do not seem to contain such indicators. Dale From mphmmr@gmail.com Tue Apr 10 16:40:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD1111E80DE for ; Tue, 10 Apr 2012 16:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyxrE+piOkAv for ; Tue, 10 Apr 2012 16:40:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1EB11E8081 for ; Tue, 10 Apr 2012 16:40:49 -0700 (PDT) Received: by lagj5 with SMTP id j5so280245lag.31 for ; Tue, 10 Apr 2012 16:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d+4pbjL6Nc5psqAN7NSqFqp/eTuWnHgRnI8rFWsg7kM=; b=ezrEP5TTRzPkQ9a/KPsbCfMlTkFGTyOWmUCqmM8WvJeJ0PVIlDSwQqdJQ/b8wzX+sv xs8e/OyOuADD1E36lwwy7p1O0+YftbnNIKOYfdzk6KrM++AnNKmAPbu+xZ1GUVcRqCrw l3ZcIKs4ymx4VqWpzv6O2CSRriXJtuSErlL6rmN1iNeIY2SjWUOW3UoLQvsbFaaZ4aeW HkuUlpoCJoB+JEvOVNlzvgGKwsePGLRB4uH2K3ZW1lL8xhUfumx2tMoX42uwt4OEWE3w +h06rXz29XZFGTS6ecyIyfVN59L7DxB+xuR7QyHhcZgkSJ5teCzOUDP/ogM111uFGbFG HkXw== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr17170242lab.35.1334101243169; Tue, 10 Apr 2012 16:40:43 -0700 (PDT) Received: by 10.112.85.129 with HTTP; Tue, 10 Apr 2012 16:40:43 -0700 (PDT) In-Reply-To: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> Date: Tue, 10 Apr 2012 19:40:43 -0400 Message-ID: From: Michael Hammer To: "Worley, Dale R (Dale)" Content-Type: multipart/alternative; boundary=f46d0430855ab18d1c04bd5ba6e3 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:40:50 -0000 --f46d0430855ab18d1c04bd5ba6e3 Content-Type: text/plain; charset=ISO-8859-1 This seems more like a Presence issue. We have protocols for that. Mike On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) wrote: > > From: Manjunath [manjugd@gmail.com] > > > > [Answer]: For the type of problems we are addressing below i.e: > > > > - How do we know the exact mood/state of a callee to place a > > normal/Urgent/important call? > > As far as I can tell, you place great emphasis on the need for the > callee to communicate his state to the caller. And that this is the > reason that the "Priority" header in the INVITE is not a sufficient > solution. > > This is not specified in a requirement in Amardeep's list of > requirements. > > But I do not know of a justification that it is important for the > callee to communicate his state to the caller. The caller knows > before placing the call whether it is important enough to interrupt > the callee. Knowing whether the callee is busy does not change that. > > One possibility is that ISDN can perform such an inquiry and it is > desired to make SIP interwork directly with that ISDN capability. But > despite the description in sections 7.6, I can find no reference to an > ISDN implementation of this type of operation. ETSI TS 183 036 does > not seem to contain the words "confirm", "confirmation", "urgent", or > "emergency". The ISDN messages shown in section 7.6 do not seem to > contain such indicators. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d0430855ab18d1c04bd5ba6e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems more like a Presence issue. =A0We have protocols for that.
<= br>
Mike


On Tue, Apr= 10, 2012 at 1:55 PM, Worley, Dale R (Dale) <dworley@avaya.com> wrote:
> From: Manjunath [manjugd@gmail.com]
>
> [Answer]: For the type of problems we are addressing below i.e:
>
> - How do we know the exact mood/state of a callee to place a
> =A0 normal/Urgent/important call?

As far as I can tell, you place great emphasis on the need for the
callee to communicate his state to the caller. =A0And that this is the
reason that the "Priority" header in the INVITE is not a sufficie= nt
solution.

This is not specified in a requirement in Amardeep's list of
requirements.

But I do not know of a justification that it is important for the
callee to communicate his state to the caller. =A0The caller knows
before placing the call whether it is important enough to interrupt
the callee. =A0Knowing whether the callee is busy does not change that.

One possibility is that ISDN can perform such an inquiry and it is
desired to make SIP interwork directly with that ISDN capability. =A0But despite the description in sections 7.6, I can find no reference to an
ISDN implementation of this type of operation. =A0ETSI TS 183 036 does
not seem to contain the words "confirm", "confirmation"= , "urgent", or
"emergency". =A0The ISDN messages shown in section 7.6 do not see= m to
contain such indicators.

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

--f46d0430855ab18d1c04bd5ba6e3-- From dworley@avaya.com Wed Apr 11 15:13:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3679611E8087 for ; Wed, 11 Apr 2012 15:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EnzKreI1pCQ for ; Wed, 11 Apr 2012 15:13:40 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 49A2411E8073 for ; Wed, 11 Apr 2012 15:13:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOkAhk/GmAcF/2dsb2JhbABEuVaBB4IJAQEBAQMBAQEPKDQJAhACAQgNAQMEAQEBHgUEByEGCxQJCAEBBA4FCBMHh14DCwudUJNJDQ6JQQSKK4ZnYwSSBoIRh2mFJYR9gwM X-IronPort-AV: E=Sophos;i="4.75,407,1330923600"; d="scan'208";a="3907414" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Apr 2012 18:13:34 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Apr 2012 18:11:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 11 Apr 2012 18:13:34 -0400 From: "Worley, Dale R (Dale)" To: Michael Hammer Date: Wed, 11 Apr 2012 18:12:07 -0400 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Thread-Index: Ac0Xc1qr89EUufk+TU+dSTdkW2mEhAAvMe3i Message-ID: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:13:41 -0000 I suppose we could incorporate "Yao's Millionaires' Problem" into the proto= col so that the UAs could compare the sender's "how important this call is" wit= h the receiver's "how busy I am", without either revealing to the other their= value. Dale ________________________________________ From: Michael Hammer [mphmmr@gmail.com] Sent: Tuesday, April 10, 2012 7:40 PM To: Worley, Dale R (Dale) Cc: amar deep; sunilkumarsinha9@rediffmail.com; pkyzivat@alum.mit.edu; disp= atch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispa= tch-sip-continuation-option-03.txt This seems more like a Presence issue. We have protocols for that. Mike On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) > wrote: > From: Manjunath [manjugd@gmail.com] > > [Answer]: For the type of problems we are addressing below i.e: > > - How do we know the exact mood/state of a callee to place a > normal/Urgent/important call? As far as I can tell, you place great emphasis on the need for the callee to communicate his state to the caller. And that this is the reason that the "Priority" header in the INVITE is not a sufficient solution. This is not specified in a requirement in Amardeep's list of requirements. But I do not know of a justification that it is important for the callee to communicate his state to the caller. The caller knows before placing the call whether it is important enough to interrupt the callee. Knowing whether the callee is busy does not change that. One possibility is that ISDN can perform such an inquiry and it is desired to make SIP interwork directly with that ISDN capability. But despite the description in sections 7.6, I can find no reference to an ISDN implementation of this type of operation. ETSI TS 183 036 does not seem to contain the words "confirm", "confirmation", "urgent", or "emergency". The ISDN messages shown in section 7.6 do not seem to contain such indicators. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Wed Apr 18 04:08:07 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E021F861D for ; Wed, 18 Apr 2012 04:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33-WJfdH6Qjk for ; Wed, 18 Apr 2012 04:08:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3521F860D for ; Wed, 18 Apr 2012 04:08:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-f6-4f8ea09176a9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B8.04.25560.190AE8F4; Wed, 18 Apr 2012 13:08:01 +0200 (CEST) Received: from [131.160.36.128] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 18 Apr 2012 13:08:01 +0200 Message-ID: <4F8EA090.1010400@ericsson.com> Date: Wed, 18 Apr 2012 14:08:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 11:08:07 -0000 Hi John Luc, it is important that the DISPATCH community understands how you would like to progress this draft so that they provide their input. Per RFC 2183, the registration of disposition types requires a Standards Track or an IESG-Approved Experimental RFC: http://www.iana.org/assignments/mail-cont-disp/mail-cont-disp.xml#mail-cont-disp-1 You draft seems to aim to become an Experimental RFC, right? I guess the reasons for this RFC to be Experimental are given in Section 1 of the draft, right? http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-08#section-1 I assume you considered Section 8 of RFC 5621 when deciding disposition types were the right tool for what you need to do: http://www.iana.org/assignments/media-types/application/3gpp-ims+xml Thanks, Gonzalo On 09/04/2012 5:47 PM, John-Luc Bakker wrote: > Dear Paul, Gonzalo, > > I received an editorial comment on this draft. The draft is referring to sections 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and 4.2.3. > > Have you had an oppertunity to further digest the draft in light of our previous offline discussion? > > Kind regards, > > John-Luc > > -----Original Message----- > From: John-Luc Bakker > Sent: Tuesday, March 27, 2012 12:37 PM > To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com > Cc: dispatch@ietf.org > Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) > > Dear all, > > I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handling available following offline discussion. Biggest addition is the new section 2.1 which aims to further motivate the need for the ID. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-08 > > I am looking forward to hearing about any concerns you may have. > > Kind regards, > > John-Luc > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of John-Luc Bakker > Sent: Tuesday, March 20, 2012 1:53 PM > To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com > Cc: dispatch@ietf.org; sipping > Subject: Re: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > > Hi, > > Thanks, Paul for reviewing the draft. > Appologies for having delayed this response. > > Let me address first the question about this being a SIPPING draft: I intend to ask Gonzallo to sponsor this draft. To collect any further comments and ensure visibility (sine the sipping list is obsolete), I have copied the DISPATCH list. > > See also inline with . > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Saturday, December 03, 2011 12:11 PM > To: John-Luc Bakker > Cc: sipping > Subject: Re: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > > I'm commenting on this on the (now obsolete) sipping list because this > has sipping in its name. This may not be the best place. I suppose an > alternative is rai. > > ISTM that there are three degrees of freedom here for identifying how to > process these bodies: > - content-disposition > - content-type > - the actual content of the body > > Of these, the content-disposition is the most heavy weight in terms of > mechanism, while the actual content of the body is the least heavy-weight. > > So, I wonder why you have chosen to use one content-type, that seems to > already contain distinct representations for the differing behaviors of > interest, and yet use distinct content-dispositions. I think you could > use a single content-disposition and get the same effect. > > I guess multiple content-dispositions might make sense if they are > processed by different entities, so that only the intended entities need > decode the body. > > The reason for having two content dispositions is because there are different behaviors for the same content-type when received by different entities. > There are two different entities that apply a different behavior when receiving the body, say behavior A and behavior B. However, XML elements present in the body trigger behavior A (in the abstract of the draft, behavior (2)) by entity A and if not present, no further behavior by entity A is specified in this draft. Other XML elements present in the body trigger one of a set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by entity B and if not present, no further behavior by entity B is specified in this draft. > > It would also make sense if the same identical body > representation was processed differently based on the > content-disposition. > > The bodies triggering the different behaviors are indeed not identical. > However, the content-dispositions are processed by different entities, which is a reason for proposing these content-disposition values. > > But I don't think either of those is the case here. So I would find it helpful if this draft explained why it chooses to use multiple content-dispositions. > > The draft illustrates that, in IMS, different entities receive bodies with the content-type, and apply different behaviors. The draft further suggests that the applicability of these values may be limited to IMS. Do you see a need for a general discussion of this approach since the applicability is limited to IMS? > > I also think it would be useful to say something about how you expect > the handling parameter to be used with these dispositions. If > handling=required (the default) is used, then any UA that gets this must > fail the request unless it is able to handle the body. If > handling=optional is specified, then that need not be so. > > The handling parameter is mentioned in RFC 3261 and this draft refers to that RFC. RFC 3261 refers to RFC 3204. This draft does not change the behavior and interpretation of the parameter and its values. It should not be necessary to repeat what has already been documented in RFC 3261. Do you see different behavior that goes beyond what has been documented? > > Thanks, > Paul > > On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Specification of 3GPP IM CN Subsystem XML body handling >> Author(s) : John-Luc Bakker >> Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> Pages : 7 >> Date : 2011-12-02 >> >> This document registers new disposition-types for the Content- >> Disposition header field that apply to the application/3gpp-ims+xml >> body used by 3GPP. The applicability of these content-disposition >> values are limited to 3GPP IMS. The application/3gpp-ims+xml body >> has the following three distinct uses: (1) for redirecting the >> emergency session to use a different domain (e.g. using a Circuit >> Switched call), (2) for delivering user profile specific information >> from the SIP registrar to an Application Server, and (3) for causing >> a UAC to attempt to re-register with the IMS. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > From manjugd@gmail.com Sun Apr 22 03:29:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8807921F85B8 for ; Sun, 22 Apr 2012 03:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGlN4iGe17Bo for ; Sun, 22 Apr 2012 03:29:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2167B21F85B6 for ; Sun, 22 Apr 2012 03:29:22 -0700 (PDT) Received: by iazz13 with SMTP id z13so18679341iaz.31 for ; Sun, 22 Apr 2012 03:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JvWNkr0QAm44FyGn40ECjei9M3PgK9fnv63gkBvUkvo=; b=OB/7LfwbV2thXA8jXVPgGZTcRH3mJqKEFqWadNELGUAjiFM1bH3YHTFaomSOpfnJp9 7cfU9gXDN3N3TeLmH/r7pAwjqPxokmjrq6cvekhJykigyUp6KT0PHJZ5hbJobuvc+0Bk iIZW933nGkAfbY3//g2LNdilVhl6RYpuNz+uwrYb6rm4zlL2pKQeLvF2LwxL8XIB352f Pz7ymD0Xq71amnDq+MAr0loILOF2XI5pD3+SdeT8SiLE+DgWZ4l2DT5NtHEs1t1l/pCA ZD5g28jcX8WA6uUOGMpLBD3eipzClftPb7O8TSmE10Lqyq42PZPMOWwhB3WmoBsLXrUn P6wg== MIME-Version: 1.0 Received: by 10.50.106.132 with SMTP id gu4mr3589535igb.59.1335090561626; Sun, 22 Apr 2012 03:29:21 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Sun, 22 Apr 2012 03:29:21 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42D3B369@ESESSCMS0356.eemea.ericsson.se> References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <4F79E624.7070200@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C42D3B369@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 22 Apr 2012 15:59:21 +0530 Message-ID: From: Manjunath To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8f3ba149ab31ed04be41fe22 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:29:23 -0000 --e89a8f3ba149ab31ed04be41fe22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for your prompt inputs. Please see my comments inline. On Tue, Apr 10, 2012 at 5:12 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Some initial questions: > > Q1. Why can't the caller, already when sending the initial INVITE, > indicate whether the call is important or not, in order for the callee to > take proper actions? Why does the callee have to tell the caller to give > that information? > > [Manjunath]: The Caller should not send the initial INVITE with high priority because particular call may be important for Caller but may not be important for Callee and also Caller is unknowingly disturbing the Callee. By our proposed mechanism, before actual session establishment, both Caller and Callee will come to one common point of agreement for urgent/important calls. > Q2. I don't think the usage of Require is correct. Require is used to > mandate support of a SIP extension, but in the PRACK/UPDATE the caller us= es > it to tell the callee that the call is important. > > [Manjunath]: Yes, you are absolutely right. Required header is used to mandate the support of SIP extensions. In our draft we have defined an optional tag =93continue=94 and a header =93Continue=94 to address the purpose. So we have used Continue header in t= he PRACK/UPDATE method of the caller to inform the callee that the call is important. > Q3. In the draft, the 182 response contains SDP (section 7.x). But, I > guess the callee will not start reserving resources until it has decided > whether it is going to accept the call. > > [Manjunath]: Yes agreed. We will change this in our next revision draft. > Q4: In the ABNF (section 5), you don't need to define the same value with > capital and small letters. > > [Manjunath]: Yes agreed. We will change this in our next revision draft. > Q5: I don't understand why the caller has to send PRACK in case of > Continue: no (section 7.2). Why not simply send CANCEL? > > [Manjunath]: Here we are taking extra care by providing additional option to the Caller either by dropping a VoiceMail OR by redirecting to some other number which was preset by Callee. This is the reason why we were not sending simply CANCEL message in case of Continue: no (section 7.2). > Regards, > > Christer > > > On 4/2/12 1:46 PM, sunil sinha wrote: > > Dear All, > > > > I have just made revision 3 of > > 'draft-sinha-dispatch-sip-continuation-option' available following > > offline discussion. Biggest addition is the new section 7.6 and 7.7 > > which aims to further inter-working scenario. > > > > You can find the HTML formatted version here: > > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-optio > > n-03 > > > > > > I am looking forward to hearing about any concerns you may have. > > > > Thanks & Regards, > > sunil kumar sinha > > > > > > > > > > > > ---------- Forwarded message ---------- > > From: ** > > > Date: Mon, Apr 2, 2012 at 3:41 PM > > Subject: New Version Notification for > > draft-sinha-dispatch-sip-continuation-option-03.txt > > To: sunilkumarsinha9@gmail.com > > Cc: sinha.amardeep@gmail.com , > > de_subhrajyoti@yahoo.co.uk > > > > > > A new version of I-D, > > draft-sinha-dispatch-sip-continuation-option-03.txt has been > > successfully submitted by Sunil Kumar Sinha and posted to the IETF > > repository. > > > > Filename: draft-sinha-dispatch-sip-continuation-option > > Revision: 03 > > Title: The Continue Header Field for the Session Initiation > > Protocol (SIP) > > Creation date: 2012-04-02 > > WG ID: Individual Submission > > Number of pages: 23 > > > > Abstract: > > Before placing a call, it is quite often useful for the Caller to > > know whether a Callee is in favorable state to receive a call or > > not. This document defines an optional tag "continue" and > > a header "Continue" to address the purpose. The > > "Continue" header field is > > to confirm the session continuity with the Callee from the Caller > > after an option for session continuity is placed by the Callee based > > on the unfavorable state of the Callee. This functionality is neede= d > > to resolve the unwillingness of the Callee to receive any call. An > > option is given to the Callee by the Service Provider or by the > > Handset Manufacturer or by the Carrier to establish this requirement= . > > > > > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --e89a8f3ba149ab31ed04be41fe22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Christer,

Thanks for your prompt inputs. Please see= my comments inline.



On Tue, Apr 10, 2012 at 5:12 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wro= te:
Hi,

Some initial questions:

Q1. Why can't the caller, already when sending the initial INVITE, indi= cate whether the call is important or not, in order for the callee to take = proper actions? Why does the callee have to tell the caller to give that in= formation?

[Manjunath]: The Caller should not send t= he initial INVITE with high priority because particular call may be important for Caller but may n= ot be important for Callee and also Caller is unknowingly disturbing the Calle= e.

By our proposed mechanism, before actual = session establishment, both Caller and Callee will come to one common point of agreement for urgent/imp= ortant calls.

=A0
Q2. I don't think the usage of Require is correct. Require is used to m= andate support of a SIP extension, but in the PRACK/UPDATE the caller uses = it to tell the callee that the call is important.

[Manjunath]: Yes, you are absolutely righ= t. Required header is used to mandate the support of SIP extensions.

In our draft we have defined an optional = tag =93continue=94 and a header =93Continue=94 to address the purpose. So we have used Continue head= er in the PRACK/UPDATE method of the caller to inform the callee that the call is important.

=A0
Q3. In the draft, the 182 response contains SDP (section 7.x). But, I guess= the callee will not start reserving resources until it has decided whether= it is going to accept the call.

[Manjunath]: Yes agreed. We will change t= his in our next revision draft.

=A0
Q4: In the ABNF (section 5), you don't need to define the same value wi= th capital and small letters.

[Manjunath]: Yes agreed. We will change t= his in our next revision draft.

=A0
Q5: I don't understand why the caller has to send PRACK in case of Cont= inue: no (section 7.2). Why not simply send CANCEL?

[Manjunath]: Here we are taking extra car= e by providing additional option to the Caller either by dropping a VoiceMail OR by redirecting to some other number which was preset by Callee.

This is the reason why we were not se=
nding simply CANCEL message in case of Continue: no (section 7.2).=A0
Regards,

Christer


On 4/2/12 1:46 PM, sunil sinha wrote:
> Dear All,
>
> I have just made revision 3 of
> 'draft-sinha-dispatch-sip-continuation-option' available follo= wing
> offline discussion. Biggest addition is the new section 7.6 and 7.7 > which aims to further inter-working scenario.
>
> You can find the HTML formatted version here:
> http://tools.ietf.org/html/draft-sinha-dispa= tch-sip-continuation-optio
> n-03
>
>
> I am looking forward to hearing about any concerns you may have.
>
> Thanks & Regards,
> sunil kumar sinha
>
>
>
>
>
> ---------- Forwarded message ----------
> From: ** <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Mon, Apr 2, 2012 at 3:41 PM
> Subject: New Version Notification for
> draft-sinha-dispatch-sip-continuation-option-03.txt
> To: su= nilkumarsinha9@gmail.com <mailto:sunilkumarsinha9@gmail.com>
> Cc: sinh= a.amardeep@gmail.com <mailto:sinha.amardeep@gmail.com>,
> de_sub= hrajyoti@yahoo.co.uk <mailto:de_subhrajyoti@yahoo.co.uk>
>
>
> A new version of I-D,
> draft-sinha-dispatch-sip-continuation-option-03.txt has been
> successfully submitted by Sunil Kumar Sinha and posted to the IETF
> repository.
>
> Filename: =A0 =A0 =A0 =A0draft-sinha-dispatch-sip-continuation-option<= br> > Revision: =A0 =A0 =A0 =A003
> Title: =A0 =A0 =A0 =A0 =A0 The Continue Header Field for the Session I= nitiation
> Protocol (SIP)
> Creation date: =A0 2012-04-02
> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 23
>
> Abstract:
> =A0 =A0Before placing a call, it is quite often useful for the Caller = to
> =A0 =A0know whether a Callee is in favorable state to receive a call o= r
> =A0 =A0not. This document defines an optional tag &quot;continue&a= mp;quot; and
> a header &quot;Continue&quot; to address the purpose. =A0The > &quot;Continue&quot; header field is
> =A0 =A0to confirm the session continuity with the Callee from the Call= er
> =A0 =A0after an option for session continuity is placed by the Callee = based
> =A0 =A0on the unfavorable state of the Callee. =A0This functionality i= s needed
> =A0 =A0to resolve the unwillingness of the Callee to receive any call.= An
> =A0 =A0option is given to the Callee by the Service Provider or by the=
> =A0 =A0Handset Manufacturer or by the Carrier to establish this requir= ement.
>
>
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

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

--e89a8f3ba149ab31ed04be41fe22-- From manjugd@gmail.com Sun Apr 22 03:34:05 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EFA21F8653 for ; Sun, 22 Apr 2012 03:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPuZUWASLl2A for ; Sun, 22 Apr 2012 03:34:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C96E821F8650 for ; Sun, 22 Apr 2012 03:34:04 -0700 (PDT) Received: by iazz13 with SMTP id z13so18682589iaz.31 for ; Sun, 22 Apr 2012 03:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ei9fjSdhWlEXjvjHeRSosFLgNGuX/Doq8MfW0c+655g=; b=gsL+KwSu9B0M0zp0xIMVkbJNobQcQfRD3FsCrCgJq5LDMzmhqZOGkOM4N1HO//xB8w DbITOq3gcoq6+yOEoz2JkiGSC8grCegzHSd1CAkdOTNz6/NEI+MajGa9fFIz9VnuuSzK cHqc/Sfskva/V9JTBHZJ5/i5Wk5A97OoqB3UD5AJS7cGv80M5dvSlb1bIivKCguyx6aM 3zWg4T6oHL5vkzm1YKSzTEDlyNsMM1hXgZxEAxQdCso25pfbXZd43Eb9RKyaEZt1ykQi JJf1XuYH1R95ctlNLilbtTSepHCx6fOEQqM2RAXaI3eCVMh0lTYpta/DcUejCtZhyMT0 V8ig== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr3532025igc.49.1335090844488; Sun, 22 Apr 2012 03:34:04 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Sun, 22 Apr 2012 03:34:04 -0700 (PDT) In-Reply-To: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> Date: Sun, 22 Apr 2012 16:04:04 +0530 Message-ID: From: Manjunath To: Michael Hammer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:34:05 -0000 Hi Mike, The use of PRESENCE with UAC clients restricted to higher end-mobile devices. It is also not necessary that caller and callee both would be in each-other=92s buddy list OR connected to the same social networks. It need not be necessary that call is between two known persons. Thanks & Best Regards - Manjunath On Wed, Apr 11, 2012 at 5:10 AM, Michael Hammer wrote: > > This seems more like a Presence issue. =A0We have protocols for that. > > > Mike > > > On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) wrote: >> >> > From: Manjunath [manjugd@gmail.com] >> > >> > [Answer]: For the type of problems we are addressing below i.e: >> > >> > - How do we know the exact mood/state of a callee to place a >> > =A0 normal/Urgent/important call? >> >> As far as I can tell, you place great emphasis on the need for the >> callee to communicate his state to the caller. =A0And that this is the >> reason that the "Priority" header in the INVITE is not a sufficient >> solution. >> >> This is not specified in a requirement in Amardeep's list of >> requirements. >> >> But I do not know of a justification that it is important for the >> callee to communicate his state to the caller. =A0The caller knows >> before placing the call whether it is important enough to interrupt >> the callee. =A0Knowing whether the callee is busy does not change that. >> >> One possibility is that ISDN can perform such an inquiry and it is >> desired to make SIP interwork directly with that ISDN capability. =A0But >> despite the description in sections 7.6, I can find no reference to an >> ISDN implementation of this type of operation. =A0ETSI TS 183 036 does >> not seem to contain the words "confirm", "confirmation", "urgent", or >> "emergency". =A0The ISDN messages shown in section 7.6 do not seem to >> contain such indicators. >> >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From manjugd@gmail.com Sun Apr 22 03:36:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1521F8527 for ; Sun, 22 Apr 2012 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+W5Np95bcEM for ; Sun, 22 Apr 2012 03:36:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4868121F84C8 for ; Sun, 22 Apr 2012 03:36:06 -0700 (PDT) Received: by iazz13 with SMTP id z13so18683917iaz.31 for ; Sun, 22 Apr 2012 03:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SjMVCOpR0VzswixJptqbnjtJGZKkRvKhahCzqIkwWJo=; b=HfC/ltnUK6pMYbLx6zLn5UZxzkl73PaEoKYp53lNXxcAgdWQ4Cbf8E4FpcFq4gS9Y0 lT0HkbI/xxHLC3IyvZTrI95bdi2bq/R0fczyGdJwYBThXpGNNiMPUtY5190DMHPqhnlJ fK6mh8fMGySqx6EjQtoJe5ZSzk9j8Zp9PpR7oQcEa/MUCgyBPbTEA4RfdsOMhCi8Vk3S HtfdqAPBd7UQ0eD5apRn2ZI7euzI1QDTyWAhOskFfn2273KMZ5t1QIVQV5vAL51o6Z20 LU8v3aPoQF5y40rEEWnNtOAV40hgNSSC3TjjX0hJ4Hz6I+t+eQAPXURK1lCxnw3yGFLh H4Hw== MIME-Version: 1.0 Received: by 10.50.106.132 with SMTP id gu4mr3601385igb.59.1335090965922; Sun, 22 Apr 2012 03:36:05 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Sun, 22 Apr 2012 03:36:05 -0700 (PDT) In-Reply-To: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> Date: Sun, 22 Apr 2012 16:06:05 +0530 Message-ID: From: Manjunath To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , Michael Hammer Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:36:07 -0000 Hi Dale, As per our understanding Yao=92s millionaire problem works only when both parties know each other well in advance but in our case we can get calls from unknown users. Here we are talking about the scenarios/use cases where caller is not in callee=92s=A0 favourite/buddy list and caller wants to know the favourable state OR willingness of the callee before placing the call. Thanks & Best Regards - Manjunath On Thu, Apr 12, 2012 at 3:42 AM, Worley, Dale R (Dale) wrote: > > I suppose we could incorporate "Yao's Millionaires' Problem" into the pro= tocol > so that the UAs could compare the sender's "how important this call is" w= ith > the receiver's "how busy I am", without either revealing to the other the= ir value. > > Dale > > ________________________________________ > From: Michael Hammer [mphmmr@gmail.com] > Sent: Tuesday, April 10, 2012 7:40 PM > To: Worley, Dale R (Dale) > Cc: amar deep; sunilkumarsinha9@rediffmail.com; pkyzivat@alum.mit.edu; di= spatch@ietf.org > Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dis= patch-sip-continuation-option-03.txt > > This seems more like a Presence issue. =A0We have protocols for that. > > Mike > > > On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) > wrote: > > From: Manjunath [manjugd@gmail.com] > > > > [Answer]: For the type of problems we are addressing below i.e: > > > > - How do we know the exact mood/state of a callee to place a > > =A0 normal/Urgent/important call? > > As far as I can tell, you place great emphasis on the need for the > callee to communicate his state to the caller. =A0And that this is the > reason that the "Priority" header in the INVITE is not a sufficient > solution. > > This is not specified in a requirement in Amardeep's list of > requirements. > > But I do not know of a justification that it is important for the > callee to communicate his state to the caller. =A0The caller knows > before placing the call whether it is important enough to interrupt > the callee. =A0Knowing whether the callee is busy does not change that. > > One possibility is that ISDN can perform such an inquiry and it is > desired to make SIP interwork directly with that ISDN capability. =A0But > despite the description in sections 7.6, I can find no reference to an > ISDN implementation of this type of operation. =A0ETSI TS 183 036 does > not seem to contain the words "confirm", "confirmation", "urgent", or > "emergency". =A0The ISDN messages shown in section 7.6 do not seem to > contain such indicators. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From manjugd@gmail.com Sun Apr 22 03:41:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2192D21F860E for ; Sun, 22 Apr 2012 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEe-h9PgTv9l for ; Sun, 22 Apr 2012 03:41:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE821F84F0 for ; Sun, 22 Apr 2012 03:41:27 -0700 (PDT) Received: by iazz13 with SMTP id z13so18687338iaz.31 for ; Sun, 22 Apr 2012 03:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G/+osUkeF+jcGmdgBqr3M166QSdPOzCfysk7zWarZv4=; b=m9xOa84/UKUEvUpmrzGIrStZrEmTJluSzbKbfY1+uvSAML5pIBsTCb5668k9Blp6Ec 6xISycBJdXMokLWBqw0n/h5TV/CIe+f8wvmEMYu1xP9AxFFzFWtxbvyE63O7M4cmeEsO qKHXHL5W5eboQ6Fb60SQtm1PWWB+svQjfT1/HgVSpOWI4hcW1h3gJZSa4cN95X3mEUxL aAs9y5Xmgxb+XfOBj2QuL3P47+GHoslznKaFcphgw6KvaVPNX65RGvDfj9dEv1gCFVlw gs78n2yngRawZyAC7vgZBQG9yrTD9W0dCpbgAb4HKZgnKIxjp4Fs+FcpU6aHm3nv8mr3 Ivww== MIME-Version: 1.0 Received: by 10.50.193.199 with SMTP id hq7mr3548115igc.49.1335091287060; Sun, 22 Apr 2012 03:41:27 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Sun, 22 Apr 2012 03:41:27 -0700 (PDT) In-Reply-To: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> Date: Sun, 22 Apr 2012 16:11:27 +0530 Message-ID: From: Manjunath To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:41:28 -0000 Hi Dale, Thanks for your prompt inputs. Please see my comments inline. On Tue, Apr 10, 2012 at 11:25 PM, Worley, Dale R (Dale) wrote: > > > From: Manjunath [manjugd@gmail.com] > > > > [Answer]: For the type of problems we are addressing below i.e: > > > > - How do we know the exact mood/state of a callee to place a > > =A0 normal/Urgent/important call? > > As far as I can tell, you place great emphasis on the need for the > callee to communicate his state to the caller. =A0And that this is the > reason that the "Priority" header in the INVITE is not a sufficient > solution. > [Manjunath] : Yes true. We also feel the same. > > This is not specified in a requirement in Amardeep's list of > requirements. > [Manjunath] :What Amardeep sent earlier was just the consolidated requirement list. > But I do not know of a justification that it is important for the > callee to communicate his state to the caller. =A0The caller knows > before placing the call whether it is important enough to interrupt > the callee. =A0Knowing whether the callee is busy does not change that. > [Manjunath] : Yes it would be important for the callee to communicate his state to the caller because that particular call at that moment may not be important for callee. Yes, the caller knows before placing the call whether it is important enough to interrupt the callee. And knowing whether the calee is busy (DND set) the caller will not change his/her state. That means caller wants callee to answer his/her URGENT call. And this is only possible when callee notice the alert OR pop-up message or light blink. If callee missed OR unnoticed pop-up message OR light blink then callee will not answer the caller=92s URGENT call even though the caller has sent the request with High priority. So if callee sets NDDND (as defined in draft) we can overcome this problem. > One possibility is that ISDN can perform such an inquiry and it is > desired to make SIP interwork directly with that ISDN capability. =A0But > despite the description in sections 7.6, I can find no reference to an > ISDN implementation of this type of operation. =A0ETSI TS 183 036 does > not seem to contain the words "confirm", "confirmation", "urgent", or > "emergency". =A0The ISDN messages shown in section 7.6 do not seem to > contain such indicators. > [Manjunath] : True, this document (ETSI TS 183 036) is for the reference for ISDN. And ITU may refer the example 7.6 if they wish to implement NDDND and =93Call Continuation=94 features. > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From manjugd@gmail.com Sun Apr 22 04:27:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260C621F860D for ; Sun, 22 Apr 2012 04:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-1.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY3Lt4xXtHRL for ; Sun, 22 Apr 2012 04:26:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4773921F85F9 for ; Sun, 22 Apr 2012 04:26:58 -0700 (PDT) Received: by iazz13 with SMTP id z13so18717415iaz.31 for ; Sun, 22 Apr 2012 04:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m7m/z//ac4Vmx7CoKBq9JUhKI/Yj+rIg/nGICy7uqng=; b=O35gOcMdpoCT0yUOJQoq6DiRHCDyJDMYnLoPTBVQp7uOiyf9gMau8uog0h6N6LHY8N S2t4e6oVX/LTwEgo0dNsJRa6Qitd1tBdc10t6hR6qfeuiHtfUNGtETPk2YazrEaxtppR ieHZg8CT9crT/u0oTxwMNbeJzfA7DIsWK2SaNT/UJMem7xXzcAj2/040RwmlgrrKuyhn 63vzZdiRoltF+nkRIuzFFlDQykGfboKzemRYZJQWpfY4A38fvGo4ukJAPLRF4Qxu81VR rKY43vFZbJFci8Ob1pjji9uvdlsfYAKdKN1Gqc745nimQq4kNiTHig6oy/Pl1HPa/cPI Xtig== MIME-Version: 1.0 Received: by 10.50.187.169 with SMTP id ft9mr3693955igc.59.1335094010801; Sun, 22 Apr 2012 04:26:50 -0700 (PDT) Received: by 10.231.66.204 with HTTP; Sun, 22 Apr 2012 04:26:50 -0700 (PDT) In-Reply-To: <4F82DDC6.4000704@alum.mit.edu> References: <1333947130.S.10083.16336.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 401, 114.f5-224-169.old.1333948912.23738@webmail.rediffmail.com> <4F82DDC6.4000704@alum.mit.edu> Date: Sun, 22 Apr 2012 16:56:50 +0530 Message-ID: From: Manjunath To: Paul Kyzivat Content-Type: multipart/alternative; boundary=14dae9340575416d8704be42ccfa Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 11:27:00 -0000 --14dae9340575416d8704be42ccfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for your prompt inputs. Please see my comments inline. On Mon, Apr 9, 2012 at 6:31 PM, Paul Kyzivat wrote: > On 4/9/12 1:21 AM, amar deep wrote: >> >> Hi Paul, >> >> Problem : >> -REQ-1: Callee wants no urgent call for him should get rejected when he >> set DnD status =3DON, & he fail to notice beep/flash over the phone. > > > Do you have a standard definition of DnD status? Or is your DnD mechanism > proprietary? > >*[Manjunath] : Here we are not touching standard DND mechanism at all.* >> -REQ-2: Caller wants call to get connected only if callee is >> free/available =E2=80=93 for normal/urgent/emergency call >> -REQ-3: Caller don=E2=80=99t wants call to get connected to Callee when = is BUSY >> =E2=80=93 for Normal call >> -REQ-4: Caller wants call to get connected what so ever is state of >> callee is =E2=80=93 for urgent/emergency call >> >> Problem-Solution justification with Continue -Why problem need to be >> solved: >> -Based on call type(normal/urgent/emergency), caller can make decision >> to go with call setup or not >> -Based on callee status, caller can make decision to go with call setup >> or not >> -Decision of have call setup successful based on call priority is vested >> within Caller decision not on feature configuration >> >> Using Priority header: >> -Using Priority headers is not run time bases, its depends on call >> service and pre-configured call setting > > > I don't understand your comment about the Priority header. It seems to me > that you can obtain all the behaviors you describe in your requirements and > in your problem solution justification simply by the caller setting the > Priority header and the callee taking it into account. > *[Manjunath] : Here we mean to say the limitations of Priority Header. With Priority Header there are two use cases which have limitations: CASE 1: Caller sends PRIORITY =3DHIGH and Callee don=E2=80=99t have DND Ena= bled In this case/scenario we would miss couple of things: a.) Caller does not know the state/mood of Callee before placing a call. b.) Particular Call may be important for Caller but may not be important for Callee and also Caller is unknowingly disturbing the Callee. CASE2: Caller sends PRIORITY =3DHIGH and Callee have DND Enabled with Ringe= r off** In this case/scenario also we would be missing couple of things: a.) If Callee does not notice Pop- up message that means Callee is ready to take a HIGH risk to miss any URGENT call. b.) Particular Call might be important for Caller but might not be important for Callee. * > >> -Initial request from caller is MARKED if it=E2=80=99s a high priority c= all or >> not =E2=80=93 mainly addressing emergency situation.The priority header = filed >> mainly address to =E2=80=9Cresources that may become scarce and congeste= d during >> emergencies. These resources include gateway resources, circuit-switched >> network resources, IP network resources, receiving end system resources >> and SIP proxy resources. =E2=80=9C. > > > You seem to be describing the Resource-Priority header, not the Priority > header. They are different. > *[Manjunath] : Yes, I completely agree both are different. We are talking about ONLY priority header.* > >> -It doesn=E2=80=99t address above Requirement/problem, wherein call is m= ade >> high-priority based on callee availability/willingness and caller >> decision about call catergory based on call-type >> >> Using 403 Forbidden /or New Response Code: >> -For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX, >> make call discontinue irrespective of call-type urgency >> normal/urgent/emergency >> -Response code of 3XX, 4XX, 5XX & 6XX category =E2=80=93 don=E2=80=99t g= ive option to >> caller to make decision for call continuation or for termination > > > You have two choices of how to use these mechanisms to accomplish your > objective: > > 1) if the caller knows a priori that the call is high priority then he ca= n > instruct his phone to include a suitable Priority header value in the cal= l > initially. *[Manjunath] : If Caller sends initial INVITE with high priority then in that case the call may be important for Caller but may not be important for Callee. Also Caller is unknowingly disturbing the Callee without knowing the favourable state of Callee before placing a call. * > 2) the caller can always try calls first with normal priority. If the cal= l > fails with a response code that indicates that it was rejected because it= s > priority was insufficient, then the phone can report this to the user, wh= o > can retry the call with the priority set appropriately. There are numerou= s > possibilities for how the user interface would look for this. The exact code > used to indicate that the call was rejected for insufficient priority can be > refined if you want to pursue this approach. > *[Manjunath] : When Caller tries calls with normal priority and get rejected because of priority insufficient this is because the Callee is in DND mode. Now, again when Caller retry the call with High priority set that means Caller wants the Callee to answer his/her ONLY URGENT call. And this is possible only when Callee notices the pop-up message OR light blink as Callee is in DND mode. If Callee missed OR unnoticed that pop-up message OR light blink then Callee will not answer the Caller=E2=80=99s URGENT call ev= en though the Caller has sent the request with High priority. * > Thanks, > Paul > >> ISDN interoperability: >> -This section is added at 7.6 and 7.7 section of the draft document, to >> state that this feature is not limited only from VoIP call >> -This feature proposed within the draft document, works across network >> type as well. >> >> Thanks, >> Amardeep >> >> -- Original Message -- >> > >> >> > >> From: Paul Kyzivat pkyzivat@alum.mit.edu >> > >> To: dispatch@ietf.org >> > >> Subject: Re: [dispatch] Fwd: New Version Notification for >> draft-sinha-dispatch-sip-continuation-option-03.txt >> >> >> FollowRediff Deal ho jaye!to get exciting offers in your city everyday. >> Sunil, >> >> >> >> Looking back, I see that you had replied to my comments on the earlier >> >> version of this draft and I never responded. >> >> >> >> To summarize, the problem I have with this draft is that you leap to a >> >> particular mechanism to solve a problem without having justified why >> >> that solution is better than other possible solutions to the same >> >> problem. And also without having sufficiently motivated people about why >> >> this is a problem that needs solving. >> >> >> >> Your latest update, with the ISDN interoperability example, suggests >> >> that ISDN interoperability might be driving the way you frame the >> >> problem. If so it would be good for you to explain that. >> >> >> >> It still seems to me that this could be solved with less new mechanism. >> >> The Priority header, plus an existing response (e.g. 403 Forbidden plus >> >> an exiting or new Warning header) or a new response code. >> >> >> >> Thanks, >> >> Paul >> >> >> >> On 4/2/12 1:46 PM, sunil sinha wrote: >> >> > Dear All, >> >> > >> >> > I have just made revision 3 of >> >> > =EF=BF=BDdraft-sinha-dispatch-sip-continuation-option=EF=BF=BD availa= ble following >> >> > offline discussion. Biggest addition is the new section 7.6 and 7.7 >> >> > which aims to further inter-working scenario. >> >> > >> >> > You can find the HTML formatted version here: >> >> > >> http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 >> >> > >> >> > >> >> > I am looking forward to hearing about any concerns you may have. >> >> > >> >> > Thanks & Regards, >> >> > sunil kumar sinha >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > ---------- Forwarded message ---------- >> >> > From: ** > >> >> > Date: Mon, Apr 2, 2012 at 3:41 PM >> >> > Subject: New Version Notification for >> >> > draft-sinha-dispatch-sip-continuation-option-03.txt >> >> > To: sunilkumarsinha9@gmail.com >> >> > Cc: sinha.amardeep@gmail.com , >> >> > de_subhrajyoti@yahoo.co.uk >> >> > >> >> > >> >> > A new version of I-D, >> >> > draft-sinha-dispatch-sip-continuation-option-03.txt has been >> >> > successfully submitted by Sunil Kumar Sinha and posted to the IETF >> >> > repository. >> >> > >> >> > Filename: draft-sinha-dispatch-sip-continuation-option >> >> > Revision: 03 >> >> > Title: The Continue Header Field for the Session Initiation >> >> > Protocol (SIP) >> >> > Creation date: 2012-04-02 >> >> > WG ID: Individual Submission >> >> > Number of pages: 23 >> >> > >> >> > Abstract: >> >> > Before placing a call, it is quite often useful for the Caller to >> >> > know whether a Callee is in favorable state to receive a call or >> >> > not. This document defines an optional tag "continue" and a >> >> > header >> >> > "Continue" to address the purpose. The "Continue" >> >> > header field is >> >> > to confirm the session continuity with the Callee from the Caller >> >> > after an option for session continuity is placed by the Callee based >> >> > on the unfavorable state of the Callee. This functionality is needed >> >> > to resolve the unwillingness of the Callee to receive any call. An >> >> > option is given to the Callee by the Service Provider or by the >> >> > Handset Manufacturer or by the Carrier to establish this requirement. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > The IETF Secretariat >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > dispatch mailing list >> >> > dispatch@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> Amar >> >> >> < http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/sign= atureline.htm@Middle ?> >> >> Follow *_Rediff Deal ho jaye! >> >> < http://track.rediff.com/click?url=3D___http://dealhojaye.rediff.com?sc_cid= =3Drediffmailsignature___&cmp=3Dsignature&lnk=3Drediffmailsignature&newserv= ice=3Ddeals >_* >> >> to get exciting offers in your city everyday. >> > --14dae9340575416d8704be42ccfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul,

Thanks for your prompt inputs. Please see my comments inlin= e.

On Mon, Apr 9, 2012 at 6:31 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> On 4/= 9/12 1:21 AM, amar deep wrote:
>>
>> Hi Paul,
>>
>> Problem :
>>= -REQ-1: Callee wants no urgent call for him should get rejected when he>> set DnD status =3DON, & he fail to notice beep/flash over the= phone.
>
>
> Do you have a standard definition of DnD status? Or is= your DnD mechanism
> proprietary?
>
>[Manjunath] : He= re we are not touching standard DND mechanism at all.

>> -= REQ-2: Caller wants call to get connected only if callee is
>> free/available =E2=80=93 for normal/urgent/emergency call
>&= gt; -REQ-3: Caller don=E2=80=99t wants call to get connected to Callee when= is BUSY
>> =E2=80=93 for Normal call
>> -REQ-4: Caller w= ants call to get connected what so ever is state of
>> callee is =E2=80=93 for urgent/emergency call
>>
>&= gt; Problem-Solution justification with Continue -Why problem need to be>> solved:
>> -Based on call type(normal/urgent/emergency),= caller can make decision
>> to go with call setup or not
>> -Based on callee status, = caller can make decision to go with call setup
>> or not
>&g= t; -Decision of have call setup successful based on call priority is vested=
>> within Caller decision not on feature configuration
>>>> Using Priority header:
>> -Using Priority headers is not= run time bases, its depends on call
>> service and pre-configured= call setting
>
>
> I don't understand your comment about the Priority= header. It seems to me
> that you can obtain all the behaviors you d= escribe in your requirements and
> in your problem solution justifica= tion simply by the caller setting the
> Priority header and the callee taking it into account.
>

= [Manjunath] : Here we mean to say the limitations of Priority Header. Wi= th Priority Header there are two use cases which have limitations:

=C2=A0
CASE 1: Caller sends PRIORITY =3DHIGH and Callee don=E2=80=99t= have DND Enabled

In this case/scenario we would miss couple of = things:

a.)=C2=A0=C2=A0=C2=A0 Caller does not know the state/mood of= Callee before placing a call.

b.)=C2=A0=C2=A0 Particular Call may be important for Caller but may not= be important for Callee and also Caller is unknowingly disturbing the Call= ee.

=C2=A0

CASE2: Caller sends PRIORITY =3DHIGH and Callee= have DND Enabled with Ringer off

In this case/scenario also we would be missing couple of things:
a.)=C2=A0=C2=A0=C2=A0 If Callee does not notice Pop- up message that means= Callee is ready to take a HIGH risk to miss any URGENT call.

b.)=C2= =A0=C2=A0 Particular Call might be important for Caller but might not be im= portant for Callee.


>
>> -Initial request from caller is MARKED if it= =E2=80=99s a high priority call or
>> not =E2=80=93 mainly address= ing emergency situation.The priority header filed
>> mainly addres= s to =E2=80=9Cresources that may become scarce and congested during
>> emergencies. These resources include gateway resources, circuit-sw= itched
>> network resources, IP network resources, receiving end s= ystem resources
>> and SIP proxy resources. =E2=80=9C.
>
= >
> You seem to be describing the Resource-Priority header, not the Priori= ty
> header. They are different.
>

[Manjunath] : Yes,= I completely agree both are different. We are talking about ONLY priority = header.


>
>> -It doesn=E2=80=99t address above Requirement/prob= lem, wherein call is made
>> high-priority based on callee availab= ility/willingness and caller
>> decision about call catergory base= d on call-type
>>
>> Using 403 Forbidden /or New Response Code:
>>= -For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX= ,
>> make call discontinue irrespective of call-type urgency
>> normal/urgent/emergency
>> -Response code of 3XX, 4XX, 5X= X & 6XX category =E2=80=93 don=E2=80=99t give option to
>> cal= ler to make decision for call continuation or for termination
>
&g= t;
> You have two choices of how to use these mechanisms to accomplis= h your
> objective:
>
> 1) if the caller knows a priori that the ca= ll is high priority then he can
> instruct his phone to include a sui= table Priority header value in the call
> initially.


[M= anjunath] : If Caller sends initial INVITE with high priority then in that = case the call may be important for Caller but may not be important for Call= ee. Also Caller is unknowingly disturbing the Callee without knowing the fa= vourable state of Callee before placing a call.


> 2) the caller can always try calls first with normal prior= ity. If the call
> fails with a response code that indicates that it = was rejected because its
> priority was insufficient, then the phone = can report this to the user, who
> can retry the call with the priority set appropriately. There are nume= rous
> possibilities for how the user interface would look for this. = The exact code
> used to indicate that the call was rejected for insu= fficient priority can be
> refined if you want to pursue this approach.
>

[Manjun= ath] : When Caller tries calls with normal priority and get rejected becaus= e of priority insufficient this is because the Callee is in DND mode.

Now, again =C2=A0when Caller retry the call with High priority set that= means Caller wants the=C2=A0 Callee to answer his/her ONLY URGENT call. An= d this is possible only when Callee notices the pop-up message OR light bli= nk as Callee is in DND mode. If Callee missed OR unnoticed that pop-up mess= age OR light blink then Callee will not answer the Caller=E2=80=99s URGENT = call even though the Caller has sent the request with High priority.


> =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0Paul
>
>> ISDN interoperability:
>> -T= his section is added at 7.6 and 7.7 section of the draft document, to
&g= t;> state that this feature is not limited only from VoIP call
>> -This feature proposed within the draft document, works across net= work
>> type as well.
>>
>> Thanks,
>> = Amardeep
>>
>> -- Original Message --
>> =C2=A0&= gt;
>>
>> =C2=A0>
>> From: Paul Kyzivat pkyzivat@alum.mit.edu
>> =C2=A0&g= t;
>> To: dispatch@ietf.org
>> =C2=A0>
>> Subject: Re: [dispatch] Fwd: New Version Notification for
>&= gt; draft-sinha-dispatch-sip-continuation-option-03.txt
>>
>= >
>> FollowRediff Deal ho jaye!to get exciting offers in your c= ity everyday.
>> Sunil,
>>
>>
>>
>> Looking bac= k, I see that you had replied to my comments on the earlier
>>
= >> version of this draft and I never responded.
>>
>&g= t;
>>
>> To summarize, the problem I have with this draft is th= at you leap to a
>>
>> particular mechanism to solve a pr= oblem without having justified why
>>
>> that solution is= better than other possible solutions to the same
>>
>> problem. And also without having sufficiently motivate= d people about why
>>
>> this is a problem that needs sol= ving.
>>
>>
>>
>> Your latest update, w= ith the ISDN interoperability example, suggests
>>
>> that ISDN interoperability might be driving the way yo= u frame the
>>
>> problem. If so it would be good for you= to explain that.
>>
>>
>>
>> It still = seems to me that this could be solved with less new mechanism.
>>
>> The Priority header, plus an existing response (e.g. 4= 03 Forbidden plus
>>
>> an exiting or new Warning header)= or a new response code.
>>
>>
>>
>> Th= anks,
>>
>> Paul
>>
>>
>>
>> O= n 4/2/12 1:46 PM, sunil sinha wrote:
>>
>> =C2=A0> Dea= r All,
>>
>> =C2=A0>
>>
>> =C2=A0>= ; I have just made revision 3 of
>>
>> =C2=A0> =EF=BF=BDdraft-sinha-dispatch-sip-continuat= ion-option=EF=BF=BD available following
>>
>> =C2=A0> = offline discussion. Biggest addition is the new section 7.6 and 7.7
>= >
>> =C2=A0> which aims to further inter-working scenario. >>
>> =C2=A0>
>>
>> =C2=A0> You can = find the HTML formatted version here:
>>
>> =C2=A0>>> http://tools.ietf.org/html/draft-sinha-dispatch-sip-c= ontinuation-option-03
>>
>> =C2=A0>
>>
>> =C2=A0>
>&= gt;
>> =C2=A0> I am looking forward to hearing about any concer= ns you may have.
>>
>> =C2=A0>
>>
>>= =C2=A0> Thanks & Regards,
>>
>> =C2=A0> sunil kumar sinha
>>
>> = =C2=A0>
>>
>> =C2=A0>
>>
>> =C2= =A0>
>>
>> =C2=A0>
>>
>> =C2=A0&g= t;
>>
>> =C2=A0> ---------- Forwarded message --------= --
>>
>> =C2=A0> From: ** >
>>
>> =C2= =A0> Date: Mon, Apr 2, 2012 at 3:41 PM
>>
>> =C2=A0>= ; Subject: New Version Notification for
>>
>> =C2=A0> = draft-sinha-dispatch-sip-continuation-option-03.txt
>>
>> =C2=A0> To: sunilkumarsinha9@gmail.com
>>
>> =C2=A0> Cc= : sinha.amardeep@gmail.com = ,
>>
>> =C2=A0> de_subhra= jyoti@yahoo.co.uk
>>
>> =C2=A0>
>>
>= ;> =C2=A0>
>>
>> =C2=A0> A new version of I-D,>>
>> =C2=A0> draft-sinha-dispatch-sip-continuation-opt= ion-03.txt has been
>>
>> =C2=A0> successfully submitted by Sunil Kumar Sinha= and posted to the IETF
>>
>> =C2=A0> repository.
&= gt;>
>> =C2=A0>
>>
>> =C2=A0> Filename:= draft-sinha-dispatch-sip-continuation-option
>>
>> =C2=A0> Revision: 03
>>
>> =C2=A0= > Title: The Continue Header Field for the Session Initiation
>>= ;
>> =C2=A0> Protocol (SIP)
>>
>> =C2=A0> = Creation date: 2012-04-02
>>
>> =C2=A0> WG ID: Individual Submission
>>>> =C2=A0> Number of pages: 23
>>
>> =C2=A0>=
>>
>> =C2=A0> Abstract:
>>
>> =C2= =A0> Before placing a call, it is quite often useful for the Caller to >>
>> =C2=A0> know whether a Callee is in favorable state= to receive a call or
>>
>> =C2=A0> not. This document= defines an optional tag "continue" and a
>>
>>= =C2=A0> header
>>
>> =C2=A0> "Continue" to address the purpose= . The "Continue"
>>
>> =C2=A0> header field = is
>>
>> =C2=A0> to confirm the session continuity wit= h the Callee from the Caller
>>
>> =C2=A0> after an option for session continuity is p= laced by the Callee based
>>
>> =C2=A0> on the unfavor= able state of the Callee. This functionality is needed
>>
>&= gt; =C2=A0> to resolve the unwillingness of the Callee to receive any ca= ll. An
>>
>> =C2=A0> option is given to the Callee by the Servic= e Provider or by the
>>
>> =C2=A0> Handset Manufacture= r or by the Carrier to establish this requirement.
>>
>> = =C2=A0>
>>
>> =C2=A0>
>>
>> =C2=A0>
>&= gt;
>> =C2=A0>
>>
>> =C2=A0>
>>>> =C2=A0> The IETF Secretariat
>>
>> =C2=A0&g= t;
>>
>> =C2=A0>
>>
>> =C2=A0>
>>
>> =C2=A0> ________= _______________________________________
>>
>> =C2=A0> = dispatch mailing list
>>
>> =C2=A0> dispatch@ietf.org
>>
>> =C2=A0> https://www.ietf.org/mailman/listinfo/dispatch
>&= gt;
>>
>>
>> ___________________________________= ____________
>>
>> dispatch mailing list
>>
>> dispatch@ietf.org
>>
>>= https://www.iet= f.org/mailman/listinfo/dispatch
>>
>>
>> Amar
>>
>>
>> &= lt;http://sigads.rediff.com/RealMedia/ads/= click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
>>
>> Follow *_Rediff Deal ho jaye!
>>
>> = <http://track.rediff.com/click?url=3D= ___http://dealhojaye.rediff.com?sc_cid=3Drediffmailsignature___&cmp=3Ds= ignature&lnk=3Drediffmailsignature&newservice=3Ddeals>_*
>>
>> to get exciting offers in your city everyday.
>&= gt;
> --14dae9340575416d8704be42ccfa-- From pkyzivat@alum.mit.edu Sun Apr 22 13:20:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A813E21F85A1 for ; Sun, 22 Apr 2012 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUpSQrpjWP8R for ; Sun, 22 Apr 2012 13:20:39 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5859321F8595 for ; Sun, 22 Apr 2012 13:20:38 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id 17JX1j0081uE5Es568Lfu4; Sun, 22 Apr 2012 20:20:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 18Lf1j00C07duvL3c8LgGJ; Sun, 22 Apr 2012 20:20:40 +0000 Message-ID: <4F946815.9080805@alum.mit.edu> Date: Sun, 22 Apr 2012 16:20:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20120402101135.24670.80457.idtracker@ietfa.amsl.com> <4F79E624.7070200@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C42D3B369@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 20:20:41 -0000 On 4/22/12 6:29 AM, Manjunath wrote: > Hi Christer, > > Thanks for your prompt inputs. Please see my comments inline. > > > > On Tue, Apr 10, 2012 at 5:12 PM, Christer Holmberg > > > wrote: > > Hi, > > Some initial questions: > > Q1. Why can't the caller, already when sending the initial INVITE, > indicate whether the call is important or not, in order for the > callee to take proper actions? Why does the callee have to tell the > caller to give that information? > > [Manjunath]: The Caller should not send the initial INVITE with high > priority because particular call may be important for Caller but may not > be important for Callee and also Caller is unknowingly disturbing the > Callee. > > By our proposed mechanism, before actual session establishment, both > Caller and Callee will come to one common point of agreement for > urgent/important calls. I don't understand this argument at all. In the end, the callee knows whether the call is a priority to the caller and can still decide if it wants to answer it when the caller has declared it to be priority. AFAICT, the only difference is that with your approach the caller need not decide if his call is a priority call until he knows it won't be accepted as a non-priority call. I will grant that can lead to a more convenient UI for the caller. But I have suggested a different, simpler, mechanism to achieve that. Thanks, Paul > Q2. I don't think the usage of Require is correct. Require is used > to mandate support of a SIP extension, but in the PRACK/UPDATE the > caller uses it to tell the callee that the call is important. > > [Manjunath]: Yes, you are absolutely right. Required header is used to > mandate the support of SIP extensions. > > In our draft we have defined an optional tag “continue” and a header > “Continue” to address the purpose. So we have used Continue header in > the PRACK/UPDATE method of the caller to inform the callee that the call > is important. > > > Q3. In the draft, the 182 response contains SDP (section 7.x). But, > I guess the callee will not start reserving resources until it has > decided whether it is going to accept the call. > > [Manjunath]: Yes agreed. We will change this in our next revision draft. > > > Q4: In the ABNF (section 5), you don't need to define the same value > with capital and small letters. > > [Manjunath]: Yes agreed. We will change this in our next revision draft. > > > Q5: I don't understand why the caller has to send PRACK in case of > Continue: no (section 7.2). Why not simply send CANCEL? > > [Manjunath]: Here we are taking extra care by providing additional > option to the Caller either by dropping a VoiceMail OR by redirecting to > some other number which was preset by Callee. > > This is the reason why we were not sending simply CANCEL message in case of Continue: no (section 7.2). > > Regards, > > Christer > > > On 4/2/12 1:46 PM, sunil sinha wrote: > > Dear All, > > > > I have just made revision 3 of > > 'draft-sinha-dispatch-sip-continuation-option' available following > > offline discussion. Biggest addition is the new section 7.6 and 7.7 > > which aims to further inter-working scenario. > > > > You can find the HTML formatted version here: > > > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-optio > > n-03 > > > > > > I am looking forward to hearing about any concerns you may have. > > > > Thanks & Regards, > > sunil kumar sinha > > > > > > > > > > > > ---------- Forwarded message ---------- > > From: ** >> > > Date: Mon, Apr 2, 2012 at 3:41 PM > > Subject: New Version Notification for > > draft-sinha-dispatch-sip-continuation-option-03.txt > > To: sunilkumarsinha9@gmail.com > > > > > Cc: sinha.amardeep@gmail.com > >, > > de_subhrajyoti@yahoo.co.uk > > > > > > > > A new version of I-D, > > draft-sinha-dispatch-sip-continuation-option-03.txt has been > > successfully submitted by Sunil Kumar Sinha and posted to the IETF > > repository. > > > > Filename: draft-sinha-dispatch-sip-continuation-option > > Revision: 03 > > Title: The Continue Header Field for the Session Initiation > > Protocol (SIP) > > Creation date: 2012-04-02 > > WG ID: Individual Submission > > Number of pages: 23 > > > > Abstract: > > Before placing a call, it is quite often useful for the Caller to > > know whether a Callee is in favorable state to receive a call or > > not. This document defines an optional tag > "continue" and > > a header "Continue" to address the purpose. The > > "Continue" header field is > > to confirm the session continuity with the Callee from the Caller > > after an option for session continuity is placed by the Callee > based > > on the unfavorable state of the Callee. This functionality is > needed > > to resolve the unwillingness of the Callee to receive any call. An > > option is given to the Callee by the Service Provider or by the > > Handset Manufacturer or by the Carrier to establish this > requirement. > > > > > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Sun Apr 22 14:35:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E214621F859F for ; Sun, 22 Apr 2012 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGEyPuL7ygDI for ; Sun, 22 Apr 2012 14:35:27 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4453121F8593 for ; Sun, 22 Apr 2012 14:35:27 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id 19RJ1j0041GhbT8579bUKq; Sun, 22 Apr 2012 21:35:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id 19bU1j00v07duvL3T9bViW; Sun, 22 Apr 2012 21:35:29 +0000 Message-ID: <4F94799E.8060003@alum.mit.edu> Date: Sun, 22 Apr 2012 17:35:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Manjunath References: <1333947130.S.10083.16336.H.WXN1bmlsIGt1bWFyIHNpbmhhAEZ3OiBSZTogW2Rpc3BhdGNoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWM_.RU.rfs223, rfs223, 401, 114.f5-224-169.old.1333948912.23738@webmail.rediffmail.com> <4F82DDC6.4000704@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 21:35:29 -0000 On 4/22/12 7:26 AM, Manjunath wrote: > Hi Paul, > > Thanks for your prompt inputs. Please see my comments inline. > > On Mon, Apr 9, 2012 at 6:31 PM, Paul Kyzivat > wrote: > > On 4/9/12 1:21 AM, amar deep wrote: > >> > >> Hi Paul, > >> > >> Problem : > >> -REQ-1: Callee wants no urgent call for him should get rejected when he > >> set DnD status =ON, & he fail to notice beep/flash over the phone. > > > > > > Do you have a standard definition of DnD status? Or is your DnD mechanism > > proprietary? > > > >*[Manjunath] : Here we are not touching standard DND mechanism at all.* I don't know what you meant. Are you saying that you are assuming a standard definition of DND? (E.g. a 3gpp definition.) Or are you saying that you have your own definition of DND independent of any standard. It doesn't really matter greatly to the discussion. But it would help in understanding you. > >> -REQ-2: Caller wants call to get connected only if callee is > >> free/available – for normal/urgent/emergency call > >> -REQ-3: Caller don’t wants call to get connected to Callee when is BUSY > >> – for Normal call > >> -REQ-4: Caller wants call to get connected what so ever is state of > >> callee is – for urgent/emergency call > >> > >> Problem-Solution justification with Continue -Why problem need to be > >> solved: > >> -Based on call type(normal/urgent/emergency), caller can make decision > >> to go with call setup or not > >> -Based on callee status, caller can make decision to go with call setup > >> or not > >> -Decision of have call setup successful based on call priority is vested > >> within Caller decision not on feature configuration > >> > >> Using Priority header: > >> -Using Priority headers is not run time bases, its depends on call > >> service and pre-configured call setting > > > > > > I don't understand your comment about the Priority header. It seems to me > > that you can obtain all the behaviors you describe in your > requirements and > > in your problem solution justification simply by the caller setting the > > Priority header and the callee taking it into account. > > > > *[Manjunath] : Here we mean to say the limitations of Priority Header. > With Priority Header there are two use cases which have limitations: > > > _CASE 1: Caller sends PRIORITY =HIGH and Callee don’t have DND Enabled_ > > In this case/scenario we would miss couple of things: > > a.) Caller does not know the state/mood of Callee before placing a call. Why does it matter? It may be that the caller would want to do all he can to get the call answered regardless of the state of the callee. If not, he can wait to assert priority until after his unprioritized attempt is rejected. In this case DND isn't enabled, so presumably the called phone will ring regardless of the priority of the call. > b.) Particular Call may be important for Caller but may not be > important for Callee and also Caller is unknowingly disturbing the Callee. Surely its true that the call could be important to the caller but not the callee. But your mechanism doesn't protect against that. In any case, the callee is free to reject calls even if they are marked as high priority. And it can do so either automatically or after alerting the callee and getting feedback from the called user. Since you say DND isn not enabled, presumably the callee will get an alert regardless of the priority of the call. If he considers the call undesired he can reject it. > _CASE2: Caller sends PRIORITY =HIGH and Callee have DND Enabled with > Ringer off_** From what I can see this case is not discussed in your draft. > In this case/scenario also we would be missing couple of things: > > a.) If Callee does not notice Pop- up message that means Callee is > ready to take a HIGH risk to miss any URGENT call. You are making assumptions about what the callee device does with different priority settings, ringer settings, and DND settings. Since your draft doesn't address this I don't know what it would do. > b.) Particular Call might be important for Caller but might not be > important for Callee. Same comment as above. > * > > > >> -Initial request from caller is MARKED if it’s a high priority call or > >> not – mainly addressing emergency situation.The priority header filed > >> mainly address to “resources that may become scarce and congested during > >> emergencies. These resources include gateway resources, circuit-switched > >> network resources, IP network resources, receiving end system resources > >> and SIP proxy resources. “. > > > > > > You seem to be describing the Resource-Priority header, not the Priority > > header. They are different. > > > > *[Manjunath] : Yes, I completely agree both are different. We are > talking about ONLY priority header.* The quote you give above about resources that become scarce and congested during emergencies is pertinent to the Resource-Priority header, not the Priority header. So you can't use that as an argument against use of the Priority header. > > > >> -It doesn’t address above Requirement/problem, wherein call is made > >> high-priority based on callee availability/willingness and caller > >> decision about call catergory based on call-type > >> > >> Using 403 Forbidden /or New Response Code: > >> -For 403 response code or any new response code of 3XX, 4XX, 5XX & 6XX, > >> make call discontinue irrespective of call-type urgency > >> normal/urgent/emergency > >> -Response code of 3XX, 4XX, 5XX & 6XX category – don’t give option to > >> caller to make decision for call continuation or for termination > > > > > > You have two choices of how to use these mechanisms to accomplish your > > objective: > > > > 1) if the caller knows a priori that the call is high priority then > he can > > instruct his phone to include a suitable Priority header value in the > call > > initially. > > > *[Manjunath] : If Caller sends initial INVITE with high priority then in > that case the call may be important for Caller but may not be important > for Callee. Also Caller is unknowingly disturbing the Callee without > knowing the favourable state of Callee before placing a call. > * I'll say it again: The callee is in control of whether it is disturbed by high priority calls or not. If it chooses to reject high priority calls without disturbing its user then so be it. And you assume somehow that the decision the caller makes about whether his call is important will be affected in some way by knowledge of the callee state. If the caller wants the priority to be high only if a lower priority call is rejected then he can wait for the reject before asserting the high priority. But if he knows that he wants to make the call regardless then he can assert the priority immediately. > > 2) the caller can always try calls first with normal priority. If the > call > > fails with a response code that indicates that it was rejected > because its > > priority was insufficient, then the phone can report this to the > user, who > > can retry the call with the priority set appropriately. There are > numerous > > possibilities for how the user interface would look for this. The > exact code > > used to indicate that the call was rejected for insufficient priority > can be > > refined if you want to pursue this approach. > > > > *[Manjunath] : When Caller tries calls with normal priority and get > rejected because of priority insufficient this is because the Callee is > in DND mode. Presumably the call is rejected because the priority is insufficient to be accepted by the called UA in its current state. For you, perhaps that is because it is in DND mode. That is your choice. Make your algorithm for rejecting calls be whatever you want. > Now, again when Caller retry the call with High priority set that means > Caller wants the Callee to answer his/her ONLY URGENT call. No. It means the caller is asserting that he considers *this* call to be of high priority, and hopes the callee will take that into account in deciding whether to accept it. (And "high" is different from "urgent". Presumably either could be used depending on caller preference.) > And this is > possible only when Callee notices the pop-up message OR light blink as > Callee is in DND mode. You can make a variety of choices about how to alert calls based on mode of the callee and priority. Its your choice. > If Callee missed OR unnoticed that pop-up message > OR light blink then Callee will not answer the Caller’s URGENT call even > though the Caller has sent the request with High priority. > * I suggest you do the following: - enumerate the modes that you want to allow for the callee (normal, DND, NDDND, ...) - enumerate the desired user experience for the callee for calls that are offered to the callee, in each callee mode. - enumerate the desired user experience for the caller for calls to the callee, in each callee mode. Then we can discuss mechanisms. Thanks, Paul > > Thanks, > > Paul > > > >> ISDN interoperability: > >> -This section is added at 7.6 and 7.7 section of the draft document, to > >> state that this feature is not limited only from VoIP call > >> -This feature proposed within the draft document, works across network > >> type as well. > >> > >> Thanks, > >> Amardeep > >> > >> -- Original Message -- > >> > > >> > >> > > >> From: Paul Kyzivat pkyzivat@alum.mit.edu > >> > > >> To: dispatch@ietf.org > >> > > >> Subject: Re: [dispatch] Fwd: New Version Notification for > >> draft-sinha-dispatch-sip-continuation-option-03.txt > >> > >> > >> FollowRediff Deal ho jaye!to get exciting offers in your city everyday. > >> Sunil, > >> > >> > >> > >> Looking back, I see that you had replied to my comments on the earlier > >> > >> version of this draft and I never responded. > >> > >> > >> > >> To summarize, the problem I have with this draft is that you leap to a > >> > >> particular mechanism to solve a problem without having justified why > >> > >> that solution is better than other possible solutions to the same > >> > >> problem. And also without having sufficiently motivated people about why > >> > >> this is a problem that needs solving. > >> > >> > >> > >> Your latest update, with the ISDN interoperability example, suggests > >> > >> that ISDN interoperability might be driving the way you frame the > >> > >> problem. If so it would be good for you to explain that. > >> > >> > >> > >> It still seems to me that this could be solved with less new mechanism. > >> > >> The Priority header, plus an existing response (e.g. 403 Forbidden plus > >> > >> an exiting or new Warning header) or a new response code. > >> > >> > >> > >> Thanks, > >> > >> Paul > >> > >> > >> > >> On 4/2/12 1:46 PM, sunil sinha wrote: > >> > >> > Dear All, > >> > >> > > >> > >> > I have just made revision 3 of > >> > >> > ďż˝draft-sinha-dispatch-sip-continuation-optionďż˝ available following > >> > >> > offline discussion. Biggest addition is the new section 7.6 and 7.7 > >> > >> > which aims to further inter-working scenario. > >> > >> > > >> > >> > You can find the HTML formatted version here: > >> > >> > > >> > http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03 > >> > >> > > >> > >> > > >> > >> > I am looking forward to hearing about any concerns you may have. > >> > >> > > >> > >> > Thanks & Regards, > >> > >> > sunil kumar sinha > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > ---------- Forwarded message ---------- > >> > >> > From: ** > > >> > >> > Date: Mon, Apr 2, 2012 at 3:41 PM > >> > >> > Subject: New Version Notification for > >> > >> > draft-sinha-dispatch-sip-continuation-option-03.txt > >> > >> > To: sunilkumarsinha9@gmail.com > >> > >> > Cc: sinha.amardeep@gmail.com , > >> > >> > de_subhrajyoti@yahoo.co.uk > >> > >> > > >> > >> > > >> > >> > A new version of I-D, > >> > >> > draft-sinha-dispatch-sip-continuation-option-03.txt has been > >> > >> > successfully submitted by Sunil Kumar Sinha and posted to the IETF > >> > >> > repository. > >> > >> > > >> > >> > Filename: draft-sinha-dispatch-sip-continuation-option > >> > >> > Revision: 03 > >> > >> > Title: The Continue Header Field for the Session Initiation > >> > >> > Protocol (SIP) > >> > >> > Creation date: 2012-04-02 > >> > >> > WG ID: Individual Submission > >> > >> > Number of pages: 23 > >> > >> > > >> > >> > Abstract: > >> > >> > Before placing a call, it is quite often useful for the Caller to > >> > >> > know whether a Callee is in favorable state to receive a call or > >> > >> > not. This document defines an optional tag "continue" and a > >> > >> > header > >> > >> > "Continue" to address the purpose. The "Continue" > >> > >> > header field is > >> > >> > to confirm the session continuity with the Callee from the Caller > >> > >> > after an option for session continuity is placed by the Callee based > >> > >> > on the unfavorable state of the Callee. This functionality is needed > >> > >> > to resolve the unwillingness of the Callee to receive any call. An > >> > >> > option is given to the Callee by the Service Provider or by the > >> > >> > Handset Manufacturer or by the Carrier to establish this requirement. > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > The IETF Secretariat > >> > >> > > >> > >> > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > dispatch mailing list > >> > >> > dispatch@ietf.org > >> > >> > https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> > >> _______________________________________________ > >> > >> dispatch mailing list > >> > >> dispatch@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> Amar > >> > >> > >> > > >> > >> Follow *_Rediff Deal ho jaye! > >> > >> > >_* > >> > >> to get exciting offers in your city everyday. > >> > > From dworley@avaya.com Mon Apr 23 08:55:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE121F8753 for ; Mon, 23 Apr 2012 08:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.322 X-Spam-Level: X-Spam-Status: No, score=-103.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FetriMMa56u2 for ; Mon, 23 Apr 2012 08:55:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5861621F8755 for ; Mon, 23 Apr 2012 08:55:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHN6lU+HCzI1/2dsb2JhbAA4DLFHgQeCCQEBAQECARILWgIFCwIBCA0IJgshESUBAQQOBQgTB4dfAwYFnUiTQg2JU4l6awGFamMEkhCCEoduhSeFAYMF X-IronPort-AV: E=Sophos;i="4.75,467,1330923600"; d="scan'208";a="303182242" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Apr 2012 11:54:59 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Apr 2012 11:38:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 23 Apr 2012 11:54:59 -0400 From: "Worley, Dale R (Dale)" To: Manjunath Date: Mon, 23 Apr 2012 11:54:59 -0400 Thread-Topic: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt Thread-Index: Ac0gdHo4b/Z1ASlRQ/WF16BzAEOsbgA893B1 Message-ID: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:55:03 -0000 > From: Manjunath [manjugd@gmail.com] >=20 > > As far as I can tell, you place great emphasis on the need for the > > callee to communicate his state to the caller. And that this is the > > reason that the "Priority" header in the INVITE is not a sufficient > > solution. > [...] > > This is not specified in a requirement in Amardeep's list of > > requirements. >=20 > [Manjunath] :What Amardeep sent earlier was just the consolidated > requirement list. However you should ensure that the consolidated requirement list contains this requirement, as it is an essential reason for organizing the "continuation" mechanism in the way you have organized it. > > But I do not know of a justification that it is important for the > > callee to communicate his state to the caller. The caller knows > > before placing the call whether it is important enough to interrupt > > the callee. Knowing whether the callee is busy does not change that. >=20 > [Manjunath] : Yes it would be important for the callee to communicate > his state to the caller because that particular call at that moment > may not be important for callee. >=20 > Yes, the caller knows before placing the call whether it is important > enough to interrupt the callee. And knowing whether the calee is busy > (DND set) the caller will not change his/her state. That means caller > wants callee to answer his/her URGENT call. And this is only possible > when callee notice the alert OR pop-up message or light blink. If > callee missed OR unnoticed pop-up message OR light blink then callee > will not answer the caller=92s URGENT call even though the caller has > sent the request with High priority. So if callee sets NDDND (as > defined in draft) we can overcome this problem. However, since we are considering changing the callee's phone's behavior already, why not modify the callee's phone to ring when it receives an INVITE with "Priority: urgent" even if the phone is busy or has DND set? Dale