-----Original Message----- From: Dan Wing [mailto:[EMAIL PROTECTED] Sent: 19 November 2008 14:33 To: Ian Elz; 'Hadriel Kaplan' Cc: 'SIP List' Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> -----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. [Ian Elz ] But there is no point having the B2BUA insert the header as this doesn't solve the main problem, routing to the B2BUA where the mapping occurred. Example: The UA which does not support the session-id will generates a new request containing a Target-dialog with the existing dialog identifiers. The problem of routing the new Request to the B2BUA which inserted the session-id in the original request remains. If the original request was forked then a Target-dialog using a dialog id would refer to one forked dialog whilst the session-id would potentially refer to all the forked dialogs. Unfortunately this is not as simple as inserting authentication headers as authentication headers are only used by the one party to validate the identity of the other party for the specific request. In this case the session-id will be used in separate requests which reference other requests. You need to ensure that you can route to the B2BUA which inserted the session-id to map between the session-id and the dialog identifiers. This is the problem that exists without the session-id and this still needs to be solved. > 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. [Ian Elz ] Agreed > 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? [Ian Elz ] The part relating to passing a session-id transparently from one side to the other does not appear difficult. The logic to map from dialog-ids to session-id as discussed above is another matter. > 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". [Ian Elz ] The previous draft was an attempt to define what things a B2BUA should do to be as proxy like in the network. There were also proposals as to how Requests containing the headers which reference other dialogs are routed in the network. The attempt was to define what things a B2BUA must do and which it should not. I still believe that this needs to be defined. -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
