Hi Robert, I finally found the main issue with my deployment - MTU value on signalling interfaces. While main ifaces (eth0) was correctly set up by DHCP, signaling ifaces used default value (1500), which caused network issues and strange failures. I was able to make a call using Zoiper (Jitsi doesn't work for some reason).
Thank you for help. On Wed, Apr 20, 2016 at 4:58 PM, Sergey Kolekonov <[email protected]> wrote: > Just an update. Looks like I hit this problem (MTU issue) [0]. > After disabling some encodings, I moved forward, but still no luck - I'm > getting 503. > > This is what I see in Sprout logs: > >> 20-04-2016 13:43:46.932 UTC Verbose pjsip: tcpc0x7f588c5c TCP transport >> 192.168.1.5:33632 is connected to 192.168.1.6:5058 >> 20-04-2016 13:43:50.003 UTC Verbose pjsip: tcpc0x7f588c5c TCP connection >> closed >> 20-04-2016 13:43:50.003 UTC Debug pjsip: tsx0x7f588c5c5 State changed >> from Calling to Terminated, event=TRANSPORT_ERROR >> 20-04-2016 13:43:50.003 UTC Debug basicproxy.cpp:213: tsx0x7f588c5c5548 - >> tu_on_tsx_state UAC, TSX_STATE TRANSPORT_ERROR state=Terminated > > > This seems to be a reason for 503 errors. > > [0] http://lists.jitsi.org/pipermail/users/2013-December/005742.html > > On Wed, Apr 20, 2016 at 2:11 PM, Sergey Kolekonov <[email protected] > > wrote: > >> Hi Robert, >> >> I've redeployed my environment and now I can see INVITE messages with >> appropriate User-Agent, but the error is still here. >> You can find a record at ./var/log/bono/bono_20160420T100000Z.txt line >> 14364 >> >> Can you please advice something? >> Thanks. >> >> On Tue, Apr 19, 2016 at 9:27 PM, Robert Day (projectclearwater.org) < >> [email protected]> wrote: >> >>> Hi Sergey, >>> >>> >>> >>> The Ralf logs shouldn’t cause call failures – Ralf is a component for >>> enabling offline billing (also known as Rf billing), and those logs just >>> indicate that you can’t connect to a Charging Collection Function at >>> example.com. >>> >>> >>> >>> I can’t see any INVITE messages with “User-Agent: Jitsi” in the Bono >>> logs you’ve sent, only REGISTER, SUBSCRIBE and OPTIONS messages. It’s worth >>> checking local network capture with Wireshark or a similar tool when you >>> make calls with Jitsi, in case it’s just sending messages to the wrong >>> place, or resolving example.com incorrectly, and reporting a 408 >>> timeout locally. >>> >>> >>> >>> Best, >>> >>> Rob >>> >>> >>> >>> >>> >>> *From:* Sergey Kolekonov [mailto:[email protected]] >>> *Sent:* 19 April 2016 13:46 >>> >>> *To:* Robert Day (projectclearwater.org) <[email protected]> >>> *Cc:* [email protected] >>> *Subject:* Re: [Project Clearwater] [Clearwater] Sprout routing problem >>> >>> >>> >>> Robert, >>> >>> >>> >>> Adding alias_list helped. I also added scscf.sprout.example.com to DNS >>> as it wasn't here and caused failures. >>> >>> After these steps some live tests started to pass (Call Barring, for >>> example). But I'm still unable to make a call using real clients, >>> >>> as there're some 408 errors. Ralf logs also look suspicious: >>> >>> 19-04-2016 12:23:23.508 UTC Error diameterstack.cpp:293: Routing error: >>> 'No remaining suitable candidate to route the message to' for message with >>> Command-Code 271, Destination-Host and Destination-Realm example.com >>> >>> >>> >>> I've attached full logs of Ralf, Sprout and Bono. >>> >>> >>> >>> Thanks for help! >>> >>> >>> >>> On Tue, Apr 19, 2016 at 12:20 AM, Robert Day (projectclearwater.org) < >>> [email protected]> wrote: >>> >>> Hi Sergey, >>> >>> >>> >>> Can you try adding ‘alias_list=”sprout.example.com”` to >>> /etc/clearwater/shared_config and running “sudo service sprout stop” to >>> restart Sprout? That’s the domain name in the Route header of that >>> REGISTER, and adding that will make sure that it’s recognised as local >>> (which might not be happening in this case, and so the REGISTER isn’t being >>> processed properly). >>> >>> >>> >>> If that doesn’t help, can you send across the full Sprout log – for >>> example, by attaching it to an email (compressing it if it’s large)? That >>> will help me see everything that’s going on with the REGISTER, from the >>> point it enters the system onwards, and should also help me see the initial >>> configuration of the system (there are some logs starting with “Local host >>> aliases:” which will be useful for figuring this out) >>> >>> >>> >>> Best, >>> >>> Rob >>> >>> >>> >>> *From:* Sergey Kolekonov [mailto:[email protected]] >>> *Sent:* 18 April 2016 17:05 >>> *To:* Robert Day (projectclearwater.org) <[email protected]> >>> *Cc:* [email protected] >>> *Subject:* Re: [Project Clearwater] [Clearwater] Sprout routing problem >>> >>> >>> >>> Hi Robert, >>> >>> >>> >>> Thanks a lot for the fast response. >>> >>> This solved my problem, but I ran into another [0]. >>> >>> Now Sprout can not get subscriber data. The problem seems to be on >>> Homestead side [1]: >>> >>> looks like it receives a request without necessary fields. >>> >>> >>> >>> >>> >>> [0] http://paste.openstack.org/show/494445/ >>> >>> [1] http://paste.openstack.org/show/494449/ >>> >>> >>> >>> On Mon, Apr 18, 2016 at 5:22 PM, Robert Day (projectclearwater.org) < >>> [email protected]> wrote: >>> >>> Hi Sergey, >>> >>> >>> >>> From the log you provided, it looks like the REGISTER is being processed >>> by the BGCF (which routes calls outside the deployment), not the S-CSCF >>> (which processes registrations). We fixed an issue recently where the BGCF >>> and S-CSCF were both on port 5054 and so sometimes requests would go to the >>> wrong one ( >>> https://github.com/Metaswitch/sprout/commit/efd13e91a3e2a16d92b159aa9ec73faf25257935#diff-75af8e842ec03e21817a448de6bdf026R208 >>> ). >>> >>> >>> >>> Could you try setting “bgcf=0” (to disable the BGCF) in >>> /etc/clearwater/shared_config, and running “sudo service sprout stop” to >>> restart Sprout? Hopefully that will resolve your issue. >>> >>> >>> >>> By the way, you’re not currently subscribed to the mailing list, which >>> means your posts have to be approved by an administrator before anyone sees >>> them – you can sign up at >>> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org >>> and avoid that step. >>> >>> >>> >>> Best, >>> >>> Rob >>> >>> >>> >>> >>> >>> *From:* Clearwater [mailto: >>> [email protected]] *On Behalf Of *Sergey >>> Kolekonov >>> *Sent:* 18 April 2016 14:12 >>> *To:* [email protected] >>> *Subject:* [Project Clearwater] [Clearwater] Sprout routing problem >>> >>> >>> >>> Hello, >>> >>> >>> >>> I need some help with Sprout issue. >>> >>> I've deployed Clearwater using clearwater-heat [0] on top of OpenStack >>> Mitaka. >>> >>> >>> >>> So the problem is that I'm unable to register/make a call. >>> >>> After some investigations I found the following logs from Sprout [1]. >>> >>> In short, it answers SIP/2.0 404 No route to target when a client tries >>> to register. >>> >>> Results are equal when I use both the real client (Jitsi) >>> and clearwater-live-test [2]. >>> >>> >>> >>> Could you please help to understand what can be wrong? >>> >>> >>> >>> Thank you. >>> >>> >>> >>> [0] https://github.com/Metaswitch/clearwater-heat >>> >>> [1] http://paste.openstack.org/show/494412/ >>> >>> [2] https://github.com/Metaswitch/clearwater-live-test >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Sergey Kolekonov >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Sergey Kolekonov >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Sergey Kolekonov >>> >> >> >> >> -- >> Regards, >> Sergey Kolekonov >> > > > > -- > Regards, > Sergey Kolekonov > -- Regards, Sergey Kolekonov
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
