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]> 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] > Call-Id: qwe...@aa > > ---> > INVITE [email protected] > Call-Id: asd...@transit > References: QAZWSXEDCRFV;rel=serial > > ---> > INVITE [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] for questions on current sip > Use [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
