Subject: [MMUSIC] Any comments on draft-ietf-mmusic-sdp-cs-00?

From: <[email-masked]>
Date: Fri, 15 May 2009 11:39:47 +0200

Hello,

Our draft on SDP Extension For Setting Up Audio Media Streams Over CS Bearers In The PSTN (http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-00) was submitted as a WG item before the SF meeting, and since then we haven't had much discussion on it.

We are not planning to a major revision of the doc at the moment, so now would be a good time to take a look at the doc and comment on this list.

Thanks
Simo and Miguel

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 May 2009 07:58:15 +0100

Simo, Miguel,

1. I wonder whether a little more can be said about non-support for the
two correlation methods. If a received call contains neither calling
line ID nor UUS, what should I do?  I could treat it as not related to
the CS call negotiated through SDP, in other words treat it as an
unrelated incoming call that happens to arrive during the time window
when I am expecting the CS call. I might, for example, reject the call,
since I am busy on another call, or I might cause it to wait for me to
become free.

On the other hand I could say that, because it arrived during the window
in which I expected the CS call, that it is indeed the expected CS call
and I should treat it as such. There is a small chance it was an
independent call, in which case I would falsely associate it with the
SDP exchange.

2. The security considerations section needs more work. For example, we
could talk about the correlation mechanisms and the chances that they
could mislead and hence the potential for attack. Also the inability to
use SRTP or other mechanisms to secure the media path should be
mentioned.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 15 May 2009 10:40
> To: [email-masked]
> Subject: [MMUSIC] Any comments on draft-ietf-mmusic-sdp-cs-00?
> 
> Hello,
>  
> Our draft on SDP Extension For Setting Up Audio Media Streams 
> Over CS Bearers In The PSTN 
> (http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-00 
> <http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-00> ) 
> was submitted as a WG item before the SF meeting, and since 
> then we haven't had much discussion on it. 
>  
> We are not planning to a major revision of the doc at the 
> moment, so now would be a good time to take a look at the doc 
> and comment on this list.
>  
> Thanks
> Simo and Miguel
>  
>

---

From: <[email-masked]>
Date: Fri, 22 May 2009 12:50:44 +0200

Hi John,
Thanks for your comments.  See below.

>From: ext Elwell, John [mailto:[email-masked]] 
>Sent: 19 May, 2009 09:58
>To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]
>Subject: RE: [MMUSIC] Any comments on draft-ietf-mmusic-sdp-cs-00?
>
>Simo, Miguel,
>
>1. I wonder whether a little more can be said about 
>non-support for the two correlation methods. If a received 
>call contains neither calling line ID nor UUS, what should I 
>do?  I could treat it as not related to the CS call negotiated 
>through SDP, in other words treat it as an unrelated incoming 
>call that happens to arrive during the time window when I am 
>expecting the CS call. I might, for example, reject the call, 
>since I am busy on another call, or I might cause it to wait 
>for me to become free.
>
>On the other hand I could say that, because it arrived during 
>the window in which I expected the CS call, that it is indeed 
>the expected CS call and I should treat it as such. There is a 
>small chance it was an independent call, in which case I would 
>falsely associate it with the SDP exchange.

I assume you refer to a case where the support of some correlation mechanism(s) has been successfully negotiated during SDP o/a exchange, but a CS call does not use any of these mechanisms. We could add some text to Section 5.2.3.5 to describe what an implementation should do in that case. Since by looking at the call signalling it cannot be determined that the call is related to an ongoing SDP exchange, the decision could be left to the end user. 

>
>2. The security considerations section needs more work. For 
>example, we could talk about the correlation mechanisms and 
>the chances that they could mislead and hence the potential 
>for attack. Also the inability to use SRTP or other mechanisms 
>to secure the media path should be mentioned.

Right, these are both good examples of relevant scenarios. We'll add some text to elaborate these.

Regards,
Simo

>> Our draft on SDP Extension For Setting Up Audio Media 
>Streams Over CS 
>> Bearers In The PSTN 
>> <http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-00> ) was 
>> submitted as a WG item before the SF meeting, and since then we 
>> haven't had much discussion on it.
>>  
>> We are not planning to a major revision of the doc at the moment, so 
>> now would be a good time to take a look at the doc and 
>comment on this 
>> list.
>>  
>> Thanks
>> Simo and Miguel
>>  
>> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 May 2009 17:41:56 +0100

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 22 May 2009 11:51
> To: Elwell, John; [email-masked]
> I assume you refer to a case where the support of some 
> correlation mechanism(s) has been successfully negotiated 
> during SDP o/a exchange, but a CS call does not use any of 
> these mechanisms. We could add some text to Section 5.2.3.5 
> to describe what an implementation should do in that case. 
> Since by looking at the call signalling it cannot be 
> determined that the call is related to an ongoing SDP 
> exchange, the decision could be left to the end user. 
[JRE] Yes. Thanks.

John

> moment, so