woops, [% networking.iaddress %]<br><br><div class="gmail_quote">On Thu, Nov 8, 2012 at 9:15 PM, Skyler <span dir="ltr"><<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div>sorry, in config.yml look for anything 127.0.0.1 and change them to 172.16.10.55</div>
<div> </div><div>also check that there are no hard-coded lo's in any configs. Like cd /etc/ngcp-config/templates/etc then grep -r 127.0.0.1 .</div>
<div> </div><div>If you find any hard-coded entries just replace the 127.0.0.1's with [% networking.eaddress %]<br></div><div>then ngcpcfg apply</div><span class="HOEnZb"><font color="#888888"><div> </div><div>Skyler<br>
</div></font></span><div class="HOEnZb"><div class="h5"><div class="gmail_quote">On Thu, Nov 8, 2012 at 8:47 PM, Skyler <span dir="ltr"><<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div>well I spent 3 hours loading win7 as my primary OS and now virtualbox crashes BSOD's all the time (grr). So while I figure out what flavor to load back on now...try the below.</div>
<div> </div><div>as root on your vz:</div>
<div> </div><div>remove or comment out the topoh.so in your LB config and save</div><div>ifconfig lo add 172.16.10.55</div><div>ifconfig to verify lo:0 is there</div><div>ping 172.16.10.55 just for fun</div><div> </div><div>
open config.yml and change iaddress to 172.16.10.55</div><div>ngcpcfg apply</div><div> </div><div>run a test call through TieUS and see if that works. If so, then test call through voxcentral. If this doesn't work, then change iaddress back to 127.0.0.1 and (init 6) reboot to clear the temporary lo:0 entry.</div>
<span><font color="#888888">
<div> </div><div>Skyler <br><br></div></font></span><div><div><div class="gmail_quote">On Thu, Nov 8, 2012 at 6:42 PM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div style="word-wrap:break-word"><div>Yup. Let me know if you have something you want me to try out ;)</div>
<div><div><div><br></div><div> </div><br><div><div>On 2012-11-08, at 9:20 PM, Skyler <<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div>Ah ok, so 1 & 2 are the same. So the RR & via being 127.0.0.1 breaks TieUS. When topoh is used, TieUS works but breaks Voxcentral. Got it.</div><div> </div><div>Skyler<br><br></div><div class="gmail_quote">On Thu, Nov 8, 2012 at 5:57 PM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div style="word-wrap:break-word"><div>Close.</div><div><br>
</div><div>Point 1 is correct.!</div><div><br></div><div>Point 2 is N/A, I dont have them as a provider., that problem belongs to provider A as well. (TieUS), and Im not 100% yet, but I believe the DTMF INFO only works when using topoh, if I change the 127.0.0.1 to something else instead of topoh it seems to break again (will verify again)..</div>
<div><br></div><div>pont 3 is correct.!</div><div><br></div><div>Thanks</div><span><font color="#888888">Dave</font></span><div><div><div><br></div><br><div><div>On 2012-11-08, at 6:47 PM, Skyler <<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div>Hi Dave,</div><div> </div><div> Just to clarify, my understanding of the problem(s) is:</div><div> </div><div>1. Provider A (TieUS) has inbound DTMF and call dropping problem because the RR is 127.0.0.1 and they don't like this. So the last-resort solution is to introduce topoh to re-write as private address space. However, in doing so, the spce-lb is detecting 'NATed request detected' and subsequent 'NATed in-dialog request detected'. This results in add_contact_alias() being called to rewrite the Contact as <<a>sip:10.1.1.10;line=sr-N6IAzhaINwPlPxFAOBPAOBM6OBFLWxvuMx3A</a>>. This causes problems with other carriers.</div>
<div> </div><div>2. Provider B (Group Telecom) sends DTMF as INFO. This is now fixed by adding INFO to spce-proxy.</div><div> </div><div>3. Provider C (Voxcentral) has no issues until topoh is introduced. Then due to the bad contact, they drop the call(s) after some time.</div>
<div> </div><div> Is this correct?</div><div> </div><div>Skyler<br></div><div class="gmail_quote">On Thu, Nov 8, 2012 at 6:49 AM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Im not sure Im not familiar with topoh.<br>
<br>
I have to do some more testing to be sure, but INFO worked for DTMF and using topoh, but didnt work using the method below.<br>
But I have to check again to be sure.<br>
<div><br>
<br>
<br>
On 2012-11-08, at 3:59 AM, Andrew Pogrebennyk <<a href="mailto:apogrebennyk@sipwise.com" target="_blank">apogrebennyk@sipwise.com</a>> wrote:<br>
<br>
> Hi Dave,<br>
><br>
> On 11/07/2012 03:40 AM, Dave Massey wrote:<br>
>><br>
>> I went back to the roots of modifying the iaddress field in config.yml<br>
>> after creating an unused "dummy" ethernet interface. I wasn't modifying<br>
>> the other 2 instances of 127.0.0.1 as was mentioned by Andrew today.<br>
>> And that worked... But maybe lost the SIP INFO DTMF in one direction again.<br>
>><br>
>> Both peers now work (minus incoming DTMF from TieUS, again) without<br>
>> dropping calls.<br>
>><br>
>> You think this is a good way to work around this problem?<br>
><br>
> That is a good way IMO, yes.<br>
><br>
> What are you trying to accomplish with topoh? We use sems to rewrite the<br>
> From and To header with <a>sip:provider's</a> IP address and that should be it.<br>
> Hasn't DTMF problem been resolved by adding INFO to the supported methods?<br>
><br>
> BR,<br>
> Andrew<br>
<br>
<br>
_______________________________________________<br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
<a href="http://lists.sipwise.com/listinfo/spce-user" target="_blank">http://lists.sipwise.com/listinfo/spce-user</a><br>
</div></blockquote></div><br>
</blockquote></div><br></div></div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>