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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2012 09:01:58 -0400

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 [email-masked]
>  >
> To: [email-masked]
>  >
> 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: [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 "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
>
>  > [email-masked]
>
>  > https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> _______________________________________________
>
> dispatch mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> Amar
>
> <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=___http://dealhojaye.rediff.com?sc_cid=rediffmailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals>_*
> to get exciting offers in your city everyday.
>

---

From: Manjunath <[email-masked]>
Date: Sun, 22 Apr 2012 16:56:50 +0530

Hi Paul,

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

On Mon, Apr 9, 2012 at 6:31 PM, Paul Kyzivat <[email-masked]> wrote:
> 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 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.

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 =HIGH and Callee have DND Enabled with Ringer
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.

*
> header. They are different.

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

> 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.
*

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

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’s URGENT call even
though the Caller has sent the request with High priority.
*

>> <
http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle
?>
>> <
http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_cid=rediffmailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals
>_*

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Apr 2012 17:35:26 -0400

On 4/22/12 7:26 AM, Manjunath wrote:
> On Mon, Apr 9, 2012 at 6:31 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:

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.

>  > that you can obtain all the behaviors you describe in your
> requirements and
> *[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_
>

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.

> 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

Same comment as above.

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

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

> call
>  > 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
> 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.

> 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
> 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

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

>  >> From: Paul Kyzivat [email-masked] <mailto:[email-masked]>
>  >> >
>  >> To: [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,
>  >>
>  >> > [email-masked] <mailto:[email-masked]>
>  >>
>  >> [email-masked] <mailto:[email-masked]>
>  >>
> <http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_cid=rediffmailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals
> <http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_cid=rediffmailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals>>_*
>  >>