Subject: [dispatch] Comments on Straw WG proposal and related deliverals

From: Qin Wu <[email-masked]>
Date: Fri, 02 Dec 2011 10:01:36 +0800

Hi, Hadriel:
  Your Straw WG proposal in DISPATCH meeting looks interesting to me. Unfortunetely I was not present in the Dispatch when I was in Taipei meeting.

  So I read your drafts related to Straw and have couples of questions:
  1. Why SIP request routing loop will happen? Isn't SIP request initiated from one end and terminated at the other end?
     Is SIP request routing loop only apply to some subset of SIP message type?
  2. What cause unending SIP request routing loop? Is it becos media loop back? How media loop back has to do with signaling loop back?
  3. What's the difference between end to end media loopback and hop by hop media loopback? what message signaling exchange looks like?
  4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you intend to drop these header extension or reuse these header extension and fill the missing part?
  5. Is there any tools at the SIP level like trace route and ping to test the path reachability?
  6. Why B2BUA1 at the one end should care about how many paths it can go through to the B2BUA2 at the other end? Isn't SIP request routed in the transparent manner?
  7. How many B2BUAs from one end to the other end should be traversed in the path?

  I will be appreciated if you can clarify a little bit to me?

  Regards!
  -Qin

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Dec 2011 14:42:54 +0000

Hi Qin, 
comments inline...

>     Is SIP request routing loop only apply to some subset of SIP message type?

In theory it applies to any out-of-dialog request type, but typically it happens with INVITEs today.
The "loop" is just that the INVITE gets routed across proxies/B2BUAs, and at some point it reaches a proxy/b2bua that routes the request back upstream - either literally back to the same previous proxies/b2buas or to another proxy/b2bua which eventually routes it back to the same one that erroneously sent it upstream.  In deployed networks this is usually caused by misconfiguration of dial-plans/routing-tables, but has also occurred due to call-forwarding loops.  

If all the SIP devices were strict Proxies, then they'd detect and stop the loop based on either the Via header check or Max-Forwards reaching 0.  But with B2BUAs the Via isn't usable for loop detection, and some B2BUAs reset the Max-Forwards value, so draft-kaplan-dispatch-b2bua-loop-detection-00 says not to do that but instead copy and decrement the Max-Foreards.

>  2. What cause unending SIP request routing loop? Is it becos media loop back? How media loop back has to do with signaling loop back?

No the two have nothing to do with each other.  Draft-kaplan-dispatch-b2bua-loop-detection-00 is just about signaling loops (which are bad).  Draft-kaplan-dispatch-sip-traceroute-00 is about using media-loopback for call testing, but is not about a "loop" at the signaling layer.

>  3. What's the difference between end to end media loopback and hop by hop media loopback? what message signaling exchange looks like?

End-to-end media-loopback would be just a media-loopback session based on draft-ietf-mmusic-media-loopback-16, and thus a session to the target of the request.  So for example if you make a loopback test call to +17815551212, then your SIP INVITE request would reach the UAS representing +17815551212, and that UAS would loop media back to you.  Hop-by-hop is where you'd make a loopback test call to +17815551212, but the first time you'd make it the first media-plane B2BUA along the path to +17815551212 would actually answer the call and loop media to you; the second time you'd make it the second B2BUA along the path would answer the call, and so on until you'd finally reach +17815551212.  That way you can test the signaling+media path on a hop-by-hop basis towards the target destination.

>  4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you intend to drop these header extension or reuse these header extension and fill the missing part?

I don't know what you mean - where do I say there's a missing feature?

>  5. Is there any tools at the SIP level like trace route and ping to test the path reachability?

Sort of, but not always.  You can just send OPTIONS requests as a form of "ping", but not all devices support it and it's not always clear that the OPTIONS got the whole way to the target (I've been told some B2BUAs answer OPTIONS not targeted at them).  If OPTIONs works, you can also reduce the Max-Forwards for the OPTIONS request as form of traceroute, but since some B2BUAs reset Max-Forwards that doesn't always work.

>  6. Why B2BUA1 at the one end should care about how many paths it can go through to the B2BUA2 at the other end? Isn't SIP request routed in the transparent manner?

If you mean in draft-kaplan-dispatch-sip-traceroute-00, the purpose is for troubleshooting.  There will obviously be strict rules/policies on B2BUAs that support this draft as to whether they accept such requests and from whom, and when.  For example I doubt they'd let user/consumer UAs perform this test - more like only operator/administrator test devices.  And obviously if the operator doesn't want to let anyone do this they can just not enable it to begin with.

>  7. How many B2BUAs from one end to the other end should be traversed in the path?

There's no limit in theory, though in practice I think the default Max-Forwards value of 70 is reasonably high enough never to be reached for good calls.

-hadriel

---

From: Qin Wu <[email-masked]>
Date: Tue, 06 Dec 2011 16:25:38 +0800

Hi, Hadriel:
Thank for your useful clarification. I have some followup comments below.
----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 02, 2011 10:42 PM
Subject: Re: Comments on Straw WG proposal and related deliverals

Hi Qin, 
comments inline...

[Qin]: In the loop detection mechanism you proposed, How do you prevent some bad B2BUAs in the path without support of loop mechanism  resetting the MAX-Forward value or you need to assume all the B2BUAs in the path should support loop detection mechanism you proposed?

Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via header?

[Qin]: Okay. I see.

[Qin]: Good example, Now I know their difference.
But one more question is:

why each B2BUAs in the path more close to the user/consumer device answer the 
call on behalf of UAS representing +17815551212? Is that 
becos this is test signaling? or new SIP request type only for test?

[Qin]: That's what you mentioned in the open issue section 5 of draft-kaplan-dispatch-sip-traceroute.
The question is do you want to fix MAX-Forward or Do you want to define new header extension?
This is a little contradict to me when reading draft-kaplan-dispatch-b2bua-loop-detection and draft-kaplan-dispatch-sip-traceroute.
It looks to me in draft-kaplan-dispatch-b2bua-loop-detection, it propose additional new behavior for B2BUAs without any change to MAX-Forward 
while in the draft-kaplan-dispatch-sip-traceroute, it seems it propose some new header extension?

[Qin]: So your proposal can works when some B2BUA reset Max-Forward?

[Qin]: Agree. But do you believe the information about B2BUAs in the path regarding whether they accept such requests and from whom (topological information about the path), and when should be reported to the operator test devices instead of consumer device? How this formation help troubleshooting and pinpoint the root of loop back?

[Qin]: I see and agree.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Dec 2011 20:51:56 +0000

Hi Qin,
I'm splitting the email into two responses: one for the loop detection and a separate one for the traceroute topic.
This is about the loop detection...

> [Qin]: In the loop detection mechanism you proposed, How do you prevent some bad B2BUAs in the path without support of loop mechanism  resetting the MAX-Forward value or you need to assume all the…

If a B2BUA along the loop-path doesn't follow the draft and instead resets the Max-Forwards value, then the loop won't be detected by that mechanism.  That's no worse than not publishing the draft, but obviously no better either.  In the cases of loops I've seen occur in actual deployments, it doesn't cross that many B2BUAs before it loops - usually it's a loop that could be prevented if only one or two B2BUAs would stop resetting Max-Forwards.

> Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via hea…

Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2BUA-1 due to a conflicting route table.  By "sends it" I mean the B2BUA receives an INVITE on its UAS side and generates an INVITE on its UAC side based on that received one, with some headers the same but with new Call-ID/tags/Via/Contact/etc.  If both B2BUAs reset the Max-Forwards to 70 every time they send it to each other, this creates an infinite loop because they'll just keep generating INVITEs to each other until they run out of CPU.  If, on the other hand, each B2BUA copied and decremented the Max-Forwards from the received INVITE into the new INVITE they send, as SIP Proxies do, then the MAx-Forwards would eventually reach the value 0 and whichever B2BUA receives that will reject the INVITE and thus stop the loop from becoming infinite.

The Via header can't be used for this, because it doesn't (and arguably shouldn't) get copied by B2BUAs from a received INVITE on their UAS side to a new one on their UAC side.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Dec 2011 21:25:47 +0000

> becos this is test signaling? or new SIP request type only for test?

In the traceroute case, you'd have a test-device/phone that generates the call using a B2bua-Hops header value of 1, then a value of 2, then 3, and so on each time it makes the test call.  The rest of the message appears exactly the same as a normal loopback call - i.e., it is an INVITE to the final target with other headers being normal, etc.

> while in the draft-kaplan-dispatch-sip-traceroute, it seems it propose some new header extension?

Ahh, I see.  Right, today Max-Forwards can't be used for this traceroute concept because devices reset the Max-Forwards value.  The loop detection draft is an attempt to "fix" that.  So the open question for the traceroute draft is whether it should use Max-Forwards and hope all b2bua's implement the loop-detection draft, or whether it should use a new header like "B2bua-Hops".

> [Qin]: So your proposal can works when some B2BUA reset Max-Forward?

Yes, the traceroute draft currently doesn't rely on Max-Forwards, because it uses a new header.  Of course the new header has to make it through b2bua's (not be deleted), but they don't all have to decrement its value or understand it (only b2bua's which want to answer the traceroute/loopback call would have to do that).

> [Qin]: Agree. But do you believe the information about B2BUAs in the path regarding whether they accept such requests and from whom (topological information about the path), and when should be repo…

I think those types of decisions are policies decided on by the administrators of the b2bua's, rather than something to put in the draft.  It's up to the admin to decide who/what/where/when.  Is that what you're asking? (i.e., does that answer your question, or am I not understanding your question?)

-hadriel

---

From: Qin Wu <[email-masked]>
Date: Mon, 12 Dec 2011 16:32:27 +0800

Hi, Hadriel:
----- Original Message ----- 
>Sent: Saturday, December 10, 2011 4:51 AM

>> [Qin]: In the loop detection mechanism you proposed, How do you prevent some bad B2BUAs in the path without support of loop mechanism  resetting the MAX-Forward value or you need to assume >all the B2BUAs in the path should support loop detection mechanism you proposed?

>If a B2BUA along the loop-path doesn't follow the draft and instead resets the Max-Forwards value, then the loop won't be detected by that mechanism.  That's no worse than not publishing the draft, but >obviously no better either.  In the cases of loops I've seen occur in actual deployments, it doesn't cross that many B2BUAs before it loops - usually it's a loop that could be prevented if only one or two >B2BUAs would stop resetting Max-Forwards.

[Qin]: Really?, I am not sure how many B2BUAs really get invloved in the SIP session call? Suppose Alice place a call to Bob, B2BUA1 is near to Alice and B2BUA2 is near to Bob, both B2BUA2 and B2BUA follow the mechanism in your draft(i.e., stop reseting Max-Forwards), but there is a bad B2BUA3 does not follow this rule(i.e., always reseting Max-Fowards), the Invite message always pass through this bad B2BUA3, How do you prevent such loop?

But I agree with B2BUA on two sides support stopping reseting Max-Foward can alleviate loop harm if loop does happen.

> Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via >header?

>Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2BUA-1 due to a conflicting route table.  By "sends it" I mean the B2BUA receives an INVITE on its UAS side and >generates an INVITE on its UAC side based on that received one, with some headers the same but with new Call-ID/tags/Via/Contact/etc.  If both B2BUAs reset the Max-Forwards to 70 every time they >send it to each other, this creates an infinite loop because they'll just keep generating INVITEs to each other until they run out of CPU.  If, on the other hand, each B2BUA copied and decremented the >Max-Forwards from the received INVITE into the new INVITE they send, as SIP Proxies do, then the MAx-Forwards would eventually reach the value 0 and whichever B2BUA receives that will reject >the INVITE and thus stop the loop from becoming infinite.

[Qin]: 
How B2BUA behavior to deal with Max foward is different from UAC behavior to deal with Max Forward specified in the section 8.1.1.6 of RFC3261 and other Max Foward specifiction described in the section  16.3 and section 16.6 of RFC3261
"
8.1.1.6 Max-Forwards

   The Max-Forwards header field serves to limit the number of hops a
   request can transit on the way to its destination.  It consists of an
   integer that is decremented by one at each hop.  If the Max-Forwards
   value reaches 0 before the request reaches its destination, it will
   be rejected with a 483(Too Many Hops) error response.

   A UAC MUST insert a Max-Forwards header field into each request it
   originates with a value that SHOULD be 70.  This number was chosen to
   be sufficiently large to guarantee that a request would not be
   dropped in any SIP network when there were no loops, but not so large
   as to consume proxy resources when a loop does occur.  Lower values
   should be used with caution and only in networks where topologies are
   known by the UA.

"
"
16.3 Request Validation
   3. Max-Forwards check

      The Max-Forwards header field (Section 20.22) is used to limit the
      number of elements a SIP request can traverse.

      If the request does not contain a Max-Forwards header field, this
      check is passed.

      If the request contains a Max-Forwards header field with a field
      value greater than zero, the check is passed.

      If the request contains a Max-Forwards header field with a field
      value of zero (0), the element MUST NOT forward the request.  If
      the request was for OPTIONS, the element MAY act as the final
      recipient and respond per Section 11.  Otherwise, the element MUST
      return a 483 (Too many hops) response.

"
"
16.6 Request Forwarding
      3. Max-Forwards

         If the copy contains a Max-Forwards header field, the proxy
         MUST decrement its value by one (1).

         If the copy does not contain a Max-Forwards header field, the
         proxy MUST add one with a field value, which SHOULD be 70.

         Some existing UAs will not provide a Max-Forwards header field
         in a request.

"
It is better to specify the Max-Foward behavior difference between this draft and RFC3261. Is it compliant with what it said in the RFC3261?
 since B2BUA has two role, i.e., comination of UAC and UAS.
Also I am aware this draft doesn't explain how loop is detected. Does this mean this draft follows the mechanism specifed in  the RFC3261
"
16.3 Request Validation
   4. Optional Loop Detection check

      An element MAY check for forwarding loops before forwarding a
      request.  If the request contains a Via header field with a sent-
      by value that equals a value placed into previous requests by the
      proxy, the request has been forwarded by this element before.  The
      request has either looped or is legitimately spiraling through the
      element.  To determine if the request has looped, the element MAY
      perform the branch parameter calculation described in Step 8 of
      Section 16.6 on this message and compare it to the parameter
      received in that Via header field.  If the parameters match, the
      request has looped.  If they differ, the request is spiraling, and
      processing continues.  If a loop is detected, the element MAY
      return a 482 (Loop Detected) response.

"
"
16.6 Request Fowarding

      8. Add a Via header field value

         The proxy MUST insert a Via header field value into the copy
         before the existing Via header field values.  The construction
         of this value follows the same guidelines of Section 8.1.1.7.
         This implies that the proxy will compute its own branch
         parameter, which will be globally unique for that branch, and
         contain the requisite magic cookie. Note that this implies that
         the branch parameter will be different for different instances
         of a spiraled or looped request through a proxy.

         Proxies choosing to detect loops have an additional constraint
         in the value they use for construction of the branch parameter.
         A proxy choosing to detect loops SHOULD create a branch
         parameter separable into two parts by the implementation.  The
         first part MUST satisfy the constraints of Section 8.1.1.7 as
         described above.  The second is used to perform loop detection
         and distinguish loops from spirals.

         Loop detection is performed by verifying that, when a request
         returns to a proxy, those fields having an impact on the
         processing of the request have not changed.  The value placed
         in this part of the branch parameter SHOULD reflect all of
         those fields (including any Route, Proxy-Require and Proxy-
         Authorization header fields).  This is to ensure that if the
         request is routed back to the proxy and one of those fields
         changes, it is treated as a spiral and not a loop (see Section
         16.3). 
"
Also when I read section 8.2.2.2 of RFC3261, I am confused, it said:
"
8.2.2.2 Merged Requests

   If the request has no tag in the To header field, the UAS core MUST
   check the request against ongoing transactions.  If the From tag,
   Call-ID, and CSeq exactly match those associated with an ongoing
   transaction, but the request does not match that transaction (based
   on the matching rules in Section 17.2.3), the UAS core SHOULD
   generate a 482 (Loop Detected) response and pass it to the server
   transaction.

      The same request has arrived at the UAS more than once, following
      different paths, most likely due to forking.  The UAS processes
      the first such request received and responds with a 482 (Loop
      Detected) to the rest of them.

"
Is it for loop detection or for duplication request detection?

>>The Via header can't be used for this, because it doesn't (and arguably shouldn't) get copied by B2BUAs from a received INVITE on their UAS side to a new one on their UAC side.

[Qin]: Okay, so what's the standard behavior for proxy to deal with Via header in RFC3261? The reasonable to ask this question is B2BUA is not simply acting as a proxy or a server.

-hadriel=

---

From: Qin Wu <[email-masked]>
Date: Mon, 12 Dec 2011 17:26:06 +0800

Hi, Hadriel:
----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 10, 2011 5:25 AM
Subject: Re: Comments on Straw WG proposal and related deliverals

[Qin]: That is to say each time you make the test call, the test call will reach each B2BUA that support new header in the path one by one. One followup question how does B2BUA answer the test call?
what kind of information should be sent from the B2BUA that support new header? B2BUA keeps state of new header value for each user?  

[Qin]: Does this means Max-Fowards behavior for B2BUA and B2BUA-Hops are two competing mechanisms for the same goal? shall we allow both?

[Qin]: How do you guarantee that the new header can traverse B2BUA? what if one proxy or B2BUA that doesn't support new header between two sides discard the message that carry the new header ? or you just assume the proxy will not drop the new header even the proxy doesn't understand the new header?

[Qin]: Just be curious, but I am okay with your answer.:-)

-hadriel=

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Dec 2011 23:10:23 +0000

> [Qin]: Really?, I am not sure how many B2BUAs really get invloved in the SIP session call? Suppose Alice place a call to Bob, B2BUA1 is near to Alice and B2BUA2 is near to Bob, both B2BUA2 and B2BU…

Of course if N number of B2BUAs are involved in a loop, then N number have to decrement Max-Forwards.  But I was talking about in practice how many are usually involved in the loop - note I said "involved in the loop", not how many B2BUAs does a request traverse.  In other words, a call from Alice to Bob typically goes through many B2BUAs, but what matters is how many are part of the loop itself.  If the loop is because B2BUA3 sends it to B2BUA2 and B2BUA2 sends it back to B2BUA3 and B3BUA3 sends it back to B2BUA2, then B2BUA2 and B2BUA3 could stop the loop if they decremented Max-Forwards, even if B2BUA1 did not.

> It is better to specify the Max-Foward behavior difference between this draft and RFC3261. Is it compliant with what it said in the RFC3261?  since B2BUA has two role, i.e., comination of UAC and UAS.
> 

I believe one could claim the draft clarifies RFC 3261, without changing it.  But I'd be fine with claiming it updated it instead.  I don't much care either way.

> Also I am aware this draft doesn't explain how loop is detected. Does this mean this draft follows the mechanism specifed in  the RFC3261

The draft currently uses the Max-Forwards reaching the value 0 as a loop detection.

> Is it for loop detection or for duplication request detection?

The "Merged Request" portion of 3261 is about the same request reaching the same UAS twice due to forking.  It's not about B2BUAs, although a B2BUA's UAS portion needs to handle Merged Requests. 
(really very little of 3261 considered B2BUAs)

> [Qin]: Okay, so what's the standard behavior for proxy to deal with Via header in RFC3261? The reasonable to ask this question is B2BUA is not simply acting as a proxy or a server.

RFC 3261 provides Proxies with an optional-to-implement loop detection mechanism using the Via header.  RFC 5393 strengthened that by requiring forking Proxies to implement that check, but not non-forking proxies.  And neither 3261 nor 5393 require B2BUAs to perform such a check.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Dec 2011 23:21:29 +0000

> what kind of information should be sent from the B2BUA that support new header? B2BUA keeps state of new header value for each user?  

Nope.  No state needs to be stored in the B2BUAs.  The test-device/UAC making the test calls keeps track of what B2bua-hops header value is uses in each test call it tries.  Basically this whole model follows the same model of ICMP Traceroute done by hosts today: when you do a "traceroute 1.2.3.4", your PC starts with an ICMP Echo request using a TTL of 1, and the first hop it reaches responds with TTL expired, then your PC sends another ICMP with a TTL of 2, and the second IP hop responds, and so on.  So in the SIP case, your tester would generate a SIP call to the target with a B2bua-hops of 0, then 1, then 2.  Each time it is a new SIP dialog request, so it gets new Call-ID and tags, etc., but to the same target number.

> [Qin]: Does this means Max-Fowards behavior for B2BUA and B2BUA-Hops are two competing mechanisms for the same goal? shall we allow both?

No, the two drafts are not competing for the same goal - it's just that the means of performing traceroute testing might be achievable using Max-Forwards if we think the loop-detection draft is likely to be implemented.  But you'd still need both drafts, separately.

> [Qin]: How do you guarantee that the new header can traverse B2BUA? what if one proxy or B2BUA that doesn't support new header between two sides discard the message that carry the new header ? or y…

A "Proxy" would never delete the new header, since a "Proxy" has to follow RFC 3261 which mandates "Proxies" ignore and do not delete unknown headers.  A B2BUA, however, could delete it of course - there's nothing any draft can do about that, no matter what new or old headers/bodies/params/etc. we use for anything ever.  Such "guarantees" are impossible.  BUT, since the point of this draft is to help SIP domain administrators manage and troubleshoot their own networks, then if they want it to work they can tell their B2BUA vendors to do it, and if their B2BUA vendors want to help their customers then they'll do it, and it would then work.  If it's not useful, then people won't ask their vendors to do it, and it won't happen.

-hadriel

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Dec 2011 12:07:57 +0800

Hi, Hadriel:
----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 13, 2011 7:10 AM
Subject: Re: Comments on Straw WG proposal and related deliverals

[Qin]: Sure I believe what you said above. Is there any cases that the mechanism you proposed can not be used to fix the loop problem. Suppose we have 100 loop problems, how many problems we can use the mechanism you proposed to solve?

Also further more, I want to know whether there is some downside to use the mechanism you specified in the draft? Is there any impact to the existing deployment that follow RFC3261 for MAX-Forward processing?

[Qin]: If you really change the RFC3261, it is fair to claim that. But if you don't, it is not harm to make it clear in the document to say the mechanism proposed in the draft is compliant with RFC3261.

[Qin]: Okay.

[Qin]: Is it a mistake for UAS described in the RFC3261 to generate a 482 (Loop Detected) response rather than generate a response to indicate this is about the same request reaching the same UAS?
It looks really confusing to me.

[Qin]: So B2BUA in your draft doesn't need to do such complicated check, rather than use more simpler way, i.e.,use Max-Forwards reaching the value 0 as a loop detection? am I right?

-hadriel

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Dec 2011 15:16:28 +0800

Hi, Hadriel:
----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 13, 2011 7:21 AM
Subject: Re: Comments on Straw WG proposal and related deliverals

[Qin]: I get your idea. One thing is not clear to me is:
in draft-kaplan-dispatch-sip-traceroute , the default value of 70 will be used for the  B2bua-Hops header when A SIP User Agent Client MAY generate a B2bua-Hops header field,
However as you explained above, for traceroute testing, the SIP User Agent Client generates the call using a B2bua-Hops header value of 1, then a value of 2, then 3,
Is there discrepancy here?

[Qin]: Sorry, I agree both traceroute and loop detection mechanism are useful and may be complementary with each other. 
However what I am really asking is whether Max-Forward and B2BUA-Hops is competing? If the loop-detection draft got accepted, does it mean B2BUA-Hops is redundant?
or we allow both coexist?

[Qin]: I agree. Thank for your clarification.

-hadriel