[Spce-user] 400 Normal Release

[Skyler]

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/c40c285c/attachment-0001.html>