<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 10, 2010, at 2:29 PM, Olle E. Johansson wrote:</div><blockquote type="cite"><div>I wonder if we should try to raise ourselves a bit above various channel specifics.<br></div></blockquote><div><br></div><div>That was always my goal. :-) That's why I want to do as much in the dialplan as possible. We just need to make sure that all of our channels behave consistently--even the ones that don't support encryption. It doesn't do us any good if we store somewhere that encryption is required, and then have the channel code ignore it.</div><div><br></div><blockquote type="cite"><div>If we have an inbound call, we can have or require a combination of<br> - secure signalling<br> - secure caller ID (identity)<br> - secure media<br> - secure IM<br></div></blockquote><div><br></div><div>Wouldn't caller id be part of signaling and IM be part of media, though? Is there any protocol in existence where you can have secure caller id w/o secure signaling or would not have secure caller id if you did have secure signaling? I admit my lack of experience with much more than SIP and a little IAX, so if you have any examples in mind, let me know.</div><div><br></div><blockquote type="cite"><div>We also need to be able to have a property on the bridge - like the meetme. <font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>This makes sense and seems like something we would need to me.</div><br><blockquote type="cite"><div>- inbound call with SRTP<br>- outbound call to forking SIP proxy<br> - 183 with RTP from one server<br> - 200 OK with SRTP<br><br>SHould we play the early media if we have a security requirement?<br></div></blockquote><div><br></div><div>If we have required SRTP (media), we haven't offered anything other than RTP/SAVP. If the 183 comes in with non-encrypted audio, I would think that something on the other end was broken. So, in my opinion we would just ignore the response.</div><br><blockquote type="cite"><div>- incoming call with TLS/SRTP - security requirement for outbound call<br> - 200 OK with SRTP<br> - REFER to non-SRTP device <br><br>- should we deny transfer?<br></div></blockquote><div><br></div><div>If we are requiring all bridged calls to be encrypted, then I would say that we would have to deny the transfer.</div><br><blockquote type="cite"><div> - outbound call without security requirement<br> - 200 OK with one offer RTP and an alternative with SRTP in the same SDP<br><br> Polycoms do this if configured that way. What do we choose? (if we could parse the SDP correctly :-) )<br></div></blockquote><div><br></div><div>We yell at Polycom for doing something silly? :-p Essentially that would be saying that we should have both encrypted and unencrypted audio and accept and set up both (much like a video and audio offer), wouldn't it? I think the code would currently treat this as an encrypted call, but I haven't tested it yet. Last time that I looked at the different phones, Snom, Polycom, and Grandstream all handled this a different way. It is what led me to not supporting "optional" encryption. I vote for, "if we see an offer with encryption that we support somewhere, we go ahead and encrypt the call.</div><br><blockquote type="cite"><div>- outbound call with security requirement<br> - 200 OK with SRTP for audio, but RTP for video and text<br><br> - Do we accept non-secured media streams? Or reject the call?<br></div></blockquote><div><br></div><div>Ugh. Can we just hope that it never comes up and ignore the case completely :-) Under the current paradigm, I'd say reject the call since it doesn't include security for all options. But, I can see how that wouldn't necessarily be what one would want to happen. But I really don't want to have to specify requirements for every different kind of media that could possibly exist. audio/video/text/image/morse code/smoke signals/whatever. :-) It starts to be kind of a pain, dialplan-wise. It seems silly that a client would choose to send encrypted audio, but leave the other media unencrypted. But, people do silly things all the time.</div><div><br></div><div>Terry</div></div><br><div><br></div><div><br></div></body></html>