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

From: "amar deep" <[email-masked]>
Date: 9 Apr 2012 05:17:42 -0000

Hi Ranjit,

The main idea behind having CONTINUE header is to make call-setup successful, as far as possible, beyond time-zone boundaries & other feature setting (like DnD,non-availability presence status, etc). 

Call should not get BLOCKED/FAIL becz of these VoIP features, unless and until callee intentionally wants not to proceed with call-setup from an incoming call.

Thanks,
Amardeep

-- Original Message --

From: "Avasarala, Ranjit" [email-masked]
To: sunil sinha [email-masked], "Barnes, Mary" [email-masked], Cullen Jennings [email-masked], Gonzalo Camarillo [email-masked], "[email-masked]" [email-masked]
Cc: amardeep sinha [email-masked], Subhrajyoti De [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.

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.

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

_______________________________________________

dispatch mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dispatch

Amar

---

From: "amar deep" <[email-masked]>
Date: 9 Apr 2012 05:21:53 -0000

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

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]

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

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

> From: ** 

> Subject: New Version Notification for

> draft-sinha-dispatch-sip-continuation-option-03.txt

> Cc: [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.

> Title:      The Continue Header Field for the Session Initiation

> Protocol (SIP)

>  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

dispatch mailing list

[email-masked]

Amar