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

From: sunil sinha <[email-masked]>
Date: Mon, 2 Apr 2012 17:16:04 +0530

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: <[email-masked]>
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for
draft-sinha-dispatch-sip-continuation-option-03.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

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 &quot;continue&quot; 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

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Mon, 2 Apr 2012 22:50:16 +0800

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: [email-masked] [[email-masked]] On Behalf Of sunil sinha [[email-masked]]
Sent: Monday, April 02, 2012 5:16 PM
To: Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; [email-masked]
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.

Thanks & Regards,
sunil kumar sinha

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Apr 2, 2012 at 3:41 PM
Subject: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

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:
  not. This document defines an optional tag &quot;continue&quot; and a header
  &quot;Continue&quot; to address the purpose.  The &quot;Continue&quot; header field is

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2012 19:47:16 +0200

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:
> ‘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.
>
> From: ** <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
>
>
> 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.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Manjunath <[email-masked]>
Date: Tue, 10 Apr 2012 10:45:01 +0530

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 <[email-masked]> wrote:

> 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.
>
> 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
>
>
>> ‘draft-sinha-dispatch-sip-**continuation-option’ available following
>> http://tools.ietf.org/html/**draft-sinha-dispatch-sip-**
>> continuation-option-03<http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03>
>>
>>
>> From: ** <[email-masked] <mailto:internet-drafts@ietf.**org<[email-masked]>
>> >>
>> draft-sinha-dispatch-sip-**continuation-option-03.txt
>> To: [email-masked] <mailto:sunilkumarsinha9@**gmail.com<[email-masked]>
>> >
>> Cc: [email-masked] <mailto:sinha.amardeep@gmail.**com<[email-masked]>
>> >,
>> [email-masked] <mailto:de_subhrajyoti@yahoo.**co.uk<[email-masked]>
>> >
>>
>>
>> A new version of I-D,
>> draft-sinha-dispatch-sip-**continuation-option-03.txt has been
>> Filename:        draft-sinha-dispatch-sip-**continuation-option
>> Revision:        03
>> ______________________________**_________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>>
>
> ______________________________**_________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>

---

From: Manjunath <[email-masked]>
Date: Tue, 10 Apr 2012 11:18:51 +0530

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 <
[email-masked]> 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:* [email-masked] [[email-masked]] On Behalf
> Of sunil sinha [[email-masked]]
> *Sent:* Monday, April 02, 2012 5:16 PM
> *To:* Barnes, Mary; Cullen Jennings; Gonzalo Camarillo; [email-masked]
> *Cc:* amardeep sinha; Subhrajyoti De
> *Subject:* [dispatch] Fwd: New Version Notification for

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Apr 2012 13:42:56 +0200

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?

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.

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 capital 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:
> 'draft-sinha-dispatch-sip-continuation-option' available following 
>    not. This document defines an optional tag &quot;continue&quot; and 
> a header &quot;Continue&quot; to address the purpose.  The 
> &quot;Continue&quot; header field is

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Apr 2012 08:43:58 -0400

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.
> *
>
> -        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?
>
> 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.
>
>
>
> 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
> 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 callee unnecessarily don’t want to receive less important
> call from unknown user and get disturbed with his state of mind.
>
> 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 <[email-masked]
> <mailto:[email-masked]>> 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.
>
>     It still seems to me that this could be solved with less new
>         ‘draft-sinha-dispatch-sip-__continuation-option’ available following
>         http://tools.ietf.org/html/__draft-sinha-dispatch-sip-__continuation-option-03
>         <http://tools.ietf.org/html/draft-sinha-dispatch-sip-continuation-option-03>
>
>
>         From: ** <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         draft-sinha-dispatch-sip-__continuation-option-03.txt
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         Cc: [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>,
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>
>         A new version of I-D,
>         draft-sinha-dispatch-sip-__continuation-option-03.txt has been
>         Filename:        draft-sinha-dispatch-sip-__continuation-option
>         Revision:        03
>         _________________________________________________
>         dispatch mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/dispatch
>         <https://www.ietf.org/mailman/listinfo/dispatch>
>
>
>     _________________________________________________
>     dispatch mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>

---

From: Manjunath <[email-masked]>
Date: Sun, 22 Apr 2012 15:59:21 +0530

Hi Christer,

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

On Tue, Apr 10, 2012 at 5:12 PM, Christer Holmberg <
[email-masked]> 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 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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Apr 2012 16:20:37 -0400

On 4/22/12 6:29 AM, Manjunath wrote:
> On Tue, Apr 10, 2012 at 5:12 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     Some initial questions:
>
>     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?
>
> 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.
>
> “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]: 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
>
>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>,
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
>      >
>      > A new version of I-D,