[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] draft-garcia-mmusic-sdp-cs-02: thoughts on correlation
Miguel-
My comments below.
-Bob
Miguel A. Garcia wrote:
Hi Bob:
I guess this is exactly what Adam was proposing. At least, I haven't
seen a difference with original Adam's proposal.
[rrg]: As I read Adam's email, he was suggesting DTMF as a backup
mechanism in case that CID and/or UUI didn't work. It seemed
better to me to use the scheme at the start so an additional
signalling exchange (with it's associated delay) isn't needed.
I still have the same concerns:
1) The session setup time is increased. Ok, it might be only a couple of
seconds, but still it is.
[rrg]: This seems like a small price to pay to get it right (I'd guess
that typical systems would use only 3 or 4 digits.) We still
have the circuit-switched call propagation delay contribution
in either case.
2) Who is going to implement this mechanism?
[rrg]: Anyone who can't count on the nature of the PSTN and who wants to
make sure the right call gets associated with the right circuit.
3) If we add the cryptographic exchange, who is going to implement this
mechanism?
[rrg]: Who knows? I wasn't suggesting that we add the case; I was just
pointing out that it's possible to generate the identifying
digits cryptographically to reduce the probability that an
intruder can capture the destination circuit. I'd certainly
suggest that be deferred until someone has a good suggestion
for doing it.
4) If one of the endpoints is a decomposed entity where the signaling is
decoupled from the media part, it adds far much complexity, because you
need to upgrade the interface in between these two boxes. This might be
the case of a third party call controller.
[rrg]: It doesn't seem like such an upgrade (adding a string of digits
for identification) would cost much. The ability to use non-
digital facilities would widen the applicability, I'd think.
I'd think it would be easy enough to add later via an attribute
and related procedures, if someone wants to implement it later
rather than sooner.
5) Yes, it solves the problem in all known scenarios, but at a very high
cost compared to the other mechanisms.
[rrg]: What's the cost of crossed calls?
My proposal is pragmatical: Let's live with what we have specified
today. It is not perfect, but will work in high number of scenarios. The
draft already documents the imperfections of the system. Let's make sure
that we leave the door open for this mechanism to be standardize when we
have a bit more of operational experience and we know whether we want
that mechanism or not.
[rrg]: Given that extensions or alternative association mechanisms are
permitted, that should be OK.
/Miguel
Bob Gilman wrote:
Miguel, Adam -
Why not make the use of DTMF digits (part of) the initial correlation
mechanism? The digits can be included in SDP as part of the initial
exchange. Some of the advantages would be:
1. If the receiver of the DTMF specifies the digits, they can be
guaranteed unique (permitting shorter strings than a "random"
choice.)
2. The receiver would know that digits are coming, so it could delay
cut-through to its endpoint until the digits are received. DTMF
receivers typically filter digits anyway.
3. This avoids the complexity of a failure/fallback mechanism.
4. This allows the use of different types of PSTN and/or private
facilities, independent of ISDN or caller-id.
5. If necessary (and at somewhat greater expense), the digit exchange
could be made cryptographically secure to prevent some sort of
call-injection attack.
Agreed, cut-through is delayed, but not by much (signalling rates are
between 3 and 9 digits per second) when it's not a secondary mechanism
that requires extra out-of-band signalling.
The consequences of a mix-up of calls might be merely annoying, but it
could be disastrous, so I think it's worth taking steps to make the
possibility as small as possible.
Does this make sense?
-Bob
-------------------------------------------------------------
Bob Gilman bob_gilman at comcast.net +1 303 898 9780
Miguel A. Garcia wrote:
Hi Adam:
Thanks for your comment.
First, you are right in your analysis. None of the provided
correlation mechanisms are able to guarantee 100% of success.
We thought about the DTMD digits, but it brings some other problems.
First, you can only exchange DTMF digits once the circuit (bearer) is
setup, as opposed to the two specified mechanisms that operate prior
or during the setup of the bearer. The implication is that you are
delaying the session establishment time. In addition, this mechanism
would require some additional mechanism to "hide" those DTMF tones
from the user, so, not playing them. Alternatively, one could use
some sort of subaudible tones such as CTCSS. Honestly, I think this
will increase the complexity of implementations. Furthermore, I don't
think anyone will implement it.
So, I guess what we have in the spec is simple but not 100% secure.
It's better than nothing.
/Miguel
Adam Roach wrote:
The current version of garcia-mmusic-sdp-cs details two potential
correlation mechanisms (caller-id and UUI), both of which are known
to fail under some relatively common circumstances.
It REQ-5 is actually a MUST (instead of a SHOULD), I would guess
that we need a reliable backup mechanism that we can use in case the
other two fail -- perhaps exchanging a short series of DTMF digits
over the CS connection for correlation purposes?
I would imagine you could have some signaling over the IP side of
things that semantically means, "I just got an incoming CS
connection, but can't tell whether it is you because both the
correlation mechanisms failed. Please send the DTMF digit string
"36254" on your outbound connection so I can tell whether this is you."
/a
-------------------------------------------------------------
Bob Gilman bob_gilman at comcast.net +1 303 898 9780
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic