> -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Friday, December 05, 2008 11:33 AM > > 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.
Yup. > There may be a number of proxies and/or B2BUAs on > either side of the proxy which inserted the session-id. Nope. The draft is pretty clear that a Proxy or B2BUA would only insert/generate it if and only if it did not already exist. > 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. They have no requirement to do so - but that does not prevent them from doing so. > 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. No, the header is not trying to overcome being "unproductive". I don't dispute that it would be an unnecessary action to perform in some cases. But again, note that it is not mandatory. Matching does not introduce interop issues, and does not make it fail when it would have otherwise succeeded. It's something a node can do if it wishes to. > 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. Can you describe how you think that would be possible for a Session-ID mechanism to do? Because I don't see a way for that to be possible, given the constraints. > 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. The requirements are in the draft, as are the problems. If you don't agree with them that's cool. If you think they should be expanded or narrowed let me know. I think you feel that the matching property is not a requirement, or that the solution to it in this doc is not to your liking. (Right?) But you have not had any complaints with the troubleshooting property, AFAIK. I see no need to go through bureaucratic procedural hoops which slow down the process of invention, when what they amount to is changing the email mailing list we use but are otherwise the same group of individuals. [no offense to the SIPPING WG, but I think that viewpoint was generally shared by attendees at the last IETF meeting's RAI meeting] -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
