<div>correction in #1, I've confirmed that add_contact_alias() is not involved. Just that topoh reqries Contact as <sip:10.1.1.10;line=sr-N6IAzhaINwPlPxFAOBPAOBM6OBFLWxvuMx3A>. Which causes issue with provider(s) other than TieUS.</div>
<div> </div><div>Skyler<br><br></div><div class="gmail_quote">On Thu, Nov 8, 2012 at 3: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>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 <sip:10.1.1.10;line=sr-N6IAzhaINwPlPxFAOBPAOBM6OBFLWxvuMx3A>. 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><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 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><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 sip:provider's 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></div></blockquote></div><br>
</div></div></blockquote></div><br>