Yes, you are right, probably implementations will only go the easy way. Although something like a shared key between CC agent and CC monitor would it not make too easy for them.
But what I wonder is do we need anyway to specify the identifier in deep? This could also be a policy between agent and monitor? The CC draft could give some guidelines? What we need of course is a mechanism to transport the identifier. BR, Martin > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 10. April 2008 16:11 > An: Hülsemann, Martin > Cc: [EMAIL PROTECTED]; [email protected]; Alexeitsev, Denis > Betreff: Re: AW: [BLISS] Technical problem -- correlating dialogs > > > > Huelsemann, Martin wrote: > > Can't this be done by 2 different ways? First the normal > way with delivering something like a CC identifier back to > the CC agent which then ist used druring the subscription and > the CC call. The other way would be the fallback for > stateless UAs (and gateways) to reassemble the identifier > from information available from the original call (first > choice information about caller and callee). During design > team discussion Dale also introduced a keying mechasim > guarateeing privacy settings. > > > > Anyway with this approach the identification would actually > only be needed for the subscription and the CC call. > > IIUC, the identification is mostly just for authorization, to prevent > fraud - getting preferential treatment. > > If you have two ways, and one of them provides an opportunity > for fraud, > and the other not, then those intent of fraud will use the one that > supports it. There is then little motivation to implement the other > method, since it will only be used by those who would do the > right thing > with the weaker mechanism. > > What am I missing? > > Paul > > > BR, Martin > > > > > > > > > > > > > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Im Auftrag von Paul Kyzivat > >> Gesendet: Mittwoch, 9. April 2008 23:35 > >> An: [EMAIL PROTECTED] > >> Cc: [email protected] > >> Betreff: Re: [BLISS] Technical problem -- correlating dialogs > >> > >> Suppose you just authorized subscribers based on a > From-URI matching > >> that of a recent call attempt? As you note, it would be easy > >> for others > >> to guess this, but what bad things happen as a result? > >> > >> To take advantage of this I must forge your From address > >> (perhaps easy), > >> but I must also know that you have made a call attempt that failed. > >> > >> How is that better than just making my own call attempt in > the first > >> place, using either my own From, or yours if I am capable of > >> forging it? > >> > >> I guess it means I can jump ahead of you in line, but only > if I was > >> monitoring your usage to start with. > >> > >> I suppose there are *some* cases where that would be > >> valuable, but are > >> they important cases? > >> > >> Another thing you might use is the Contact address, which > might be a > >> little harder to guess, but not a lot harder normally. And it > >> might be > >> bad if you want to make the CC from a different extension. > >> > >> Paul > >> > >> [EMAIL PROTECTED] wrote: > >>> This is a problem that we've been discussing on the Call > Completion > >>> mailing list and we would like to put it in front of the > >> entire Bliss > >>> mailing list for people to suggest solutions. > >>> > >>> The problem runs: > >>> > >>> (To simplify,) once an initial caller has made a call to > a UAS that > >>> has failed, the caller sends a SUBSCRIBE ("the CC subscribe") to a > >>> particular UAS to state its desire to make a CC call, and > to receive > >>> notice of when it should make its CC re-call. (Currently, the > >>> expectation is that the CC subscribe will be made to the > same URI as > >>> the original call. It might be possible to change that, but that > >>> turns out to involve the same technical problem described below.) > >>> > >>> Because a CC subscribe displays busy/not-busy information > about the > >>> callee without itself making an INVITE to the callee, in order to > >>> protect privacy, we don't want to allow UAs to arbitrarily > >> perform CC > >>> subscribes -- they have to present identification of a > previous call > >>> that they have made to that destination, thus ensuring that > >> the callee > >>> is aware of the caller's interest. > >>> > >>> Some UAC callees are nearly memory-less. (In particular, > >> constellations > >>> of gateways that bridge from SS7 networks to SIP networks.) > >> Thus, the > >>> only information that can be carried reliably from the > >> destination of > >>> the (failed) original call to the CC subscription and the > >> CC recall is > >>> the "mode" (CCBS vs. CCNR), because that is carried back > >> into the SS7 > >>> network and is carried forward in the SS7 CC operations. > >>> > >>> This means that the "identification" that we require of the CC > >>> subscribe must be some aspect of the original call; it cannot be a > >>> datum from the response to the original call (because a > >> memoryless UAC > >>> cannot remember the datum). > >>> > >>> This means that any call to which CC can be applied later > must bear > >>> some sort of identification which will later be carried in the CC > >>> subscribe and CC recall. This would be straightforward > -- just use > >>> the Call-Id -- except that calls frequently pass through SBCs or > >>> B2BUAs that change the Call-Id. > >>> > >>> Let us examine what might be used for identification: > >>> > >>> There are two sorts of data that an INVITE carries. The > >> first sort is > >>> data about the nature of the call (To, From, etc.). Because it is > >>> relatively easy to guess, this data is not suitable for CC > >>> identification. The second sort is pseudo-random data used to > >>> identify the call (Call-Id, to-tag, from-tag). By its > very nature, > >>> SBCs feel free to change the second sort of data when > passing a call > >>> through, so the UAC and UAS do not necessarily see the same > >> values of > >>> these data. > >>> > >>> One alternative is to add a new header with a pseudo-random > >> value, and > >>> expect that SBCs will not change it. (And hope that SBCs > >> will pass it > >>> through, which is plausible.) But in order to reduce the > burden on > >>> the UASs and the network, we don't want to add an additional CC > >>> identifier to every call that is generated, but it appears that we > >>> have to to get calls reliably identified for CC. > >>> > >>> Dale > >>> _______________________________________________ > >>> BLISS mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/bliss > >>> > >> _______________________________________________ > >> BLISS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/bliss > >> > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
