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

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 14 Jul 2013 23:13:24 -0400

FYI - the traceroute draft has now been submitted as a WG draft.

I've added the part for handling how to know when you've reached the final UAS.  It wasn't quite clear from emails, but I think there was rough consensus for putting something in the SDP answer.  So I've taken the initiative and chosen what that would be: a pre-defined sess-id value in the origin line.  That will probably cause someone heartburn, but the IETF doesn't charge us money to upload new versions of drafts, so I can change it to whatever we get consensus for.

-hadriel

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-straw-sip-traceroute-00.txt
> Date: July 14, 2013 10:59:57 PM EDT
> To: Hadriel Kaplan <[email-masked]>
> 
> 
> A new version of I-D, draft-straw-sip-traceroute-00.txt
> has been successfully submitted by Hadriel Kaplan and posted to the
> IETF repository.
> 
> Filename:	 draft-straw-sip-traceroute
> Revision:	 00
> Title:		 A Media-based Traceroute Function for the Session Initiation Protocol (SIP)
> Creation date:	 2013-07-14
> Group:		 Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-straw-sip-traceroute-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-straw-sip-traceroute
> Htmlized:        http://tools.ietf.org/html/draft-straw-sip-traceroute-00
> 
> 
> Abstract:
>   SIP already provides the ability to perform hop-by-hop traceroute
>   for SIP messages using the Max-Forwards header field, in order to
>   determine the reachability path of requests to a target.  A
>   mechanism for media-loopback calls has also been defined separately,
>   which enables test calls to be generated which result in media being
>   looped back to the originator.  This document describes a means of
>   performing hop-by-hop traceroute-style test calls using the media-
>   loopback mechanism, in order to test the media path when SIP
>   sessions go through media-relaying B2BUAs.
> 
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 15 Jul 2013 19:26:07 +0200

Please note the WG document is draft-ietf-straw-sip-traceroute-00[1]

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

On Mon, Jul 15, 2013 at 5:13 AM, Hadriel Kaplan
<[email-masked]> wrote:
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

--
Victor Pascual Ávila

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 13:52:29 -0400

> I've added the part for handling how to know when you've reached the final UAS.  It wasn't quite clear from emails, but I think there was rough consensus for putting something in the SDP answer.  S…

Yeah, I'm not too fond of the pre-defined sess-id.
(I have a problem with carving out restricted values from any namespace 
that has been previously defined to be unconstrained. And in any case, 
what doe Pi have to do with traceroute?)

I would be more comfortable with something more explicit.
It isn't evident to me that this needs to be in SDP either. It could 
easily be in SIP, since this is really about indicating that the 
response is from exhaustion of the Max-Forwards rather than from 
reaching the intended destination. E.g. a Reason header might work, or 
some new header. Or this might justify defining a new 2xx response code.

Actually,a new 2xx code sounds quite attractive to me. E.g., 205 Too 
Many Hops.

	Thanks,
	Paul

---

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

On Jul 15, 2013, at 1:52 PM, Paul Kyzivat <[email-masked]> wrote:

> (I have a problem with carving out restricted values from any namespace that has been previously defined to be unconstrained. And in any case, what doe Pi have to do with traceroute?)

It brings it back full circle?
It's as easy as pi?
It's as wholesome as motherhood and apple pi?

> It isn't evident to me that this needs to be in SDP either. It could easily be in SIP, since this is really about indicating that the response is from exhaustion of the Max-Forwards rather than from reaching the intended destination. E.g. a Reason header might work, or some new header. Or this might justify defining a new 2xx response code.
> 
> Actually,a new 2xx code sounds quite attractive to me. E.g., 205 Too Many Hops.

The rationale for putting it in SDP, which I thought you had agreed with previously, was that using a new header/param/code would be less likely to survive its way back to the UAC - middleboxes would remove/change stuff.  Whereas with SDP, if the media-loopback SDP got through middleboxes to the device answering this thing, then the odds are good that something in the SDP answer would make it back as well.  Although now that I think about it, sess-id isn't a good one to pick because of the middlebox problem.  So something else in SDP then.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 17:45:59 -0400

> The rationale for putting it in SDP, which I thought you had agreed with previously, was that using a new header/param/code would be less likely to survive its way back to the UAC - middleboxes wou…

OK, I guess we did have some discussion on that.

By that argument it must be something *existing* in SDP that is never 
messed with. That is a high bar.

You have a product that messes with SDP. When you do so, do you mess 
with the version? (It seems like you *ought* to, since you are changing it.)

Do you think that a new return code would cause trouble this way?
I would think that to be fairly innocuous. But there are no guarantees 
when going through a B2BUA.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 22:12:46 -0400

On Jul 15, 2013, at 5:45 PM, Paul Kyzivat <[email-masked]> wrote:
> By that argument it must be something *existing* in SDP that is never messed with. That is a high bar.
> 
> You have a product that messes with SDP. When you do so, do you mess with the version? (It seems like you *ought* to, since you are changing it.)

Sometimes yes, sometimes no.  But I'm not too worried about my product - it's more the *other* B2BUAs and SBCs I'm worried about.

> I would think that to be fairly innocuous. But there are no guarantees when going through a B2BUA.

I honestly have no idea.  I don't know what most vendor products would do with a previously-unknown response code number coming back.

It feels like the right thing to do from a protocol perspective, but I don't know what would happen.

We could also, in the same 205 response, insert a Reason header with "SIP;cause=483" as the value.  That way even if it's converted to a 200 OK response, the Reason 
header might make it back. (ugly hack, but the whole problem is ugly)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jul 2013 12:04:48 -0400

> Sometimes yes, sometimes no.  But I'm not too worried about my product - it's more the *other* B2BUAs and SBCs I'm worried about.

Well, the fact that you say "sometimes yes" already suggests problems.

> header might make it back. (ugly hack, but the whole problem is ugly)

I like it!

I thought about the Reason header, but couldn't think of a way to use it 
without introducing a new reason namespace. What you suggest does it 
with existing ones. I don't see it as a bad hack.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 19 Jul 2013 18:25:26 +0000

>>> Do you think that a new return code would cause 
>>> trouble this way?  I would think that to be fairly 
>>> innocuous. But there are no guarantees when going 
>>> through a B2BUA.
>>
>> I honestly have no idea.  I don't know what most 
>> vendor products would do with a previously-unknown 
>> response code number coming back.

I know that the 205 with Reason solution will not work with all B2BUAs.  However, I assume that the B2BUA vendors/administrators would adjust as needed.

>> It feels like the right thing to do from a protocol 
>> perspective, but I don't know what would happen.
>>
>> We could also, in the same 205 response, insert a 
>> Reason header with "SIP;cause=483" as the value.  
>> That way even if it's converted to a 200 OK response, 
>> the Reason header might make it back. (ugly hack, 
>> but the whole problem is ugly)
> 
> I like it!

As I mentioned within the following link, using the Reason header (or the other listed options) sounds okay to me.

http://www.ietf.org/mail-archive/web/straw/current/msg00131.html

The new status-code also sounds okay.  I'm not sure if the service needs a new status-code; however there are numerous 2xx values still available.  Although potentially not intended, it might set a precedent of sending 2xx with a Reason header when B2BUA configured to answer a call to play treatment because of other SIP failure responses.

Other than providing two ways to communicate the same thing, do we need both mechanisms?  For instance, are customers/vendors actually wanting/needing both options?  Should the draft provide even more options so that it can work with even more middle boxes without requiring code/configuration modification?

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Jul 2013 15:22:45 -0400

> Other than providing two ways to communicate the same thing, do we need both mechanisms?  For instance, are customers/vendors actually wanting/needing both options?  Should the draft provide even m…

What are the *two* mechanisms? Do you mean the 205 and the Reason?

My reasoning for the 205 is that while this is indeed a success 
response, it is far from a normal success response - it is distinctly weird.

The Reason provides more nuance as to *why* this odd response is being 
returned.

But I agree that a 200 with a Reason of 483 would be pretty weird for 
any other reason, so might be sufficient here.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Sat, 20 Jul 2013 14:30:42 +0000

> > I know that the 205 with Reason solution will not work with all
> B2BUAs.  However, I assume that the B2BUA vendors/administrators would
> adjust as needed.
> >
> > As I mentioned within the following link, using the Reason header (or
> the other listed options) sounds okay to me.
> >
> > The new status-code also sounds okay.  I'm not sure if the service
> needs a new status-code; however there are numerous 2xx values still
> available.  Although potentially not intended, it might set a precedent
> of sending 2xx with a Reason header when B2BUA configured to answer a
> call to play treatment because of other SIP failure responses.
> >
> > Other than providing two ways to communicate the same thing, do we
> need both mechanisms?  For instance, are customers/vendors actually
> wanting/needing both options?  Should the draft provide even more
> options so that it can work with even more middle boxes without
> requiring code/configuration modification?
> 

Yes.  The current proposal is for the middle box to send both 205 and the Reason header but allow the UAC to interpret the situation based upon either mechanism since another middle might remove the Reason header or change the 205 into a 200.

Thanks,
Brett

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 10:43:25 -0400

> http://www.ietf.org/mail-archive/web/straw/current/msg00131.html

Ahh, sorry missed that - I saw the email and my brain shut off when I saw "RFC 5373". :)

> Other than providing two ways to communicate the same thing, do we need both mechanisms?  For instance, are customers/vendors actually wanting/needing both options?  Should the draft provide even m…

I don't know if vendors care either way - do you?  I don't.  I think doing two ways is already a bit silly but possibly justifiable for other reasons than to get through middleboxes; doing three or more would look crazy. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 10:46:20 -0400

> Yes.  The current proposal is for the middle box to send both 205 and the Reason header but allow the UAC to interpret the situation based upon either mechanism since another middle might remove th…

Well that's our unofficial reason for doing it - the official rationale would be the 205 indicates that some other system/UAC than the intended target is answering the request, and the Reason header indicats why it's answering the request.

See it sounds so reasonable, doesn't it?  :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Jul 2013 13:23:10 -0400

> See it sounds so reasonable, doesn't it?  :)

Sounds reasonable to me.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Sat, 20 Jul 2013 17:45:26 +0000

> > Yes.  The current proposal is for the middle box to 
> > send both 205 and the Reason header but allow the 
> > UAC to interpret the situation based upon either 
> > mechanism since another middle might remove the Reason
> > header or change the 205 into a 200.
> 
> Well that's our unofficial reason for doing it - the 
> official rationale would be the 205 indicates that some 
> other system/UAC than the intended target is answering 
> the request, and the Reason header indicats why it's 
> answering the request.
> 

:)

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?

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?

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Jul 2013 14:01:29 -0400

> 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 head…

Maybe.

But I think it depends a bit on the identity of the middle box.

If it is authorized to act on behalf of the R-URI of the request, then 
its response should probably get a 200. In other cases this 205 response 
is appropriate.

So for your example, if the middle box is on the callee side you would 
get a 200, but if the middle box is on the caller side then a 205.

But it will probably take some careful wordsmithing to get a clear 
definition for this.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 14:02:04 -0400

> 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 head…

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

---

From: Brett Tate <[email-masked]>
Date: Sat, 20 Jul 2013 18:27:04 +0000

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

You indicated that the "unofficial reason" was reflected by my statement "send both 205 and the Reason header but allow the UAC to interpret the situation based upon either mechanism since another middle might remove the Reason header or change the 205 into a 200".

If the 205 was received without Reason, how would the UAC know that the received 205 (without Reason) was because of draft-straw-sip-traceroute's Max-Forwards stuff instead of another use for 205?

Thanks,
Brett

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jul 2013 18:32:36 +0000

(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ä: [email-masked] [mailto:[email-masked]] Puolesta Hadriel Kaplan
Lähetetty: 20. heinäkuuta 2013 21:02
Vastaanottaja: Brett Tate
Kopio: [email-masked]
Aihe: Re: [straw] draft-straw-sip-traceroute-00

-hadriel