[Spce-user] 400 Normal Release

[Skyler]

oh my gosh, I didn't even read the OpenVZ stuff. I actually ignored that as
I figured it was over-my-head. Its the same thing as doing the 'lo:0'. my
bad, hope you figured that out and didn't bother.

So if you have the dummy0 interface (192.168.10.1) and iaddress + all
127.0.0.1 entries in config.yml have changed to 192.168.10.1... then that
will change the RR & Via IP so it does not use 127.0.0.1 anymore,
effectively fixing that TieUS issue. In short, the topoh shouldn't be
needed at all then.
just remove the topoh and that should do it. Is there any issues after all
that?

Skyler
On Thu, Nov 8, 2012 at 9:36 PM, Skyler <skchopperguy at gmail.com> wrote:

> may have to maually restart mediaproxy and sems. Like
> /etc/init.d/ngcp-mediaproxy restart
>
> S.
>
> On Thu, Nov 8, 2012 at 9:16 PM, Skyler <skchopperguy at gmail.com> wrote:
>
>> woops, [% networking.iaddress %]
>>
>>
>> On Thu, Nov 8, 2012 at 9:15 PM, Skyler <skchopperguy at gmail.com> wrote:
>>
>>> sorry, in config.yml look for anything 127.0.0.1 and change them to
>>> 172.16.10.55
>>>
>>> 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 .
>>>
>>> If you find any hard-coded entries just replace the 127.0.0.1's with [%
>>> networking.eaddress %]
>>> then ngcpcfg apply
>>>
>>> Skyler
>>> On Thu, Nov 8, 2012 at 8:47 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>> as root on your vz:
>>>>
>>>> remove or comment out the topoh.so in your LB config and save
>>>> ifconfig lo add 172.16.10.55
>>>> ifconfig to verify lo:0 is there
>>>> ping 172.16.10.55 just for fun
>>>>
>>>> open config.yml and change iaddress to 172.16.10.55
>>>> ngcpcfg apply
>>>>
>>>> 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.
>>>>
>>>> Skyler
>>>>
>>>> On Thu, Nov 8, 2012 at 6:42 PM, Dave Massey <dave at optionsdsl.ca> wrote:
>>>>
>>>>> Yup.  Let me know if you have something you want me to try out ;)
>>>>>
>>>>>
>>>>>
>>>>> On 2012-11-08, at 9:20 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>>
>>>>> 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/844647eb/attachment-0001.html>