Hadriel, Comments in-line. I have removed the bottom part of the discussion.
Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 [EMAIL PROTECTED] -----Original Message----- From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] Sent: 02 December 2008 21:36 To: Ian Elz Cc: SIP List Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt Hi Ian, comments inline... > -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 02, 2008 6:22 AM > > My main comment on your draft at present is the proposal to allow a > proxy to insert the session-id header if it has not been inserted by the > UA. I think that this introduces additional problems of how to ensure > that the proxy in included in the message path of a new request that > uses the session-id that it inserted as a reference to the original > dialog. You mean that a "Proxy" in particular could do this, right? (not that a B2BUA could do this?) [Ian Elz ] I think that a B2BUA could insert the session-id and that getting back to the B2BUA would have to use the same mechanism as using the existing call-id/tags dialog referencing for getting the new Request back to the B2BUA where it could perform the Session-id to call-id/tags mapping. For a proxy this is more difficult as ensuring that a proxy appears in the path of the new request does not appear to have a solution. The problem with a proxy inserting session-id is that the UA which receives the request containing the inserted session-id may attempt to create a new request using the session-id to reference the previous session/dialog but with no way of definitively routing back via the proxy which included the session-id the new request is bound to fail. I think that it is better in this case to not include the session-id and let the existing mechanisms be used. As session-id usage spreads then the use of session-id will become more common. Right now the draft is written to make the matching mechanics basically optional for a node. The Session-ID header has uses beyond dialog matching ones, and I prefer to keep the bar low for implementations to at least pass it through, or even generate it. You're right that a Proxy implementing the matching function would need to keep itself in the path - good catch - I will add it if we decide Proxies should be able to do the matching function. (and yes, it could only keep itself in the path in certain scenarios, so we may just not want to let Proxies do a matching function period to make the draft easier to comprehend) [Ian Elz ] As stated above if the proxy does not support 'matching' then there is a problem when one UA supports session-id and the other doesn't. Any attempt to reference a session/dialog using session-id will fail. [Ian Elz ] <rest of thread text removed> -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
