Subject: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option

From: "sunil kumar sinha" <[email-masked]>
Date: 24 Aug 2011 10:00:02 -0000

Hi Everyone,

This draft proposed a mechanism to resolve the problem – when callee is not in a favorable state to accepts incoming calls.
http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation-option-00.txt

Unfavorable condition highlighted in the draft are -1) Caller and Callee both are in different time-zone 2) Callee is in a mild-DND(NDDND) state. Unfortunately, there could be a number of factors that contribute to the above un-favorable condition for a callee .

But at the same time under such a case, non-emergency calls needs to be avoided and emergency calls needs to be communicated - is addressed in the draft.

Comments on the draft or which WG it should go to are much
appreciated. Please let us know your thoughts.

Best regards,
Sunil Kumar Sinha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2011 11:00:34 -0400

Sunil,

I'm having trouble understanding the assumptions and intended use of 
this mechanism. I also think there are probably other ways of 
accomplishing something similar.

Some comments and questions on the draft:

Figure 2:

You don't show the F1 message. Does it contain 'Supported:continue'? If 
not, then putting Require:continue in the response is very questionable, 
since it can't be refused in a response.

Is it intended that the 182 + Require:continue is to be interpreted by 
the UAC as indicating that the call hasn't yet alerted, and won't unless 
Continue:yes is sent?

(That is an improper use of Require. It is supposed to mean "I require 
that you *support* this option", not that I require you to use it.)

Also, what is the intended behavior when the UAC does not support this 
mechanism? If it receives a 182 response, it will probably treat it just 
like a 180 and wait, assuming the call is alerting and will eventually 
be answered. Or does the UAS note there is no Supported:continue and 
return 486 rather than 182?

Section 4:

IIUC this lists a number of cases where this feature might be used, yet 
to the UAC these are all indicated in the same way. So the user of the 
UAC has no idea why he is being asked to confirm or deny the importance 
of his call.

General comments:

This seems to be yet another spin on presence. Have you investigated how 
you might explicitly use presence for this? For instance, the UAS that 
wants this behavior could refuse (perhaps with 486) any call that 
doesn't have a Priority header with a sufficiently high value. In the 
response it could include a PIDF in the body (or content indirection to 
one). Then the UAC could interpret that, interact with its user, and 
perhaps generate another INVITE with a Priority header.

Or, UACs that support this mechanism could simply subscribe to presence 
of the callee before sending the invite, and make a decision how to make 
the call based on what is received.

Or, if you really feel its essential to do this with one invite, an 
existing mechanism to defer alerting is through use of preconditions. 
You could conceivably create a new precondition type to get the desired 
effect. (But this direction isn't appealing to me.)

Most, I suggest you spend more time refining the requirements before 
getting involved in the mechanism.

	Thanks,
	Paul

On 8/24/11 6:00 AM, sunil kumar sinha wrote:
> Hi Everyone,
>
> This draft proposed a mechanism to resolve the problem – when callee is
> not in a favorable state to accepts incoming calls.
> Unfavorable condition highlighted in the draft are -1) Caller and Callee
> both are in different time-zone 2) Callee is in a mild-DND(NDDND) state.
> Unfortunately, there could be a number of factors that contribute to the
> above un-favorable condition for a callee .
>
> But at the same time under such a case, non-emergency calls needs to be
> avoided and emergency calls needs to be communicated - is addressed in
> the draft.
>
> <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
>
>
> Treat yourself at a restaurant, spa, resort and much more with *Rediff
> Deal ho jaye!
> <http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_cid=mailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals>*
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 25 Aug 2011 15:55:43 -0400

I have just skimmed this draft.  Some comments that come to mind are:

The use and operation of the mechanism is not very clearly stated.  In particular,
there should be a narrative of the specific items in the messages that perform
the call queueing and continuation operations, and their significance to the users.
E.g., I see no place stating "When the callee receives the INVITE but would prefer
not to be alerted, it sends a 182 response with "Require: continue" header..."

As Paul has noted, the use of "Require: continue" is not correct.  The meaning of
that header is "The UAS must reject the request if it does not implement the extension
named 'continue'."  In this case, we are adding an indication to a 182 response to
mean, "the call has been queued and will remain queued unless the UAS receives a
PRACK with 'Continue: yes'", which is much different.

For that matter, why not allocate another 18x response specifically to carry this meaning?

Given the use of PRACK, the UAC and UAS must support 100rel for this mechanism
to work.  That needs to be explicitly stated.

The example message flows should show the INVITEs, even if they are no different
from other situations.  At the least, "Supported: 100rel" should be shown, as that is necessary
for the UAS to be able to use the continue mechanism.

The short form of the header name is "cn", while all the other short forms are a single
letter.

I would prefer to use the Priority header to control such a facility:

   20.26 Priority

   The Priority header field indicates the urgency of the request as
   perceived by the client.  The Priority header field describes the
   priority that the SIP request should have to the receiving human or
   its agent.  For example, it may be factored into decisions about call
   routing and acceptance.  For these decisions, a message containing no
   Priority header field SHOULD be treated as if it specified a Priority
   of "normal".  The Priority header field does not influence the use of
   communications resources such as packet forwarding priority in
   routers or access to circuits in PSTN gateways.  The header field can
   have the values "non-urgent", "normal", "urgent", and "emergency",
   but additional values can be defined elsewhere.  It is RECOMMENDED
   that the value of "emergency" only be used when life, limb, or
   property are in imminent danger.  Otherwise, there are no semantics
   defined for this header field.

      These are the values of RFC 2076 [38], with the addition of
      "emergency".

   Examples:

      Subject: A tornado is heading our way!
      Priority: emergency

   or

      Subject: Weekend plans
      Priority: non-urgent

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Aug 2011 11:29:57 +0200

The problem with a mechanism like this is that the special capability desired by the callee is only available if the caller's device supports this proposed new extension, so in many situations it simply would not work as required, and the default behaviour would be that the call is not established.

Another approach would be to answer the call and play an announcement, stating something like "hold the line if there is an urgent need to proceed with this call", and then put it through if the caller has not cleared within a given number of seconds. If you really want the caller to take positive action to proceed, DTMF could be used, which would then also work for PSTN callers. OK, this is old-fashioned technology, but it would work pretty well universally and people are comfortable with this sort of thing.

For a superior experience where the entities involved provide appropriate support, something based on presence, as already proposed, would be more appropriate, perhaps coupled with Priority.

A technical point: the proposed use of PRACK is a bit of an abuse. It requires delaying the PRACK while waiting for the caller to decide whether to proceed or not. So it might cause the 182 to be repeated a number of times. I don't know whether that matters, but it was not what PRACK was designed for.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 25 August 2011 16:01
> To: [email-masked]
> Subject: Re: [dispatch] New Draft - 
> draft-sinha-dispatch-sip-continuation-option
> 
> Sunil,
> 
> > This draft proposed a mechanism to resolve the problem - 
> when callee is
> <http://track.rediff.com/click?url=___http://dealhojaye.rediff
> .com?sc_cid=mailsignature___&cmp=signature&lnk=rediffmailsigna
> ture&newservice=deals>*
> >
> >
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 29 Aug 2011 19:40:11 +0530

Sunil,

I skimmed through the draft and I have the same question asked by Paul
and others. My first impression after reading the problem is a solution
based of presence ( as already suggested by Paul in his first general
comment) can be used.
Any reasons why you feel the current mechanisms are not sufficient and
there is a need for the new mechanism ?

Regards,
Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, August 25, 2011 8:31 PM
> To: [email-masked]
> Subject: Re: [dispatch] New Draft -draft-sinha-dispatch-sip-
> continuation-option
> 
> Sunil,
> 
> > This draft proposed a mechanism to resolve the problem - when callee
> is
<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_c
id=mailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=de
> als>*