Dale R. Worley - 2008-03-18 21:16 A typical example is frame 3 of the attached file merged.xml.

Lih-Shyng Tzeng - 2008-03-18 21:16 Robert, Do you have time in the next two months looking into this? If not, please assign it back to me. Thanks.

Dale R. Worley - 2008-03-21 09:38 In a sense, we want to append to the auth proxy address "?X-SipX-Spiral=true", but otherwise not add that header to requests.

Robert Joly - 2008-03-24 21:48 Just to be accurate, when the SIP Proxy receives a message that carries a X-Sipx-Spiral, it performs both the forwarding rules evaluation and the authentication. Given that logic, if a X-Sipx-Spiral-bearing message were to 'escape' only to come back to us later, I think that the call would succeed in most cases. I agree that we should strive to minimize the leakage of messages that have the X-Sipx-Spiral outside of the proxy but I would need some convincing to agree that the sipregistrar is a component that we should shield from such messages. When we think about it, the X-Sipx-Spiral is used to mark packets that are spiraling through the system. and given that the sipregistrar plays an integral part in the spiraling process and that it is visited on every spiral loop, it is normal to think that it will see X-Sipx-Spiral-bearing messages. Do we have real life use case or forcasted features that would call for messages 'escaping' the spiral loop before the spiraling is complete? Having said that I know of one case and perhaps another in which X-sipX-Spiral-bearing messages are sent to 'external' components: 1- message-summary SUBSCRIBE messages received by status server 2- messages received by SBCs configured in the Internet Calling feature (I have not observed that one but I believe that this can happen). When doing the initial design of the feature, i tried to contain the leakage of the X-Sipx-Spiral to a minimum but there are still cases where they leak out. Ideally, the SIP Proxy should remove the X-Sipx-Spiral header once it determines that the spiraling has ended. The problem is that there is no mechanism that the SIP Proxy can use to detect the 'end-of-spiral' event. One approach could be to compare the Route returned by a forwarding rules against the sipregistrar's known hostport and deem that the spiraling is over is they do not match. Another approach could consist in adding a label to every matching rule inside the forwarding rules config file and provide that label back to the caller when forwarding rule matches are found. The SIP Proxy could compare that label against a well-known label of the sipregistrar to determine if we are still spiraling. IMO, the first approach is more feasible and could work in both normal and HA deployments. I will look into it once I am done with my current feature.

Dale R. Worley - 2008-03-25 10:01 I'm behind the times, but it seems to me that X-sipX-Spiral is only needed when a message is specifically forwarded to the auth-proxy function. And in particular, it should not be confused with other operations that people call "spiraling". My assumption when I created this issue is that forwarding to the auth-proxy function is always done through one specific code path and that we could arrange to have X-sipX-Spiral added only on that one code path. (And of course that the "first" thing the auth-proxy function does is remove the X-sipX-Spiral.)

Scott Lawrence - 2008-06-03 10:16 See http://list.sipfoundry.org/archive/sipx-users/msg10641.html This shows that the spiral header is indeed also sent outside the domain.

Al Campbell - 2008-10-07 13:59 Please check in your review