> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ian Elz > Sent: Wednesday, November 19, 2008 5:40 AM > To: Dan Wing; Hadriel Kaplan > Cc: SIP List > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > Dan, Hadriel, > > 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.
Yes. But until UAs generate the header, the best you can do is have the first B2BUA insert the header for the benefit of the rest of the SIP network. This is akin to the 'authentication proxy' described in RFC4474, where the proxy inserts the authentication headers if the UA hasn't done so. > The bigger issue is what is to stop a B2BUA either removing the > session-id or generating one of its own. Nothing stops the B2BUA from doing anything it wants. > While this draft proposes B2BUA > actions the defined actions will only occur if the B2BUA fully > implements this draft. That is correct. Is the draft complex to implement? > 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.] Hadriel's draft attempts to do the opposite: instead of defining "these are the things a B2BUA is allowed to do", it is saying "a B2BUA, compliant with this specification, will pass the session-id header". -d > Hadriel, > > 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. > > Is it proposed to propose modifications to the RFCs for the existing > headers which use dialog ids to use the session-id? > > It is probably necessary to specify B2BUA actions in cases of 3PCC and > what happens to the session-id in these cases. > > > Ian Elz > > System Manager > DUCI LDC UK > (Lucid Duck) > > Office: + 44 24 764 35256 > gsm: +44 7801723668 > [EMAIL PROTECTED] > > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: 19 November 2008 06:24 > To: 'Laura Liess'; 'Hadriel Kaplan'; 'SIP List' > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > > The problem which I have with this particular solution > > is that it requires changes in existing user devices. > > For UAs that don't generate session-id the first B2BUA > could synthesize a session-id. > > -d > > > _______________________________________________ > 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 _______________________________________________ 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
