The idea (and it may well be a half-baked idea) was to add the Session-ID value into the dialog-event package body (the dialog-info XML doc schema in urn:ietf:params:xml:ns:dialog-info namespace) as another XML element. In other words, to add a "session-id" element wherever a "call-id" element can also be, such that a consumer of that received XML doc, if it understands that element, could try to match its value to one of its known session-id values for its known dialogs, if and only if the "call-id" one failed to match a call-id. Likewise for other package XML docs that have "call-id".
For the Replaces/Target-Dialog/etc. SIP headers, one idea would be to add another param similar to the call-id param, for session-id. But that's just one option. Option 2 was to in fact keep the Session-ID header itself the same for that out-of-dialog INVITE created by a Refer-To, by embedding the Session-ID header in Refer-To. There's pro's/con's to either approach, and I don't have an opinion on which is right/wrong/better/worse. -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dale > Worley > Sent: Wednesday, December 03, 2008 12:40 PM > > From: Hadriel Kaplan <[EMAIL PROTECTED]> > Note the "adversary" so to speak is just that a downstream node > can get a Call-ID and must not be able to tell from the Call-ID > it got, what the Session-ID should be, so they can't tell the > Call-ID was changed by a b2bua. Of course an upstream node > would be able to tell - for example the UAC would if it received > a subscribe for the dialog-event that had a session-id it > created, with a call-id+tags it didn't. But then one of the > main points of this exercise is to make those cases work. I > can't guarantee that all operators would want it to work in such > cases, but for those that don't want it to, nothing will help us > make it work. > > There's something I don't understand here. You mention "received a > SUBSCRIBE for the dialog-event that had a session-id it created, etc." > What does that mean? I assume you mean that the UAS of the original > call (or something in its near network vicinity) wanted to subscribe to > the dialog events of the UAC, filtering for the one dialog it knows of. > That would be: > > SUBSCRIBE [contact taken from INVITE seen at UAS] SIP/2.0 > Call-Id: [something new] > Session-Id: [something new] > Event: dialog;session-id=[session-id of INVITE] > > That would go back through the B2BUA (or one of its brethren) because > the Contact as seen at the UAS was munged as necessary by the B2BUA to > ensure that that would happen. The B2BUA would change the Call-ID, but > it would leave the Session-Id and the Event session-id parameter > unchanged. > > But there would be nothing to compare the Event session-id parameter > *to*. And the Session-Id would have no apparent relationship to the > Call-Id or tags of the SUBSCRIBE as seen at the original UAC (the UAS of > the SUBSCRIBE). > > Dale > _______________________________________________ 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
