<div dir="ltr">Hello Brian,<div><br></div><div>In general, you're totally right. But in my case I know the call will never go through PSTN. Also I've made tests about the header and The FS-B receives the header fine. </div>
<div><br></div><div>So this works ok for me.</div><div><br></div><div>Thanks!</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 4:07 PM, Brian West <span dir="ltr"><<a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You're working under the assumption that your custom headers are going to traverse your providers network and make it back to the second freeswitch... I don't think you can make that assumption. I know if I were a provider all your custom headers would be nuked at the border in ingress to my network.<br>
<br>
You're just trying to make sure that calls stay on the approved network routes.. not sure you can make sure that will always happen end to end if a route takes PSTN out and back in you've lost the ability to follow this... unless I'm totally off base here and missed the point.<br>
<span class="HOEnZb"><font color="#888888"><br>
/b<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sep 24, 2013, at 5:33 PM, David Villasmil <<a href="mailto:david.villasmil.work@gmail.com">david.villasmil.work@gmail.com</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> I don't think this is something FS can do. Let me explain:<br>
><br>
> We have FS-A and FS-B, between which are multiple SIP providers. We are checking that the providers between A and B don't divert calls to non-approved vendors. So what I'm doing is:<br>
><br>
> When relaying the call from FS-A to the provider, I'm adding a SIP header with a unique ID, which is inserted into a DB table.<br>
> When FS-B receives the call, i retrieve the header ID and look it up in the table and mark it as answered.<br>
> On FS-A, when the call is answered, it looks up the ID and makes sure it has been marked as "answered" by FS-B.<br>
> If it is NOT marked, FS-A MUST disconnect the call.<br>
><br>
> I hope the explanation was clear, and if anyone has a better idea of how to do this, I'm all ears :)<br>
><br>
> Thanks<br>
><br>
> David<br>
<br>
</div></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>