Re: [MMUSIC] draft-garcia-mmusic-sdp-cs-02: thoughts on correlation

[<Simo.Veikkolainen at nokia.com>]

>-----Original Message-----
>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia at ericsson.com] 
>Sent: 17 November, 2008 10:20
>To: Bob Gilman
>Cc: Adam Roach; Veikkolainen Simo (Nokia-D/Helsinki); mmusic
>Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-cs-02: thoughts 
>on correlation
>
>Hi Bob:
>
>I guess this is exactly what Adam was proposing. At least, I 
>haven't seen a difference with original Adam's proposal.
>
>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.
>
>2) Who is going to implement this mechanism?
>
>3) If we add the cryptographic exchange, who is going to 
>implement this mechanism?
>
>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.
>
>5) Yes, it solves the problem in all known scenarios, but at a 
>very high cost compared to the other mechanisms.
>
>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.
>
>/Miguel

Today in the MMUSIC session folks expressed interest in defining a
DTMF-based mechanism for correlation purposes. So, we will add this in
the next version of the document. The details, however, are still to be
ironed out.

-Simo

>
>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
>>>
>> 
>> 
>
>--
>Miguel A. Garcia
>+34-91-339-3608
>Ericsson Spain
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic