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

[Paul Kyzivat <[e-mail]>]

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

On 7/29/13 9:40 AM, Hadriel Kaplan wrote:
>
> 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/
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>