Hi Ian, Thanks for your comments. I should publish the update to this draft, because it now covers the middlebox-insertion-case in text, whereas before it was implicit. And it adds text for UAC generation that was incomplete, because I forgot to put a critical aspect to this in the original draft about matching.
The basic concept is that if we want it to be usable as an alternative dialog-matching mechanism for out-of-dialog requests, then whomever generates a session-id has to have a local session-id lookup table, as does any device needing to perform matching. That table would simply be a session-id value to dialog table, used for matching the value to a dialog. If a device doesn't do this, then we get the troubleshooting properties but not the dialog-matching one, if a request gets to that specific node and the real dialog+tags don't match. But it's true this would mean a Proxy that generates it *and* wanting to provide the matching property would need to be record-routing and have such a table, making it more stateful. With regard to the issue not being as complex for B2BUA's because UA-B would send it to the B2BUA's contact: Just being a B2BUA doesn't solve the problem without the match table being done somewhere. The problem with dialog-event and such in out-of-dialog requests is not that B2BUA's can't "fix" it and set the contact to themselves to make sure they get the request - they do that already. The problem is some of the requests aren't sent to their contact-URI to begin with. For example, in the Derive case it's sending it to the From-URI, which B2BUA's sometimes do also change (ugh), but normally/hopefully to their domain not their hostname/IP; or better yet they leave it alone. [I think that Derive is actually incorrect in sending it to the From-URI AoR, because it means the Derive message can end up at any contact for the AoR] But the bigger issue is even if such things get sent to Contact-URIs and the Contact-URI's are GRUU's, in theory the GRUU does not specify a specific B2BUA instance, but instead the whole domain and thus can hit any number of B2BUA's getting into that domain. We have been asked by some people in the IETF to leave contact GRUU's alone, and not replace them with the B2BUA's contact. We'd be happy to do that if we can make requests going to the GRUU work, which without this type of matching mechanism they won't. Ultimately the matching and troubleshooting properties work best if UA's generate the session-id themselves, and I hope it's simple enough that they do - but in the meantime B2BUA's or stateful proxies can do it for them to get it off the ground. It won't solve all scenarios, but that's ok - it's making it better than nothing. -hadriel > -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 27, 2008 11:31 AM > To: Dan Wing; James M. Polk; Hadriel Kaplan > Cc: SIP List > Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > Dan, Hadriel, > > I don't think that having a proxy insert the session-id would be > workable. > > Take the following example. > > UA-A does not support the session-id so it is not included in the > original request. > > UA-A Proxy1 Proxy2 Proxy3 UA-B > | | | | | > | INV B (F1) | | | | > |----------->| INVITE B (F2) | | > | |------------>+----------->+------------>| > | | | | | > | | 200 OK (F3) | | > | 200 OK |<------------+<-----------+<------------| > |<-----------| | | | > > F1 INVITE [EMAIL PROTECTED] > Call-id: 123456789 > From: <[EMAIL PROTECTED]>;tag=98765 > To: <[EMAIL PROTECTED]> > Contact: <[EMAIL PROTECTED]> > > F2 INVITE [EMAIL PROTECTED] > Call-id: 123456789 > From: <[EMAIL PROTECTED]>;tag=98765 > To: <[EMAIL PROTECTED]> > Contact: <[EMAIL PROTECTED]> > Session-id: abcd1234 > > F3 200 OK > Call-id: 123456789 > From: <[EMAIL PROTECTED]>;tag=98765 > To: <[EMAIL PROTECTED]>;tag=56789 > Contact: <[EMAIL PROTECTED]> > > > Note that as UA-A here does not support the session-id that this has > been inserted by Proxy1. > > What happens however if UA-B now tries to SUBSCRIBE to UA-A using the > dialog event. > > Assuming the dialog event has been modified to allow the session-id. > > UA-A Proxy1 Proxy2 Proxy3 UA-B > | | | | | > | | SUBSCRIBE (F4) | | > | |<------------+<-----------+<------------| > | | | | | > > The problem here is how the SUBSCRIBE containing the dialog event > containing a session-id ensures that the new Request on a new dialog is > handled by Proxy1 to map the session-id to the call-id, to-tag, from-tag > format of the dialog event as handled by UA-A. > > [If I may be flippant?]. It looks like there is a requirement for a new > header: "Pass-to-this-proxy-at-some-time" to ensure that the correct > proxy is included in the messaging sequence. > > You could possibly use a ROUTE header but as UA-B does not know which if > any of the proxies inserted the session-id it would be necessary to > insert all the proxies which inserted themselves in the Record-Route of > F2 as Route headers in F4. This could however result in a lot of proxies > which would not normally want to see the SUBSCRIBE being involved in the > message sequence. > > The issue is not as complex for a B2BUA as UA-B could use the Contact > received in F2 as the R-URI in the SUBSCRIBE (F4) which if the B2BUA > mapped the Contact would ensure that the B2BUA which inserted the > session-id would receive the new request. > > Ian Elz > _______________________________________________ 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
