Hadriel, If a proxy inserts a session-id then there will be two sides to the initial request, the UAC side without the session-id and the UAS side with a session-id. There may be a number of proxies and/or B2BUAs on either side of the proxy which inserted the session-id.
When a later request comes from the UAS side which uses the inserted session-id to reference another dialog which node is going to perform the matching and modify the referencing header from using the session-id to using the call-id and tags. The nodes on the UAS side of the inserting proxy will have received a session-id and will have passed it on. These nodes have no knowledge that the session-id was inserted in the middle of the message sequence and hence have no requirement to perform the matching. The nodes on the UAC side of the original dialog will not recognize the session-id as it was not in the message and cannot perform the matching. The only node which 'knows' that the session-id was inserted was the node which inserted it. If the session-id was in the original request from the originating UAC then no matching should occur. To perform matching in this case would be unproductive as it would introduce the problem which the header is trying to overcome. I think that if you are going to allow inserting then you will need a mechanism that will ensure that the new message will be passed to the node that can perform the matching, this is the node which inserted it. If all the things, insertion, matching etc are MAY in the draft I am beginning to wonder what the purpose of the header is. Perhaps the draft and consideration of the session-id header should be passed to the sipping wg to consider the requirements and what problems it is trying to solve. 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: 05 December 2008 15:52 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: Friday, December 05, 2008 5:30 AM > > >-----Original Message----- > >From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > >Sent: 03 December 2008 20:23 > > > >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. Nope, that's just one example. You said there was no way to make a Proxy be in the path for out-of-dialog requests, and I said sure there is. You could also have a one-and-only Proxy for accepting requests from outside your domain, which could do the matching. Or the Proxy could be the Registrar for your domain, which is always traversed to reach registered UAs. Again, though - this is not about who can generate a Session-ID. It's about who can do the matching. Every hop can try to do matching for all I care. It won't affect interoperability or add failure cases where previously there were success cases. It's only at a MAY level - you don't have to do it if you don't want to. > [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. Nope, it doesn't require that at all. See the draft - it's at a MAY to do matching. I think you may be reading something into the draft that it doesn't say: that only a Session-ID *generator* can do matching? The draft doesn't say that, nor did I intend it if it does. :) Should I put words in the draft making that clearer? -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
