<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>At my company we are using Broadsoft as the SIP feature server platform fronted by Acme Session Directors. &nbsp;Using a combination of CUBE on the CPE with SIP Profiles and Enterprise Trunking in Broadworks, we allow "Unscreened Calling" from our customers meaning they don't have to send a From number that is part of their DID block. &nbsp;They can send any From number (or lack there of) and we still permit the call to go through because the Acme matches the invite based on source IP and port the CPE is registered from and Broadworks is matching on the TGRP in both Registration and Invite messages from the CPE and comparing that to what is assigned to the customer's Trunk Group in Broadworks. &nbsp;</div><br><div><div>On Mar 16, 2010, at 12:20 PM, STEVEN CASPER wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="MARGIN: 4px 4px 1px">
<div>Thanks! I also find the CLID matching to be an irritant. It is easy in most cases to bypass but screws up your CLID when you do so. What other methods are you seeing carriers using to verify validity?&nbsp;&nbsp;</div>
<div>&nbsp;</div>
<div>Steve<br><br>&gt;&gt;&gt; Mark Holloway &lt;<a href="mailto:mh@markholloway.com">mh@markholloway.com</a>&gt; 3/16/2010 1:37 PM &gt;&gt;&gt;<br>Use SIP Profiles on your router to change anonymous@ to XXXXXXXXXX@<br><br><a href="http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml">http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml</a><br><br>Your carrier should rethink how they are receiving SIP Invites and what credentials are being used to verify the validity of the invite message. I know that doesn't solve your problem, but it's incredibly irritating to see how some carriers are (mis)handling SIP trunks. <br><br><br>On Mar 16, 2010, at 10:18 AM, STEVEN CASPER wrote:<br><br>&gt; I have a Right fax server that dials through our Call Manager and I am testing trying to send it out an IP Trunk service. The Rightfax server via the Call Manager sends this to the cube:<br>&gt; <br>&gt; From: "Anonymous " &lt;<a href="sip:anonymous@10.125.15.19">sip:anonymous@10.125.15.19</a>&gt;;tag=e9327c44-2ce1-444e-a47c-e6abce01eae2-124956419<br>&gt; <br>&gt; The CUBE sends this to the carrier:<br>&gt; <br>&gt; From: "anonymous" &lt;<a href="sip:anonymous@sip.bank.com">sip:anonymous@sip.bank.com</a>&gt;;tag=3C1A7418-2265<br>&gt; <br>&gt; It is rejected because the carrier is looking for a 10 digit number that has been registered to their service. Is there any way on the CUBE or Call Manager to change the anonymous to a ten digit number? I also have the Rightfax team looking into changing this on the Rightfax side but I like to have options<br>&gt; <br>&gt; From a normal phone the IP Trunk service works fine as long as I just send a registered 10 digit external mask to the carrier.<br>&gt; <br>&gt; Steve<br>&gt; <br>&gt; ************************************<br>&gt; This email may contain privileged and/or confidential information that is intended solely for the use of the addressee.&nbsp; If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission.&nbsp; If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.&nbsp; This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.&nbsp; You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.<br>&gt; There are risks associated with the use of electronic transmission.&nbsp; The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.<br>&gt; ************************************<br>&gt; &lt;Message.html&gt;_______________________________________________<br>&gt; cisco-voip mailing list<br>&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco">https://puck.nether.net/mailman/listinfo/cisco</a>-voip<br><br><br></div><pre>************************************
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee.  If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission.  If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.  This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission.  The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
************************************
</pre></div>
</blockquote></div><br></body></html>