There are some messy problems regarding what RouteState is intended to do. First, let's clarify that Record-Route and Route headers identify the "passages" of a request through proxies that want to remain in the signaling path for future dialogs. Each passage is independent of each other passage, except in the uncommon situation where they must cooperate to do something. It may happen (if the routing is sufficiently complex) that two passages are through the same proxy, but that is usually not important, as the two passages will perform different tasks.
Let's take the current example of supporting NAT traversal. (Are there any other current examples of RouteState?) Suppose a request passes through NAT traversal *twice* on its way to the destination. That means that later requests in the dialog will also pass through NAT traversal twice. And it's clear that passage 1 of NAT traversal of the original request will want to communicate with passage 1 of NAT traversal of the later request. And similarly for passage 2 of both requests. The interesting question is whether passage 1 wants to communicate with passage 2. If both passages go to the same destination, it would make sense. But if the passages go to different destinations (which can be arranged with suitably ugly call routes), then the two passages wouldn't want to share information, as there is nothing in common about the tasks that they do. Of course, if the plugin tags RouteState information properly, the two passages can keep their information separate even if the RouteState mechanism merges their RouteState data. A further complication is if a plugin uses "double Record-Routing" -- the RouteState information will be attached consistently to one of the Record-Routes, either the first or the second. But requests passing in the opposite direction will have the order of the RouteState values reversed, and so the value will be seen in (respectively) the second or the first Route. So always looking at the top Route is not sufficient to find the RouteState value that corresponds to the current passage if plugins use double Record-Routing. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
