Re: [straw] draft-straw-sip-traceroute-00

[Hadriel Kaplan <[e-mail]>]

On Jul 20, 2013, at 1:45 PM, Brett Tate <[e-mail]> wrote:

> For the "unofficial reason" to work, wouldn't the 205 also need to indicate (without use of Reason header) why it's answering the request?

In what way?  I mean isn't that arguably the purpose/role of a Reason header in a success response? (though Reason headers in responses only showed up after the Reason header got defined, if I recall, because it was for requests originally... I have to find the RFC...)


> Concerning 205, a middle box can be configured to answer and play treatments upon receiving a failure response (or determining a failure situation).  Should it start sending the 205 and Reason header to indicate why it answered the call?

I was thinking that if we move forward with this idea, I'd separate it out and submit a new I-D into DISPATCH for a 205 response.  The current sip-traceroute draft would normatively reference and say to use this new 205 draft, for the traceroute use case.  The 205 draft would informationally reference the sip-traceroute draft as its motivating use-case, but one could imagine 205 could be sent back for cases where a middlebox answered a call due to a failure response.

Obviously today they do that already, using 200, and that's fine - but they could send back a 205 with a Reason header instead if it would be useful to them.  For example if a voicemail picked up it might prefer to send back a 205, so that upstream systems could terminate immediately; or for example if a media server picked it up to play the "your number could not be reached as dialed" type thing, there'd be SIP layer info of that.  That might be useful if the originating UAC could try something else immediately without user intervention - for example the current "international dialing assistance" thing some mobile phones do, where they figure out you meant to add your country-code to dialed-numbers when you're roaming in another country.

From a practical perspective it would be up the answerer if it wanted to use this new response or not, and most probably wouldn't change behavior; but one could if it was useful for some reason.

This would create a new dependency for the sip-traceroute draft, and delay its publication, but I don't think we're in a big hurry or anything.

-hadriel