> -----Original Message----- > From: Dale Worley [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 07, 2008 11:18 AM > > I'm losing track of what problem you're attempting to solve. I thought > the problem was to identify the dialog-sets that are created by "B2BUA > pass-through". But now it seems that the mechanism only identifies some > of these dialog-sets and doesn't identify others, because any > short-circuiting of INVITE/Replaces (and possibly other call-control > operations) defeats the mechanism. There's also a problem with using > Session-Id to identify dialogs, as to-tag mangling is not compensated > for. > It seems that the only case that is well-handled is the simplest > PSTN-like call: A UAC sends an INVITE that does not fork through a > B2BUA to a UAS.
On the contrary - it handles forks just fine. The cases it doesn't "handle" are of two types: (1) not all parties which need to support Session-ID in a given scenario do in fact support it, and (2) when a new dialog is created such that it would have used a new Call-ID even if everything was a proxy and there were only a UAC and UAS. I would argue case (1) is true for any mechanism we define. I have yet to see a proposal that does not require more than one party supporting the new mechanism for it to work in all scenarios. And I'm arguing THAT'S OK. It's perfectly reasonable that whatever mechanism gets used only works if the parties that need to support it do. What's important, for me at least, is that when the mechanism doesn't work it doesn't make things worse - i.e., it doesn't cause a failure when previously just Call-ID+tags would have succeeded. I say that because, at least for me, the idea that we can get all devices to upgrade to whatever mechanism we pick on a flag-day is laughable. It ain't gonna happen. So we have to play the cards we're dealt. For case (2), the gist of it is that Session-ID is essentially a new surrogate for Call-ID. So if a UAC creates an out-of-dialog request, it would create a new Session-ID, just as it would create a new Call-ID. When a B2BUA acts on behalf of a UA, such that it creates an out-of-dialog request which that UA would have itself created had the B2BUA not intercepted a message bound for that UA, then the Session-ID it creates would be a new one - again, because the Call-ID itself would have been a new one had the B2BUA not been involved. For example, if the UAS sends an in-dialog REFER to the B2BUA, and the B2BUA "short-circuits" it and processes it on behalf of the UAC, and creates a brand new INVITE to the referred-to party, then it gets a new Session-ID, because if it had let that REFER go back to the UAC that's exactly what the UAC would have done. I'm perfectly fine with that. The original "session" is over, and a new one has been created. That B2BUA is acting as more th an a "dialog-proxy" at that instant. But if you and others feel that it in fact needs to remain the same contiguous "session" even in that case, I'll change it. I think it adds complexity, and more devices would have to support the mechanism than otherwise, but that's ok. Though I still don't think we'd need to support a conference scenario (a scenario where multiple UAC's connect to a conference bridge). -hadriel _______________________________________________ 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
