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

(As co-chair and individual)

Hi,

As co-chair:

Q1: As was discussed in Orlando, we are not chartered to define new SIP header fields. I would say the same applies for new SIP response codes. And, as Hadriel said below, we would need to go to DISPATCH (or SIPCORE) in order to do such work.

As individual:

Q2: Instead of a new response code, couldn't we simply use e.g. a media feature tag, indicating "I am a B2BUA, and I have a capability to perform traceroute-style test calls using the media-loopback mechanism"? Media feature tags do not require an RFC. We could still use a Reason header field with a 483 value.

Q3: I also believe the UAC needs to indicate its capability of performing the test calls. Otherwise a B2BUA could answer the call, and if the UAC does not understand the 205 response/media feature tag/whatever-mechanism-we-will-use it may think that it has reached the indicated target.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: straw-bounces@ietf.org [mailto:straw-bounces@ietf.org] Puolesta Hadriel Kaplan
Lähetetty: 20. heinäkuuta 2013 21:02
Vastaanottaja: Brett Tate
Kopio: straw@ietf.org
Aihe: Re: [straw] draft-straw-sip-traceroute-00

On Jul 20, 2013, at 1:45 PM, Brett Tate <brett@broadsoft.com> 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

_______________________________________________
straw mailing list
straw@ietf.org
https://www.ietf.org/mailman/listinfo/straw