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. -hadriel > -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2008 12:14 PM > To: Hadriel Kaplan > Cc: SIP List > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > I want to make sure we're not going to re-hash all the call-id/to-tag > mess some of use have had to live through already. Exactly what > properties do you need this identity to have? For example, with your > current draft, if the call forks to two automata that answer > immediately, you'll end up with two valid sessions with the same > "Session-ID." Is that what we want? If so, the term "Session-ID" is > something of a misnomer. Perhaps "Session-Group-ID"? > _______________________________________________ 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
