[Spce-user] 400 Normal Release

Tue Nov 6 22:42:40 EST 2012

Oh ok, so your INFO/DTMF is handled via proxy which will take care of dtmf
from GT inbound. If TieUS is all that's left, then the Topoh solution
should work, just a matter of finding which add_contact_alias() needs to be
tweaked in your LB config to work around them.

Add the loadmodule "topoh.so"  back into your customtt for LB (apply)
do the ngrep with test call and tail -f the LB log with test call

Attach here and maybe we can figure this out together ;) I had wanted to
look into topoh anyway so this will help me out too.

Skyler

On Tue, Nov 6, 2012 at 7:09 PM, Dave Massey <dave at optionsdsl.ca> wrote:

> Ok no problem,.  Sandy owned a lot of people ;)
>
> James accidentally removed me too,.. ;)
>
> I only have Voxcentral and TieUS.  Voxcentral in/out/DTMF is all working
> perfectly now.
> I dont even really want to use TieUS but perhaps the only trunk provider
> porting numbers in my service area (519587).  I still with much
> disappointment never found a provider doing 519443 :(
>
> Appreciate all the help though.
>
> Dave
>
>
>
>
> On 2012-11-06, at 9:58 PM, Skyler <skchopperguy at gmail.com> wrote:
>
> I couldn't follow that openvz stuff, it was over my head.
> IMHO, I would suggest to focus testing on all other peers except for
> TieUS. This way you can ensure those are working well. ie:
> Inbound/Outbound/DTMF(INFO)
>
> Then when comfortable, tackle TieUS. Seems like TieUS is doing something
> unothodox on thier side. Topoh may be the answer there but before going
> that route I'd definitely eliminate the OpenVZ container settings and test
> with your solid carriers first.
>
> Sandy took over my life for 2 weeks. Haven't really had a good chance to
> focus on the sockets test. Tried earlier but the test trunk wasn't working,
> I guess James 'programmatically removed it' by accident. I should have more
> time this week though, I'll let you know.
>
>
> Skyler
>
>
> On Tue, Nov 6, 2012 at 6:40 PM, Dave Massey <dave at optionsdsl.ca> wrote:
>
>> Well...
>>
>> 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?
>>
>> Also wanted to ask you how you made out with Voxcentral and using 2
>> sockets? Did you ever get a chance to look at that?
>>
>> My box is wide open for guinea pig testing.. Its not production yet.  I
>> really hope it will be one day. :)
>>
>> Thanks
>> Dave
>>
>>
>> On 2012-11-06, at 9:27 PM, Skyler <skchopperguy at gmail.com> wrote:
>>
>> Dave, nothing special to do with topoh I think. So next is to modify your
>> lb so it sends the correct contact header. The next question would be,
>> where to put that. Can you do a tail -f /var/log/ngcp/kamailio-lb.log with
>> a test call and attach here? I'm thinking to ginuea pig your box instead of
>> mine ;P
>>
>> Skyler
>>
>> On Tue, Nov 6, 2012 at 6:00 PM, Skyler <skchopperguy at gmail.com> wrote:
>>
>>> Well...
>>>
>>> http://kamailio.org/docs/modules/devel/modules/topoh.html
>>>
>>> 3.2. mask_ip (str)
>>> IP address to be used in masked headers to build valid SIP URIs. Can be
>>> any IP address, even a private-space IP address (e.g., 192.168.1.1), but
>>> must not be SIP server's local IP address. It is not used at all for SIP
>>> routing.
>>> Default value is "10.1.1.10".
>>>
>>> .... There's more settings in there. I'll bet something was missing to
>>> make topoh work. Haven't tried it myself though.
>>>
>>>
>>> Skyler
>>>
>>>
>>> On Tue, Nov 6, 2012 at 5:54 PM, Dave Massey <dave at optionsdsl.ca> wrote:
>>>
>>>> You nailed it.
>>>>
>>>> It was my fault.  last week before I had to break for Hurricane Sandy I
>>>> was desperate to get the TieUS provider working, and was looking at the
>>>> topoh module that Andreas had suggested as a last resort to fix it.  so I
>>>> had a custom template with the single line:
>>>>
>>>> loadmodule "topoh.so"
>>>>
>>>> but that was the only modification, and had to drop all work until
>>>> after the storm was gone, I never even got to test or play with it.
>>>>
>>>> But here is where it gets interesting.  Just that line in the file
>>>> fixed the peer.!  But broke Voxcentral peer.
>>>>
>>>> Now Im back to TieUS peer not working.
>>>>
>>>> But I have hope now that there is a solution  to getting both peers
>>>> working?
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>> On 2012-11-06, at 8:39 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>
>>>> One more try. The rewrite is definitely happening on the LB as the
>>>> first appearance of 10.1.1.10 is in the INVITE between 127.0.0.1:5060(LB) ->
>>>> 127.0.0.1:5062 (Poxy)
>>>>
>>>> Do you use any customtt.tt2's in lb? If so, try to mv
>>>> /etc/ngcp-config/templates/etc/kamailio/lb/kamailio.cfg.customtt.tt2 /tmp
>>>>
>>>> ngcpcfg apply
>>>> ngrep b -d any -qt -W byline port 5060 > /tmp/check
>>>> make a test call
>>>> ctrl +c
>>>> cd /tmp
>>>> grep -r 10.1.1.10 .
>>>>
>>>> If that mystery IP still shows up then that did nothing..so reverse ;)
>>>>
>>>>
>>>> Skyler
>>>>
>>>>
>>>>
>>>> On Tue, Nov 6, 2012 at 5:26 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>
>>>>> I did the apt-get update && apt-get upgrade also .. just for fun ;)
>>>>> nothing there as expected.
>>>>>
>>>>> S.
>>>>>
>>>>> On Tue, Nov 6, 2012 at 5:23 PM, Dave Massey <dave at optionsdsl.ca>wrote:
>>>>>
>>>>>> Nothing.
>>>>>>
>>>>>> root at sip:/etc/ngcp-config# grep -r 10.1.1.10 .
>>>>>> root at sip:/etc/ngcp-config#
>>>>>>
>>>>>>
>>>>>> Im completely boggled :S Until I resumed testing today I have never
>>>>>> seen this IP.
>>>>>> The only major thing I did was apt-get update/upgrade
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>> On 2012-11-06, at 8:17 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> Odd. cd to /etc/ngcp-config/ and do a grep -r 10.1.1.10 . <-- don't
>>>>>> forget the dot on the end
>>>>>>
>>>>>> Anything show up?
>>>>>>
>>>>>> Skyler
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 6, 2012 at 5:00 PM, Dave Massey <dave at optionsdsl.ca>wrote:
>>>>>>
>>>>>>> Yeap thats exactly what I have.
>>>>>>>
>>>>>>> Ive gone as far as checking my entire debian install for even a
>>>>>>> mention of that IP address in any file in /etc  and other directories and
>>>>>>> found nothing. :(
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2012-11-06, at 7:53 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>>>>
>>>>>>> Should be
>>>>>>>
>>>>>>> networking:
>>>>>>>   aaddress:
>>>>>>>     address: 127.0.0.1
>>>>>>>     enable: 'no'
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 6, 2012 at 4:52 PM, Skyler <skchopperguy at gmail.com>wrote:
>>>>>>>
>>>>>>>> Dave,
>>>>>>>>
>>>>>>>>  What do you have set for aaddress in your config.yml?
>>>>>>>>
>>>>>>>> Skyler
>>>>>>>> On Tue, Nov 6, 2012 at 4:15 PM, Dave Massey <dave at optionsdsl.ca>wrote:
>>>>>>>>
>>>>>>>>> Yea I just got told that from Voxcentral as well, and I have never
>>>>>>>>> seen that IP before.
>>>>>>>>> Its something on my end.  I dont know what though.  I did an
>>>>>>>>> apt-get update and upgrade this morning.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2012-11-06, at 7:12 PM, Skyler <skchopperguy at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Contact: <
>>>>>>>>> sip:10.1.1.10;alias=24.102.50.52~5060~1;line=sr-N6IAzEsh3wy1oSeyMBP7M.yLOBjAOBjLzBjAWBy*
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> This looks to be the reason, most likely. Not sure why that would
>>>>>>>>> be happening though.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Skyler
>>>>>>>>>
>>>>>>>>> On Tue, Nov 6, 2012 at 3:30 PM, Dave Massey <dave at optionsdsl.ca>wrote:
>>>>>>>>>
>>>>>>>>>> I attached a trace from dialing to when the call drops.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2012-11-06, at 3:47 PM, Andrew Pogrebennyk <
>>>>>>>>>> apogrebennyk at sipwise.com> wrote:
>>>>>>>>>>
>>>>>>>>>> > Dave,
>>>>>>>>>> >
>>>>>>>>>> > On 11/06/2012 03:55 PM, Dave Massey wrote:
>>>>>>>>>> >> _BUT_ --  Now I have the same problem with another peer,
>>>>>>>>>> Voxcentral drops calls after 20-25 seconds.  and I get SIP requests sent to
>>>>>>>>>> an IP that I have no idea where it comes from.
>>>>>>>>>> >>
>>>>>>>>>> >> Its sending ACK messages to a 10.1.1.10 IP that does not route
>>>>>>>>>> on my network and I assume this is why the call is dropping.
>>>>>>>>>> >> This peer had no issues 2 weeks ago.  :(
>>>>>>>>>> >
>>>>>>>>>> > We would need to see the 200 OK message from that peer to be
>>>>>>>>>> able to
>>>>>>>>>> > point out source of the problem or complete trace from the
>>>>>>>>>> INVITE to ACK
>>>>>>>>>> >
>>>>>>>>>> > 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/20121106/97a53515/attachment-0001.html>