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
