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

["Elwell, John" <john.elwell at siemens-enterprise.com>]

> -----Original Message-----
> From: Simo.Veikkolainen at nokia.com 
> [mailto:Simo.Veikkolainen at nokia.com] 
> Sent: 22 May 2009 11:51
> To: Elwell, John; mmusic at ietf.org
> Subject: RE: [MMUSIC] Any comments on draft-ietf-mmusic-sdp-cs-00?
> 
> Hi John,
> Thanks for your comments.  See below.
> 
> >-----Original Message-----
> >From: ext Elwell, John [mailto:john.elwell at siemens-enterprise.com] 
> >Sent: 19 May, 2009 09:58
> >To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic at ietf.org
> >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. 
[JRE] Yes. Thanks.

John


> 
> >
> >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
> 
> >
> >John
> >
> >
> >> -----Original Message-----
> >> From: mmusic-bounces at ietf.org
> >> [mailto:mmusic-bounces at ietf.org] On Behalf Of 
> >> Simo.Veikkolainen at nokia.com
> >> Sent: 15 May 2009 10:40
> >> To: mmusic at ietf.org
> >> 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
> >>  
> >> 
> >
>