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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 10 Apr 2012 13:55:44 -0400

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 10 Apr 2012 19:40:43 -0400

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

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 11 Apr 2012 18:12:07 -0400

I suppose we could incorporate "Yao's Millionaires' Problem" into the protocol
so that the UAs could compare the sender's "how important this call is" with
the receiver's "how busy I am", without either revealing to the other their value.

Dale

________________________________________
From: Michael Hammer [[email-masked]]
Sent: Tuesday, April 10, 2012 7:40 PM
To: Worley, Dale R (Dale)
Cc: amar deep; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt

Mike

On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Manjunath [[email-masked]<mailto:[email-masked]>]
>

Dale
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

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

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

>
> Mike
>
>
> On Tue, Apr 10, 2012 at 1:55 PM, Worley, Dale R (Dale) <[email-masked]> wrote:
>>

---

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

Hi Dale,

As per our understanding Yao’s 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’s  favourite/buddy list and caller wants to know the
favourable state OR willingness of the callee before placing the call.

Thanks & Best Regards
- Manjunath

---

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

Hi Dale,

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

> reason that the "Priority" header in the INVITE is not a sufficient
[Manjunath] : Yes true. We also feel the same.

> This is not specified in a requirement in Amardeep's list of
[Manjunath] :What Amardeep sent earlier was just the consolidated
requirement list.

> the callee.  Knowing 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’s 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.

> "emergency".  The ISDN messages shown in section 7.6 do not seem to

[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 “Call Continuation” features.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 23 Apr 2012 11:54:59 -0400

> [...]

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.

> 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