On Sat, 2008-11-29 at 17:05 -0500, Hadriel Kaplan wrote: > Sorry Adam somehow I missed your email, > The idea is to make it something benign enough that operators of > B2BUA's would not feel the need to mess with it, with as high a > probability as possible, while still have it be usable and useful. > One use for it is simply troubleshooting, but I'd like to make it > usable to help resolve some dialog-matching scenarios that B2BUA's > currently break. > > The properties it needs to have to be as benign as possible, IMO, are: > 1) Needs to not identify any identity property of the generator (no > IP, no host, no domain, no MAC, no username, etc.). If those are > incorporated into the identifier, they must not be discernible to a > receiver of the identifier. > 2) Needs to not directly reveal the call-id/tags were changed. This > is in slight conflict with being usable for dialog-matching, but I put > text in the latest draft why that's ok and B2BUA's shouldn't care. > (and I will publish the latest draft ASAP) > > Unfortunately, such a mechanism is not perfect for dialog matching > uses. For one, it needs both ends to support it - if middleboxes > support it they can do it on behalf of the ends, but the farther away > from the ends they are the less likely the matching will succeed. It > also needs B2BUA's to support it - if a B2BUA doesn't, then the > matching won't work if it hits that B2BUA first. I think that's all > ok, because I think that's unavoidable, and it makes things better > than they are now. > > The other issue with it is a B2BUA can't use the session-id value > alone for matching, because it wouldn't know which dialog side to > match to (it has a UAS and possibly multiple UAC dialogs for the same > session-id). So the latest draft says matching is done with both the > session-id and the remote-tag. That also solves a security issue, > fwiw. But it means if any middleboxes along the path muck with the > remote-tag, they could prevent the matching from succeeding, and we're > back at square one. The only solution to that I see would be to have > surrogates for tags too, but I don't want to go that far down the > rabbit hole and the draft does not. If the WG takes this as a WG > item, then it's all open to consensus of course.
So... given that we already have a call-id that _should_ already have all the matching properties you want if B2BUAs would just leave it alone (changing tags as a message passes through a B2BUA should provide the required dialog uniqueness while leaving the call-id to recognize the relationships), what is wrong with just creating a new set of rules for how to construct a call-id so that it has the other properties you suggest? You could even add a magic cookie to the beginning as was done with Via branch ids to declare that the call-id is a session-id that should be preserved. Then it's easy to detect who supports it and understands the semantics. I don't think that reformulating call-id is any harder to deploy than a new header would be. _______________________________________________ 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
