Dan, Hadriel, I don't think that having a proxy insert the session-id would be workable.
Take the following example. UA-A does not support the session-id so it is not included in the original request. UA-A Proxy1 Proxy2 Proxy3 UA-B | | | | | | INV B (F1) | | | | |----------->| INVITE B (F2) | | | |------------>+----------->+------------>| | | | | | | | 200 OK (F3) | | | 200 OK |<------------+<-----------+<------------| |<-----------| | | | F1 INVITE [EMAIL PROTECTED] Call-id: 123456789 From: <[EMAIL PROTECTED]>;tag=98765 To: <[EMAIL PROTECTED]> Contact: <[EMAIL PROTECTED]> F2 INVITE [EMAIL PROTECTED] Call-id: 123456789 From: <[EMAIL PROTECTED]>;tag=98765 To: <[EMAIL PROTECTED]> Contact: <[EMAIL PROTECTED]> Session-id: abcd1234 F3 200 OK Call-id: 123456789 From: <[EMAIL PROTECTED]>;tag=98765 To: <[EMAIL PROTECTED]>;tag=56789 Contact: <[EMAIL PROTECTED]> Note that as UA-A here does not support the session-id that this has been inserted by Proxy1. What happens however if UA-B now tries to SUBSCRIBE to UA-A using the dialog event. Assuming the dialog event has been modified to allow the session-id. UA-A Proxy1 Proxy2 Proxy3 UA-B | | | | | | | SUBSCRIBE (F4) | | | |<------------+<-----------+<------------| | | | | | The problem here is how the SUBSCRIBE containing the dialog event containing a session-id ensures that the new Request on a new dialog is handled by Proxy1 to map the session-id to the call-id, to-tag, from-tag format of the dialog event as handled by UA-A. [If I may be flippant?]. It looks like there is a requirement for a new header: "Pass-to-this-proxy-at-some-time" to ensure that the correct proxy is included in the messaging sequence. You could possibly use a ROUTE header but as UA-B does not know which if any of the proxies inserted the session-id it would be necessary to insert all the proxies which inserted themselves in the Record-Route of F2 as Route headers in F4. This could however result in a lot of proxies which would not normally want to see the SUBSCRIBE being involved in the message sequence. The issue is not as complex for a B2BUA as UA-B could use the Contact received in F2 as the R-URI in the SUBSCRIBE (F4) which if the B2BUA mapped the Contact would ensure that the B2BUA which inserted the session-id would receive the new request. 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 19:52 To: 'James M. Polk'; Ian Elz; 'Hadriel Kaplan' Cc: 'SIP List' Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > -----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
