<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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><div>Dave</div><div><br></div><br><div><div>On 2012-11-08, at 6:47 PM, Skyler <<a href="mailto:skchopperguy@gmail.com">skchopperguy@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 href="sip:10.1.1.10;line=sr-N6IAzhaINwPlPxFAOBPAOBM6OBFLWxvuMx3A">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 class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 2012-11-08, at 3:59 AM, Andrew Pogrebennyk <<a href="mailto:apogrebennyk@sipwise.com">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 href="sip:provider's">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">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></div></blockquote></div><br>
</blockquote></div><br></body></html>