Subject: [straw] Call for WG adoption: draft-kaplan-straw-sip-traceroute-01.txt

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Jun 2013 07:56:56 +0000

(As co-chair)

Hi,

Based on the discussions in Orlando, Hadriel has submitted a new version (-01) of draft-kaplan-straw-sip-traceroute:

http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt

As discussed, once the draft is submitted, the chairs will call for WG adoption of the draft, as base for the following WG charter delivery:

"A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls submitted to the IESG as PS"

So, as no other proposals to implement the delivery have been submitted, the chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-01 as base for the delivery above, and that anyone who has issues with that raises those issues it on the list by Friday 5th July.

Thanks!

Christer & Victor

Ps. The notes from Orlando can be found at: http://www.ietf.org/proceedings/86/minutes/minutes-86-straw

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Jun 2013 14:12:50 -0400

I should note there is one open issue in this draft.  The issue is that there is no way to determine when you've reached the final/real target UAS.

There are multiple ways of doing it, but each has pro's/con's.

At a high-level, I think there're two paths:
1) Have the final UAS insert something somewhere in the signaling back, to say "I'm the target you're looking for".
2) Have all the B2BUAs insert something in signaling back to say "We're not the droids you're looking for".

My vote is (2) makes more sense, because it's possible for the real target not to implement this draft whatsoever but still function correctly, because the real target only has to implement media-loopback RFC.  The B2BUAs are the ones to have to read and comply with this spec, so might as well make them do whatever new thing we need.  Besides which it just feels weird to have to make a UAS respond with "yes it's really me". :)

The next problem is exactly what token to insert in what header/SDP field.  As usual, it's very tricky to pick a field that will survive the whole way back in the 200 ok.  It's basically a game of probability.  Some options:
A) A Contact header param or URI param, which is arguably the right place to put such a token. 
B) A To header param.
C) In the SDP answer.

My vote is (C), because I think it has the best chance to survive back, under the premise that if a media-loopback SDP offer works all the way from UAC to the responding B2BUA, then an extra attribute in the answer will likely work too.  I think the Contact is the more natural/logical place, but is doomed to fail.  As justification for putting the token in SDP, I guess we could claim the token signifies the final media target hasn't been reached, and that this is a media middlebox device responding instead.

-hadriel

On Jun 17, 2013, at 3:56 AM, Christer Holmberg <[email-masked]> wrote:

> “A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls submitted to the IESG as PS”
>  
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jun 2013 23:14:32 -0400

Hadriel,

I was going to agree with you on (C), and then I got thinking...

That makes good sense if we are doing traceroute with INVITE and media 
loopback,

but what if we wanted to do a more basic traceroute, say with OPTIONS, 
where there was no O/A. In that case how would we identify reaching the 
target?

Looking, this isn't covered at all in this draft. But isn't it a 
reasonable thing to want to do?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Jun 2013 23:43:03 -0400

On Jun 18, 2013, at 11:14 PM, Paul Kyzivat <[email-masked]> wrote:

> That makes good sense if we are doing traceroute with INVITE and media loopback,
> 
> but what if we wanted to do a more basic traceroute, say with OPTIONS, where there was no O/A. In that case how would we identify reaching the target?
> 
> Looking, this isn't covered at all in this draft. But isn't it a reasonable thing to want to do?
> 

Well this is a draft about media loopback traceroute, not OPTIONS traceroute.  I believe RFC 3261 already specifies using Max-Forwards for a traceroute with OPTIONS, with Proxies responding to it.  I don't believe it says anything about knowing you reached the target, so it must not be a problem for OPTIONS, right?  Ergo, no problem for OPTIONS.  ;)

Oh wait... an OPTIONS response can actually contain SDP if I recall, to indicate media capabilities.  So we *could* put one in there.  Yeah, that'll happen...

On a more serious note though - I just don't know of any appropriate header field param we could create that has a high chance of making it back in a 200 ok.

I suppose we could specify *both* the Contact and SDP - for the OPTIONS case, only put it in a Contact; for the INVITE case, put it in both.  the UAC checks both and if either is there, it knows.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2013 00:16:44 -0400

> Well this is a draft about media loopback traceroute, not OPTIONS traceroute.  I believe RFC 3261 already specifies using Max-Forwards for a traceroute with OPTIONS, with Proxies responding to it.…

Well, this draft is also about getting through SBCs. Some of the same 
issues apply for getting OPTIONS through SBCs with the Max-Forwards 
preserved. And there might be the same issue of wanting to determine if 
you have gotten to the end.

OTOH, you have a point - how does regular traceroute with OPTIONS know 
it has gotten to the end? The only way I can see is that it tries to go 
one hop further and finds that the return is from the same place. Is 
there any other way?

If that works, then why wouldn't the same thing work for the traceroute 
in this draft?

> I suppose we could specify *both* the Contact and SDP - for the OPTIONS case, only put it in a Contact; for the INVITE case, put it in both.  the UAC checks both and if either is there, it knows.

OK, after this discussion, I suggest one of the following:

- do whatever is done with regular traceroute with OPTIONS.

- do your option (C) and forget about my question.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 04:26:22 +0000

(As co-chair)

Hi Hadriel,

Thanks for pointing out the open issue.

However, we don't need to solve it in order to adopt the draft :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Hadriel Kaplan
Lähetetty: 18. kesäkuuta 2013 21:13
Vastaanottaja: [email-masked]
Aihe: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 01:32:10 -0400

On Jun 19, 2013, at 12:16 AM, Paul Kyzivat <[email-masked]> wrote:

> Well, this draft is also about getting through SBCs. Some of the same issues apply for getting OPTIONS through SBCs with the Max-Forwards preserved. And there might be the same issue of wanting to determine if you have gotten to the end.

I'm not sure I would go near OPTIONS handling and SBCs.  We had a massive debate about that on one of the old mailing lists a few years ago when someone (Paul Jones?) submitted a draft on doing health checking using OPTIONS to SBCs.  We all do it, but no one could agree on what the right things to do are and it generated a LOT of debate if I recall, with no consensus.

> OTOH, you have a point - how does regular traceroute with OPTIONS know it has gotten to the end? The only way I can see is that it tries to go one hop further and finds that the return is from the same place. Is there any other way?
> 
> If that works, then why wouldn't the same thing work for the traceroute in this draft?

You don't know you reached the real target because the 200 ok looks the same regardless who sent it, because B2BUAs generally replace received Contact URIs (along with most other such identifying header fields/URIs) with their own.  After all, they're a UA on each side. :)

Imagine a scenario like: Alice -> B2BUA1 -> B2BUA2 -> Bob.  

Round-1) Alice makes test call with MF=0.  B2BUA1 answers 200 ok with Contact of itself.  Alice receives answer with Contact of B2BUA1.

Round-2) Alice makes test call with MF=1.  B2BUA1 forwards it, B2BUA2 answers 200 ok with Contact of itself, which B2BUA1 dutifully replaces with Contact of B2BUA1.  Alice receives answer with Contact of B2BUA1.

Round-3) Alice makes test call with MF=2.  B2BUA1 and B2BUA2 forward it, Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with Contact of B2BUA1.  Alice receives answer with Contact of B2BUA1.

Round-4) Alice makes test call with MF=3.  Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with Contact of B2BUA1.  Alice receives answer with Contact of B2BUA1.

Alice can't know to stop after Round-3, or even after Round-4.  Arguably, the problem is really that Alice can't determine the difference in any round above to begin with.  If we could solve that, then we could just let Alice do Round-4, detecting it's the same result as Round-3, and stopping at that point.

But I don't know how to do that in a way that B2BUAs (and in particular SBCs and their owners), would allow to be sent through.  Wellll... maybe I do - I suppose we could put in a hashed cookie in a defined Contact header param.  Something that hashes to the same value given the same received inputs, but is useless as a target.  It doesn't even need to be defined how to generate it; just something with that property, so that Alice can tell she's reaching the same UAS or not.  It might work. Have to chew on it for a while.

-hadriel

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 19 Jun 2013 02:08:48 -0400

> I'm not sure I would go near OPTIONS handling and SBCs.  We had a massive debate about that on one of the old mailing lists a few years ago when someone (Paul Jones?) submitted a draft on doing hea…

Yep.  It generated LOTS of discussion (on the order of hundreds of emails) and we never could come to an agreeable consensus on how to move forward (a shame IMO).  Here it is:

http://tools.ietf.org/html/draft-jones-sip-options-ping

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 12:14:42 -0400

OK, forget it. Option (C) works for me.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 21 Jun 2013 13:37:44 +0000

> 1) Have the final UAS insert something somewhere in the 
> signaling back, to say "I'm the target you're looking for".
> 2) Have all the B2BUAs insert something in signaling back 
> to say "We're not the droids you're looking for".

Option 2 sounds appropriate.  However I think that section 3.2 would need to clarify how it knows that it is not the droid you're looking for.  I assume that the answer is that it is the droid you're looking for unless Max-Forwards is the reason that the request was not relayed to a subsequent external (or internal) destination.

> The next problem is exactly what token to insert in what 
> header/SDP field.  As usual, it's very tricky to pick a 
> field that will survive the whole way back in the 200 ok.
> It's basically a game of probability.  Some options:
> A) A Contact header param or URI param, which is 
> arguably the right place to put such a token.
> B) A To header param.
> C) In the SDP answer.

This draft basically introduces a new service (RFC 5373 variant) to trigger automatically answering a call (thus there might be similar RFC 5373 IPR claims).  Unless it would be appropriate to communicate the "reason for auto answer" within the above locations, it sounds appropriate to introduce a new header, new use for Answer-Mode, or new use for Reason header.

Should this draft be an RFC 5373 extension for auto-answering?  For instance, the draft could introduce a new answer-mode-param (or new answer-mode-value).  The new parameter could be sent within INVITE to clearly communicate to middle box to follow this draft.  The new parameter (and/or another parameter) could be within INVITE's 2xx to satisfy the open issue.

Thanks,
Brett