Yeah JDR mentioned the same thing. Unfortunately that header value is created by middleboxes and removed by middleboxes. -hadriel
________________________________ From: Venkatesh [mailto:[email protected]] Sent: Wednesday, March 25, 2009 5:41 PM To: Dale Worley Cc: Hadriel Kaplan; IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 A crazy thought occurred to me while I was reading this draft. If the intent is for debugging and such, I am wondering if there is any value in considering the re-use of the P-Charging-Vector header for this purpose? After all, this is supposed to be unique, required to be carried across Proxies, B2BUA's if one is present, reflected in CDR's if one is generated by an entity?? Agree that this header had specific intents and cannot span across "trust" boundaries, but I am not sure if a SP cares when the request 'leaves' their trust boundary? It seems to satisfy the requirement for debugging? Flame away :-). Venkatesh On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley <[email protected]<mailto:[email protected]>> wrote: On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: > > If I may be immodest, the References header could a solution: State > > that two dialogs are related to each other by (effectively) naming both > > call-id's together, rather than by assigning them a common identifier > > when they are created. > > Yeah I think it adds value to have the References header. I just > don't think it should be referencing Call-ID's, or else we'll have to > replace that too. It should be referencing Session-ID's or > secure-call-id's. :) Certainly in security-sensitive situations, referencing Call-IDs, or at least, ones created by UAs, would be undesirable. But down in section 5.2 it describes how to have the B2BUA generate "linking" identifiers: A possible solution to this problem is for the B2BUA to create a "phantom" Call-Id that is suitably random, and use it in References headers sent in both the initial request and response. By the transitivity property[Section 2], the dialogs on both sides of the B2BUA are declared to be related, even if the referenced dialog contains no messages. For two chained B2BUAs with no forking, this would give a message flow like this: UA 1 B2BUA 1 B2BUA 2 UA 2 ---> INVITE [email protected]<mailto:[email protected]> Call-Id: qwe...@aa ---> INVITE [email protected]<mailto:[email protected]> Call-Id: asd...@transit References: QAZWSXEDCRFV;rel=serial ---> INVITE [email protected]<mailto:[email protected]> Call-Id: zxc...@bb References: QAZWSXEDCRFV ;rel=serial <--- SIP/2.0 200 OK Call-Id: zxc...@bb <--- SIP/2.0 200 OK Call-Id: asd...@transit References: QAZWSXEDCRFV;rel=serial <--- SIP/2.0 200 OK Call-Id: qwe...@aa References: QAZWSXEDCRFV;rel=serial 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]<mailto:[email protected]> for questions on current sip Use [email protected]<mailto:[email protected]> for new developments on the application of sip
_______________________________________________ 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
