Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hello Hadriel,
Thanks for responding to my comments, it seems that most of them are now fixed :-) To try to clarify the remaining couple of comments:

I think the draft text in clause 3.1 Processing a Received Max-Forwards Header Field (lines 206 - 208)] "As currently defined in [RFC3261], the UAS half of a B2BUA does not technically need to inspect the Max-Forwards header field value for received requests - only Proxies do." should be clearer in terms of what the implementer actually has to do. 

You replied that "...I think it is in fact in doubt.  I know of many B2BUAs which do in fact decrement max-forwards. (and I think they're right to)". So what does the implementer do? Be happy that they might not need to change too much? Make sure all of their B2BUAs decrement Max-Forwards whether they will loopback media or not? Be aware that if they don't want their B2BUA to decrement Max-Forwards then they can't use this mechanism? Something else?

To clarify my comment " How the mechanism works would be clearer if clause 3. had individual sub-clauses that describe the specific behaviour of a UAC, Proxy, B2BUA, and UAS.", I am suggesting the kind of structure below. As one example, clause 3.2 Answering the INVITE mixes B2BUA and UAS behaviour suggesting that they can be considered in the same way but the UAS behaviour might impact a user and I think it's likely that a UAS will reject loopback requests. 

3. The SIP Traceroute Mechanism
Overview and signalling example

3.1 Originating UA Procedures
Constructing an INVITE request including choosing the Request-URI, assigning a value to Max-Forwards, constructing SDP
Processing a 483 response (from proxy, from b2bua, from terminating UA)
Processing a 200 response (from b2bua, from terminating UA)
Processing a rejection from the terminating UA, either in SDP or as a SIP response

3.2 B2BUA Procuedures
Decrementing Max-Forwards
Processing SDP and setting up loopback
Assigning Reason header value
Sending a SIP response (200 or 483)

3.3 Terminating UA Procedures
Similar to 3.2 but how does a terminating UA reject the loopback request? in SDP or by a SIP response? I think clause 4. Security Considerations should refer to RFC 6849 to point out that a UAS which is looping back should alert the user and loopback can have DoS implications. 



Peter



-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: 16 December 2013 19:25
To: Dawes, Peter, Vodafone Group
Cc: [e-mail]
Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt


Thanks for the comments Peter! - responses below...


On Dec 13, 2013, at 4:30 AM, Dawes, Peter, Vodafone Group <[e-mail]> wrote:

> [draft text 1: clause 2. Introduction (lines 121 - 127)] In many 
> deployments, the media for SIP-created sessions does not flow directly from the originating user's UAC to the answering  user's UAS.  Often, SIP B2BUAs in the SIP signaling path participate in the media plane, either for injecting media such as rich-ringtones or music-on-hold, or for relaying media in order to provide functions such as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, media steering, etc .
>  
> [comment 1: It would be helpful to indicate how the B2BUA participates 
> in the media plane with the text such as below] In many deployments, the media for SIP-created sessions does not flow directly from the originating user's UAC to the answering user's UAS.  Often, SIP B2BUAs in the SIP signaling path also insert themselves in the media plane path by manipulating SDP, either for injecting media such as rich-ringtones or music-on-hold, or for relaying media in order to provide functions such as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, media steering, etc .

Done.

> [draft text 2: clause 2. Introduction (line 135)] If failures or 
> degradation occurs in the media plane
>  
> [comment 2: Typo, change as below]
> If failures or degradation occur in the media plane,

Done.

> [draft text 3: clause 2. Introduction (line 137)] to aid managing and 
> troubleshooting SIP-based sessions and media crossing such B2BUAs, it would be useful to be able to test the media path to each B2BUA separately from the source.
>  
> [comment 3: Unclear what the word "separately refers to. Suggested 
> re-wording below] to aid managing and troubleshooting SIP-based sessions and media crossing such B2BUAs, it would be useful to be able to progressively test the media path as it reaches successive B2BUAs with a test controlled in a single-ended way from the source UA.

Done.

> [draft text 4: clause 2. Introduction (lines 139 - 144)] A mechanism 
> to perform media-loopback test sessions has been defined in [RFC6849], but it would be difficult to use the mechanism directly to test B2BUAs because typically the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given session.
>  
> [comment 4: I guess that the existing mechanism cannot be used. 
> Suggested re-wording below] A mechanism to perform media-loopback test sessions has been defined in [RFC6849], but it cannot be used to directly to test B2BUAs because typically the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given session.

Done.

> [draft text 5: clause 2. Introduction (lines 151 - 155)] A better 
> solution would be to make a test call targeted to Bob, but with a SIP traceroute-type mechanism that makes the call terminate at the B2BUAs, such that she can perform test sessions to test the media path to each downstream B2BUA .
>  
> [comment 5: With one test call after another, will the media always 
> take the same path?]

No not necessarily, but I don't see that there's anything we can do about that. :(


> [draft text 6: clause 2. Introduction (lines 157 - 169)] This document 
> defines how such a mechanism can be employed, using the [RFC6849] mechanism along with the Max-Forwards SIP header field such that a SIP User Agent can make multiple test calls, each reaching a B2BUA further downstream. Each B2BUA in the path that supports this mechanism would answer the media-loopback call, and thus the originating SIP UA can test the media path up to that B2BUA.
>  
> [comment 6: Not clear what "this mechanism" refers to. Suggested 
> re-wording below] supports the mechanism in [RFC6849] would answer the 
> media-loopback call , and

Done.

> [draft text 7: clause 2. Introduction (lines 189 - 195)] The 
> originating UAC can then generate another INVITE to the same target 
> AoR with a B2bua-Hops header value of 1 , which will reach the second 
> B2BUA that supports this mechanism, and so on.  A defined [RFC3326] 
> SIP Reason header field cause value will be in the 200 answer from 
> each B2BUA answering the INVITE, until the INVITE reaches the final 
> UAS, which does not use the Reason cause value. (see Section 3.2 for 
> details)
>  
> [comment 7: If for example the signalling follows a path 
> B2BUA-Proxy-B2BUA then a hops value of 1 will reach the proxy not the 
> next B2BUA.]

Yeah the wording in that section got all screwed up when I removed the B2bua-Hops header thing.  I think I've cleaned it up now.


> [draft text 8: clause 3.1 Processing a Received Max-Forwards Header 
> Field (lines 206 - 208)] As currently defined in [RFC3261], the UAS half of a B2BUA does not technically need to inspect the Max-Forwards header field value for received requests - only Proxies do.
>  
> [comment 8: The word "technically" suggests some doubt about whether 
> an RFC 3261 compliant B2BUA decrements the Max-Forwards header field or not. Suggested re-wording below] [RFC3261] requires proxies to inspect the Max-Forwards header field but not a B2BUA.

But I think it is in fact in doubt.  I know of many B2BUAs which do in fact decrement max-forwards. (and I think they're right to)


> [draft text 9: clause 3.2. Answering the INVITE]
>  
> [comment 9: It is possible for a Max-Forwards header field value to 
> fall to zero for a call that is not a test call. A B2BUA that supports 
> this draft would answer such a call, which would be unexpected 
> behaviour as far as the calling party is concerned. How is this 
> avoided?]

The SDP won't have loopback.


> [draft text 10: clause 5. IANA Considerations]
>  
> [comment 10: Nothing stops another mechanism using the Reason text 
> "Traceroute Response" as this is not in any IANA registry so the 
> mechanism should not depend on Reason text.]

It doesn't depend on it - I've added some wording to make that clearer.


> [draft text 11: clause 3. The SIP Traceroute Mechanism]
>  
> [comment 11: How the mechanism works would be clearer if clause 3. had 
> individual sub-clauses that describe the specific behaviour of a UAC, 
> Proxy, B2BUA, and UAS.]

Not sure what you mean?

-hadriel