Subject: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Jul 2013 03:40:40 -0400

Howdy,
During discussion on the STRAW WG mailing list about the sip-traceroute draft found here:

http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00

...we realized we needed a way for a B2BUA to answer a media-loopback-based INVITE and establish a dialog with the UAC, and somehow tell the UAC it was the B2BUA answering and not the final target UAS.  That way the UAC would know it hasn't reached the end of its traceroute testing and to instead continue increasing max-forwards.  So we were thinking of doing this as a 205 response, along with a Reason header.  The below draft is for that new response code.

I'm sending this to DISPATCH because I think that's what I'm supposed to do, but I believe it should be dispatched to SIPCORE and let them decide whether it makes sense or not, etc.

-hadriel

Begin forwarded message:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Session Initiation Protocol (SIP) Success Response Code for Indication of Alternate Target Answerer
> 	Author(s)       : Hadriel Kaplan
> 	Filename        : draft-kaplan-dispatch-sip-205-response-00.txt
> 	Pages           : 7
> 	Date            : 2013-07-29
> 
> Abstract:
>   This document defines a new Session Initiation Protocol (SIP)
>   response, 205 Alternate Answerer, that a SIP User Agent Server (UAS)
>   can use to indicate to the User Agent Client (UAC) that the UAS is
>   answering the request for which it was not the intended target.
>   This is useful for cases where the UAC might wish to perform
>   different actions based on such knowledge, such as terminate the
>   dialog or re-attempt the request in a different way.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-kaplan-dispatch-sip-205-response
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-kaplan-dispatch-sip-205-response-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Jul 2013 07:18:11 -0400

BTW, just to be clear - this is not an official request (or draft) from the STRAW Working Group.  It's an individual draft from an individual (me), and I'm requesting it be dispatched, and I suggest/recommend it be dispatched to SIPCORE.

-hadriel

On Jul 29, 2013, at 3:40 AM, Hadriel Kaplan <[email-masked]> wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jul 2013 17:06:01 +0200

Hadriel,

As sipcore co-chair, I also think sipcore will ultimately be the right 
place for this. But it may be valuable to leave it on dispatch for 
awhile. My main concern is that we talk through whether the decision to 
use 205 is well defined, and if introducing this will solve any 
problems. (And I say this in spite of this having been (IIRC) my 
suggestion in the first place.)

It is far from clear to me whether there can be clear rules for when to 
use 205.
- Should it be used whenever a call has been forwarded?
- Should a VM server use it? (In some sense the VM server is an agent
   of the callee, and is entitled to use 200.)

It is also not clear to me that it will solve the traceroute problem.
- what if the call is forwarded. Then it might get a 205, but not for
   the right reason. Will that be sufficient to stop the traceroute?

I don't know that these are show stoppers. I just think we need to work 
out the details a bit more.

Assuming we think the occasions for use can be well defined, and that it 
solves the problem you want it to solve, then IMO we should take it to 
sipcore and polish it off.

	THanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Jul 2013 03:13:29 -0400

On Jul 29, 2013, at 11:06 AM, Paul Kyzivat <[email-masked]> wrote:

> Hadriel,
> 
> As sipcore co-chair, I also think sipcore will ultimately be the right place for this. But it may be valuable to leave it on dispatch for awhile. My main concern is that we talk through whether the decision to use 205 is well defined, and if introducing this will solve any problems. (And I say this in spite of this having been (IIRC) my suggestion in the first place.)
> 
> It is far from clear to me whether there can be clear rules for when to use 205.

By "call forwarded", you mean the call/dialog is answered/established at a SIP layer, but then the UAS makes a separate second call to another UA and ultimately bridges the media together?

>  of the callee, and is entitled to use 200.)

You used the phrase "entitled to use 200", but the way I tried writing the 205 draft was not to mandate VMs to use 205 - it was to *allow* them to use 205.  In other words, a VM (or its operator) can decide whether to send a 205 or not, based on what it wants the UAC to do.  The rationale for sending a 205 would be to save resources on the VM, because in theory the UAC can know it's been redirected to voicemail and can hang up immediately. (I'm not saying the draft is good enough yet to make the distinction that it's reached a VM, but that can be worked on...)

>  the right reason. Will that be sufficient to stop the traceroute?

Yes - the Reason header will have a cause code of 483 when it's answered by the B2BUA for the traceroute purpose.  Once the testing UAC increases Max-Forwards, the next 205 would have a different Reason code.

-hadriel