[Spce-user] 400 Normal Release

[Skyler]

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.

Skyler

On Thu, Nov 8, 2012 at 5:57 PM, Dave Massey <dave at optionsdsl.ca> wrote:

> Close.
>
> Point 1 is correct.!
>
> 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)..
>
> pont 3 is correct.!
>
> Thanks
> Dave
>
>
> On 2012-11-08, at 6:47 PM, Skyler <skchopperguy at gmail.com> wrote:
>
> Hi Dave,
>
>  Just to clarify, my understanding of the problem(s) is:
>
> 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.
>
> 2. Provider B (Group Telecom) sends DTMF as INFO. This is now fixed by
> adding INFO to spce-proxy.
>
> 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.
>
>  Is this correct?
>
> Skyler
> On Thu, Nov 8, 2012 at 6:49 AM, Dave Massey <dave at optionsdsl.ca> wrote:
>
>> Im not sure Im not familiar with topoh.
>>
>> 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.
>> But I have to check again to be sure.
>>
>>
>>
>> On 2012-11-08, at 3:59 AM, Andrew Pogrebennyk <apogrebennyk at sipwise.com>
>> wrote:
>>
>> > Hi Dave,
>> >
>> > On 11/07/2012 03:40 AM, Dave Massey wrote:
>> >>
>> >> I went back to the roots of modifying the iaddress field in config.yml
>> >> after creating an unused "dummy" ethernet interface.  I wasn't
>> modifying
>> >> the other 2  instances of 127.0.0.1 as was mentioned by Andrew today.
>> >> And that worked... But maybe lost the SIP INFO DTMF in one direction
>> again.
>> >>
>> >> Both peers now work (minus incoming DTMF from TieUS, again) without
>> >> dropping calls.
>> >>
>> >> You think this is a good way to work around this problem?
>> >
>> > That is a good way IMO, yes.
>> >
>> > What are you trying to accomplish with topoh? We use sems to rewrite the
>> > From and To header with sip:provider's IP address and that should be
>> it.
>> > Hasn't DTMF problem been resolved by adding INFO to the supported
>> methods?
>> >
>> > BR,
>> > Andrew
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121108/3bc38358/attachment-0001.html>