Hadriel, Comments in-line.
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: 03 December 2008 20:23 >To: Ian Elz >Cc: SIP List >Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > > >> -----Original Message----- >> From: Ian Elz [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, December 03, 2008 5:48 AM >> >> >> [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. > >Actually, there *is* a way of making a Proxy in the path, depending on >where the Proxy is. If it's the edge proxy between the UAC and its >registrar, have it insert itself in the Path header for the Register, and >any/all requests trying to get to that UA using GRUU/AoR should in theory >go through that Proxy. [Ian Elz ] Thus it is only a proxy which is includes itself in the Path header during registration which is allowed to insert a session-id. Does a proxy in the Path header remember that it is part of the Path for the subscriber? > >> [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. > >Yes but it would have failed *anyway*. That's the point - Session-ID is >not making it worse. It's just offering a way to make it better, in >certain scenarios. BTW, for networks like 3GPP the set of scenarios it >could cover is rather large, because basically we're talking about the P- >CSCF doing this thing, and probably I-BCF's. [Ian Elz ] But having a proxy insert a session-id is not fixing anything. I am not arguing against the session-id at this point just allowing proxies to invent one and add then in the middle of a request. Allowing the proxy to add a session-id requires that the proxy must be included in the message sequence for the new request using the session-id as a reference and it must also remember that it inserted the session-id and map the session-id <--> call-id & tags from one side to the other when they are used as a reference. > >And besides, the matching behavior for Session-ID is basically gravy - the >meat is getting a common identifier across B2BUA's, for troubleshooting and >whatever other needs we find for such an identifier. [Ian Elz ] If the session-id is only to be used for troubleshooting then having a proxy insert the header is not an issue. If it is to be used in place of the call-id and tags for use in the existing headers (Replaces, Join, Target-dialog,...) of in Events (dialog etc) then there is an issue. I think that we need to define and limit the usage of this header. > >If there's consensus that the matching mechanism is too scary/radical to >consider, that can be pulled out into a separate draft which uses the >Session-ID header value defined in this draft. [Ian Elz ] I am looking at this as a possible solution to the issue of the mapping of the call-id and tags across B2BUAs and how the headers and events listed above can be handled across B2BUAs. The current situation where the B2BUA maps the call-id and or tags requires that the referencing request is passed along the existing B2BUA chain to allow the mapping of the previous dialog identifying parameters in the referencing header. This requires that the B2BUA map the Contact if it maps any of call-id, from-tag or to-tag and that the new request uses the Contact from the previous dialog as the R-URI in the referencing dialog. In some network implementations there may be service requirements to pass the referencing request along the B2BUA chain but that is for those implementations to determine whether the session-id provides a suitable solution. > >-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
