Thought per the 3GPP spec, this header got added at the first ingress point into the network and removed at the last egress point from the network? So, essentially you can trace the call using this header within your network? Venkatesh
On Wed, Mar 25, 2009 at 3:32 PM, DRAGE, Keith (Keith) < [email protected]> wrote: > This only works if essentially your insertion and deletion requirements > of the header are the same as those required by your accounting system. > > Keith > > ------------------------------ > *From:* [email protected] [mailto:[email protected]] *On Behalf Of * > Venkatesh > *Sent:* Wednesday, March 25, 2009 9:41 PM > *To:* Dale Worley > *Cc:* 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]> 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
