> -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2008 6:40 AM > > I don't think that having the first B2BUA synthesize the session-id > would work. The idea is to have it end-to-end to solve the problem so > having it put in by a B2BUA would not solve the problems.
Can you describe why having a B2BUA generate a Session-ID, if and only if one was not in the message already, would be worse than not generating one at all? > While this draft proposes B2BUA > actions the defined actions will only occur if the B2BUA fully > implements this draft. The draft doesn't say what a B2BUA should do if no header exists. It does not say the B2BUA can not generate one in such a case. I consciously left that as a possibility, knowing it would be a while before UAC's would generate one. > The bigger issue is what is to stop a B2BUA either removing the > session-id or generating one of its own. > RFC 3261 defines a B2BUA as a concatenation of a UAS and a UAC. What > happens between the UAS and UAC parts is undefined and there is no > specification as to what actions the B2BUA should take when passing a > request from the UAS to the UAC. There was a draft presented to the > sipping wg to try an define actions of B2BUAs but this was rejected by a > hum as dangerous. I guess that the consensus was that the B2BUA should > remain totally undefined so that it could perform any action that was > required. [Declaration of interest: I was a contributor to this now > expired draft.] I'll tackle those in a separate email. > A couple of additional items which may need to be considered in the > draft. > Is it possible to include a list of headers which currently use the > existing dialog identifiers? Others which you have not mentioned include > Target-dialog, Join and In-reply-to. Funny you mention it - I was tempted to go do it in the draft, but I thought it wasn't really the place to do it because the list could change, and there're a bunch of proprietary ones too, and the goal of the draft isn't to change them. So I figured it was better to just give a couple examples. But I can certainly do it if you think it would be useful. > Is it proposed to propose modifications to the RFCs for the existing > headers which use dialog ids to use the session-id? Nope. If someone wants to propose that in the future that's up to them, but I'm not suggesting that for this draft. I *do* think some of the XML packages that include them should consider the Session-ID as an alternative (not a replacement - just an alternative). But only for the ones in draft status or proprietary ones, not published RFCs. > It is probably necessary to specify B2BUA actions in cases of 3PCC and > what happens to the session-id in these cases. Would it be any different? Thanks for reviewing! -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
