> -----Original Message----- > From: Dale Worley [mailto:dwor...@nortel.com] > Sent: Tuesday, March 24, 2009 11:59 PM > > I'm not sure how much benefit comes from this idea. > On the one hand, it contains no mandate of the form "If the call-id is > of format xxxxx, then SBCs WILL NOT change it."
Huh, you're right. I should add in a MUST NOT change it for security purposes. Although realistically Call-ID's are changed by many B2BUA's other than SBC's for reasons other than security. This draft is only trying to remove the incentive for changing them for security reasons. There is no way to stop other B2BUA's from changing them for other reasons. (which is why I have the session-id draft) > So there's SBC behavior > in particular that an outside agent can depend on, even if it knows that > all UAs in the system follow the I-D. My guess is that SBCs will munge > the call-ids anyway, rather than trying to implement an algorithm to > determine compliance -- on a UAC-by-UAC basis! Sure, SBC's may not follow this draft. So? UA's and other devices may not follow any given draft/RFC. But right now there's actually a reasonably defendable rationale for why the Call-ID's should be changed. I'm trying to get rid of that rationale. The owners of the SBC's will then be able to tell their vendors "go do this draft", if they find they need SIP extensions to work which rely on the Call-ID not changing. The market will sort out if that's valuable or not. > The other side of this is that it makes life harder for anyone trying to > diagnose problems. In sipX, we currently generate pseudo-random > call-ids. Actually, the format is "s-XXXXXXXXXXX-NNN", where XXXXXXXX > is pseudo-random and NNN is a sequence number. That way you can > mentally say "dialog 7" and "dialog 45", but still get uniqueness. But > we've got a work item to append the host DNS name to the format so that > we can easily distinguish "dialog 45 from sipx1.example.com" and "dialog > 45 from sipx2.example.com". If you do that, SBC's will continue to change the Call-ID from your devices. There's always a trade-off between revealing enough information to troubleshoot/diagnose, and revealing information that can lead to abuse. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
