From: Paul Kyzivat <[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote:
> We still need to investigate what History-Info looks like if some of > the participating proxies do not support it. What happens with History-Info if a proxy does not support it, a proxy that is between the most-upstream proxy that adds History-Info and the agent that is interpreting it? There seem to be two messy aspects: 1) There must be an unambiguous way for the SIP agent to determine the History-Info element that is the leaf that applies to it. In principle, there should be only one leaf whose URI matches the current request-URI. But in SIP, "address matching never works". And if there can be intermediate proxies rewriting the request-URI but not updating History-Info, address matching is hopeless. One solution is to rule that the element with the "rightmost" index is always the applicable element. This can probably be made to work, but it requires that even when there is parallel forking, no fork can see another fork until that fork has returned a final response. Another solution is to specifically mark the applicable element with a field-parameter. 2) The intermediate proxy can fork the request. This results in two or more downstream agents adding History-Info elements with the same indexes. Fortunately, only one of these gets back to the upstream proxy, so from that proxy's point of view, assembling the History-Info is unambiguous. However, if a HERFP mechanism allows the upstream proxy to see more than the History-Info for more than one fork under these circumstances, it would have to integrate the History-Info's and may have to renumber the elements. Messy but possible. Right! More importantly, the middle boxes that are intentionally trying to obscure it. It seems that it is common to want to hide all the details. I find it very unlikely that HI will ever be populated in a reliable enough way to be of use in making important decisions. That's only a problem if History-Info from one side of an SBC is needed to make a decision on the other side of the SBC. Or, if History-Info must pass through a topology-hidden network, we would have to ensure that the SBCs cooperate to transport the information through the network. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
