> -----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 ] 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. 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. 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. -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
