<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><blockquote type="cite">We do have patches for SIP identity in the bug tracker and we do support TLS, which also gives a trusted identity. It needs to be in the "secure call" concept within the dialplan.</blockquote></div></blockquote><div><br></div><div>Right, but TLS matches up with "secure signaling". And like I said, adding another option to the CHANNEL() variable for requiring only authed caller id would be simple once it is added.</div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote>Or shall it be an option or variant of DIAL()? How do we handle this in the various ways we have of originating a call?<br>I think that the CHANNEL() dialplan function is not the answer. Let's not overload it, let's create a new function and make sure it's channel independent.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Dial would be the wrong place for this since there are multiple ways to initiate a call in Asterisk. Originate, for example. I initially created a new function, but was convinced by the arguments that CHANNEL() was the way to go since that is what it was designed for. I, personally, don't really care where the function resides as the code will be mostly the same. But, it would seem inconsistent to not have the options in the CHANNEL function.</div><br><blockquote type="cite"><div><blockquote type="cite">How much can we do via the dialplan?<br></blockquote><blockquote type="cite">How do we handle "optional" encryption amongst multiple technologies?<br></blockquote><blockquote type="cite">What would be the best way to notify someone whether the other side of a conversation is secure?<br></blockquote>and what is the definition of "secure" ? Who defines a "secure call" and how?</div></blockquote><div><br></div>The goal is "whoever writes the dialplan". But, I think it is important to be able to configure in the channel config files as well and that we should make those as consistent as possible.<br><br><blockquote type="cite"><div><blockquote type="cite">Pointing out that bridges needed to be considered is certainly a good point and wasn't something I'd thought of. Implementation details like what to do in a particular case, I'm not that worried about. Those things are fairly easy to add at any stage. I would just hate to see SRTP miss the 1.8 release. The code can be very difficult to merge when it gets out of date. Better to have a set of core functionality merged in where anyone can then go in and modify stuff in trunk (even if there are some things missing), than to try to maintain the branch indefinitely to get things "perfect".<br></blockquote>Well, that's asterisk tradition. We still have a really poor TLS implementation in chan_sip that no one bothers to complete, so let's not do the architecture thing and continue adding things that doesn't follow any architecture of Asterisk and doesn't fit together... <br><br>Look at the COPS module that was added without documentation, without proper dependencies and being enabled by default. Bad product design, but it sure compiled and loaded into Asterisk.<br></div></blockquote><div><br></div><div>I think this is just the nature of open source. When lots of people have access to commit to trunk, occasionally something is going to get in that not everyone agrees with or that is kind of broken. The hope is that people use the review procedures that have been set up and that we can catch a lot of these and get them fixed before a release. While I would love for there to be a self-aware pre-commit hook for subversion that could determine if there are problems, I think it might be a few years out. ;-)</div><br><blockquote type="cite"><div>I do understand your arguments, but I still think it is the wrong approach from a software management point of view. When we create a new release of Asterisk it has to have some design, not just separate stuff we put into it from various sources, stuff that has some hooks and compiles with the rest but doesn't fit into the product design... We need to design Asterisk, not just code it. Otherwise it will fall apart and be way too hard to understand, use and teach.<br></div></blockquote><div><br></div><div>I'm certainly not arguing against design, I'm just saying that design is different than "implementation details", which is where a lot of the "what about this SIP scenario" stuff seemed to fit. Like I said before, I think it is important to get everyone's opinion on things like how the dialplan parts will work, where the control will be, etc. </div><br><blockquote type="cite"><div><blockquote type="cite">So mostly I'm thinking of "big picture" design ideas right now to make sure that I'm not going in a direction that people see any big problems with. Another good place to discuss some design would be to use reviewboard. I'll see if I can't get the new code that has been brought up to date up there soon for people to comment on as well. I also need to go through and document a lot of the code that is already there--much of that has never been done. In addition, I'll see if I can write up a document that explains thoroughly "how it works now". Since this code has been around for a while, it isn't like we're designing in a vacuum. Much has already been written.<br></blockquote><br>Well, it's just the SRTP code. The dialplan and configuraiton interface still needs design... I don't think reviewboard is a platform for design discussions - it's for reviewing code.<br></div></blockquote><div><br></div><div>Right, but since this is like a 5 year old patch, there is already a lot of code. And it is code that had been up on review board once before without a lot of input. I just figure it is important for people to see what currently exists. Thats also why I said I need to create an additional document which would include a description of how everything currently works, as a starting point to how we can get to where we all want to go.</div></div><div><br></div><div>Terry</div></body></html>