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

[Hadriel Kaplan <[e-mail]>]

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