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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 26 Aug 2011 11:54:09 -0400

An alternative approach would be to use the Priority header in the initial INVITE,
allowing the UAS to decide whether it wanted to accept the call based on its
priority.  This would have the advantage that if the call was not high priority,
the call could be immediately sent to an alternative destination (e.g., voicemail).

However, this behavior is sociologically different from the draft, as it requires the
caller to decide on the call's priority before initiating the call, and to indicate high
priority before discovering that the callee was filtering based on priority.

Another approach would be that if the Priority in the initial INVITE is not high,
the UAS would respond with (say) "184 Inadequate Priority".  The caller could
then send an UPDATE to the UAS with "Priority: high".

Another aspect of this is the matter of presence information.  I have not noticed
any of our models of presence allowing a way to indicate "available for high-priority
requests but not normal-priority requests".

Dale

---

From: "sunil kumar sinha" <[email-masked]>
Date: 29 Aug 2011 22:39:18 -0000

Dear All
Please find my answers inline wrt Paul Question. I am keeping everyone in loop for discussion so that most of the common queries I think has been addressed. In case there is any other question / clarification needed, please let us know. We will incorporate your valuable feedbacks based on the agreed items in our next document version.
Once again many thanks for your valuable feedbacks, much appreciate your valuable inputs and time.
&nbsp;Regards
Sunil kumar sinha
&nbsp;
&nbsp;
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.
[Sunil] Intended use: Applications as mentioned in Section 4, this is used as Called Party Voice feature service when Callee is not in a favorable state to receive calls, Callee is NOT in DND and can accept calls, Callee can set a parameter called NDDND (Non Dedicated Do Not Disturb) in Handsets / IP Devices or with NSP which initiates the mentioned 182 response on receiving INVITE instead of 180 Ringing from Handset or VFS as the case may be based on the configuration, finally its upto the sole discretion of Caller to make progress with placing the call or disconnect. Detailed Call Flow given in the proposal. We have studied all the methodologies and SIP parameters and found it difficult to incorporate this feature, so proposed this new SIP Header “Continue” with the designed call flows&nbsp; and behavior at UEs and Proxies. 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.
[Sunil] INVITE contains “Supported: continue”, we will make the needful addition of INVITE (F1) in call flow as suggested by you in the next version. Thanks for your valuable suggestion.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?
[Sunil] Correct (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.)
[Sunil] Latter meaning holds good for the usage of “Require: continue” header, we have also portrayed in the same way. If there’s anything else you would like to know or want us to incorporate anything else,pls let us know
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?
[Sunil] Agreed, accept your point fully, this is the case when caller doesn’t support this mechanism but callee does, so NDDND will not work for callee as the concept behind the usage of NDDND as a called party voice feature is to give option to the supported caller to display an option whether to finally place a call or not, the call will be placed based on the sole discretion of Caller. If Caller doesn’t support this functionality whether a DND will be flagged or Normal Call Treatment to be done I feel need to be again a configuration dependent on the Device/NSP or Device manufacturer / Service Provider implementation specific. I will incorporate the outcome behavior of this scenario in the next version after discussing with co-authors. Many thanks for your valuable feedbacks. In this case 182 won’t be responded by Callee, either 180 or 486 would be responded Section 4:IIUC this lists a number of cases where this feature might be used, yet to the UAC these are all ind
 icated 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. 
[Sunil] This is described above. &nbsp;Pls let me know if you have any questions.
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.
[Sunil] I agree to most of your points on the usage of Priority header, except one scenario which cannot be implemented. If Called Party supports the feature and Caller doesn’t support Priority, then this feature will be just DND. Our purpose is not to have DND by any means. In our case decision to treat this feature or not at the Callee although it is set at Callee based on Supported: continue present in initial INVITE from Caller. If Caller is not up-to-date with this feature, then he doesn’t send Supported: continue in initial INVITE and this call is treated as Normal Call with 180 Ringing sent by Called Party suppressing the feature set at Called Party. My apologies we haven’t put all the combination of scenarios in the first version of draft, we will send all position combination in our next version. Once again many thanks for your valuable feedbacks.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.
&nbsp;[Sunil] Not all Handsets supports this.
&nbsp;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