<div dir="ltr">Ah I forgot that <span class="Apple-style-span" style>SIP INFO for DTMF and TLS would be enough... but maybe not for the guidelines..</span><div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><br>
</font></div><div><font class="Apple-style-span" color="#222222" face="arial, sans-serif">And yes, it's possible to con/bribe/hack the telco's.. but since the calls are going over the PSTN anyway, you remove the entire "public" part of the call from being open. I presume it's at least better if that's the only opening..</font></div>
<div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><br clear="all"></font><div dir="ltr"><font face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:13px"><span style="font-size:small">-Avi Marcus</span><br>
<span style="font-size:small">BestFone</span></span></font></div><br>
<br><br><div class="gmail_quote">On Mon, Dec 19, 2011 at 2:46 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You probably already know this, but there is no technical logic to the PCI guidelines. It is not a logical process, and the requirements are not conceived by people who really understand how technology and workflows in voice service delivery function. And, in general, if the auditors don't understand it--which they invariably don't--it's not compliant.<br>
<br>
So, for instance, with regard to DTMF, you could use SIP INFO for DTMF transition, and encrypt your signaling (say, with TLS) but not your media. Strictly speaking, that would be secure, since the credit card numbers do not appear either as RTP OOB events in the media stream, or in-band, but rather as signaling artifacts. However, this is way too clever for the kinds of people that get to define the compliance requirements.<br>
<br>
More generally, the assumption that PSTN analog or digital lines are inherently secure in ways that the public Internet is not is, of course, ridiculous. In fact, by many accounts, sniffing third-parties' packets is considerably more laborious a chore than bribing ILEC employees to assist in tapping circuits, or going to a junction box with a set of alligator clips. But, as I said, rhyme and reason is not part of the formula.<div class="HOEnZb">
<div class="h5"><br>
<br>
-- <br>
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
260 Peachtree Street NW<br>
Suite 2200<br>
Atlanta, GA 30303<br>
Tel: <a href="tel:%2B1-678-954-0670" value="+16789540670" target="_blank">+1-678-954-0670</a><br>
Fax: <a href="tel:%2B1-404-961-1892" value="+14049611892" target="_blank">+1-404-961-1892</a><br>
Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-biz mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-biz" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-biz</a><br>
</div></div></blockquote></div><br></div></div>