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

[Richard Barnes <[e-mail]>]

Hey Hadriel,

Are you OK with the below text for 3.2?  If so, I'll mark us as agreed, and
send this on to LC.

--Richard


On Fri, Apr 11, 2014 at 10:48 PM, Richard Barnes <[e-mail]> wrote:

> On Fri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan <[e-mail]
> > wrote:
>
>>
>> On Apr 11, 2014, at 3:29 PM, Richard Barnes <[e-mail]> wrote:
>>
>> > 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.
>>
>> Good point. So that's another benefit then. B2BUAs solve call failure
>> problems they didn't even know existed.
>> ;)
>>
>> Actually, getting back to serious mode, that could happen even without
>> this draft. Max-Forward handling in B2BUAs has always been undefined
>> behavior until the loopback draft, afaik.
>
>
> Good point.  I did not have this in mind.
>
>
> > 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)
>>
>> I'm fine with that.  Another option is to re-title this draft to be
>> "Media-Loopback Usage in SIP" and add some text about that in general too.
>>
>>
>> > 2. Add some consent flag to the INVITE so that the B2BUA can tell
>> traceroutes from other INVITEs
>>
>> It won't help solve the problem you raised fully - it will help if all
>> B2BUAs along the path implement this draft, but not if they just implement
>> RFC 6849. Because they can still answer calls based on policy, and
>> Max-Forwards=0 technically doesn't apply to them as a UAS unless they also
>> implement the loopback draft.
>>
>
> How about this in 3.2?
>
> """
> The mechanism defined in this document could cause B2BUAs to send a 200
> response to an INVITE that is not part of a traceroute.  In such cases, the
> UAC would believe that it was exchanging media with the end UAS, when in
> reality it is talking to an intermediate B2BUA.  The UAC can recognize this
> situation by examining the Reason header.  It is RECOMMENDED that UACs
> implementing RFC 6849 perform this check.  (Note that this problem is not
> introduced by this document, since the behavior of B2BUAs with regard to
> Max-Forwards has been undefined until the publication of
> [I-D.ietf-straw-b2bua-loop-detection].)
> """
>
>
>
>>
>> -hadriel
>>
>>
>