> -----Original Message----- > From: James M. Polk [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2008 1:39 PM > To: Dan Wing; 'Ian Elz'; 'Hadriel Kaplan' > Cc: 'SIP List' > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > At 08:33 AM 11/19/2008, Dan Wing wrote: > > > > > > > -----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. > > from that pov, why not have the first SIP server insert the header > (whether or not it's a B2BUA)?
Absolutely. -d > >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 > _______________________________________________ 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
