Re: [straw] AD review of draft-ietf-straw-sip-traceroute-02

[Richard Barnes <[e-mail]>]

On Fri, Apr 11, 2014 at 2:22 PM, Hadriel Kaplan
<[e-mail]>wrote:

>
> On Apr 11, 2014, at 1:44 PM, Richard Barnes <[e-mail]> wrote:
>
> > I have reviewed this document in preparation for IETF LC.  It is clearly
> written, but I have one technical concerns that I would like to address
> before IETF LC.
> >
> > I'm concerned that, as described, the mechanism will lead to confusion
> by UAs.  How does a UA that initiates a loopback call know if it got the
> real endpoint or just some intermediate B2BUA that happened to be the last
> one to handle the INVITE?
>
> Section 3.2:
>    ... When the ultimate target UAS answers a loopback-based INVITE
>    with a Max-Forwards greater than or equal to 0, the Reason header
>    would not be added to the response and the UAC will know the
>    traceroute is complete.
>
>
> > Even if there is some indicator, it seems better to have the B2BUAs only
> respond if there's some consent flag (e.g. Supported: middlebox-answer).
>  Otherwise, you're requiring every existing UA to check that it actually
> got all the way through.
>
> It's only requiring UAs that implement this doc to do so; and it's not a
> very hard thing for the UAC to check.
>
> If a UAC just wants to do media-loopback to the final UAS, it would set
> Max-Forwars to 70 on its first attempt. Though it would still need to check
> the answer's Reason header field to verify some B2BUA hadn't answer it due
> to reaching the hop limit, but that's a good thing to check for. Ultimately
> the purpose of media-loopback is for testing+troubleshooting, so giving
> more info isn't a bad thing. :)
>
>
If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 and
answer the call -- they don't know whether this is part of a traceroute or
not.  So if a legacy UAC sends out a normal, non-traceroute, INVITE with
loopback, and it happens to time out at one of these B2BUAs, and the UAC
doesn't know to check for the Reason header for this value (because it's
legacy), then it ends up talking to the B2BUA instead of the UAS.

It seems like in order to resolve this, you need to either:
1. Require UACs that use loopback to check for Reason (and thus update RFC
6849)
2. Add some consent flag to the INVITE so that the B2BUA can tell
traceroutes from other INVITEs

--Richard




> -hadriel
>
>