Hi Rashid, So a correct MTU value for instances' interfaces depends on network segmentation that you use in your OpenStack cloud. In Mitaka all calculations are performed by Neutron, so you just need to check the MTU value on an interface which is set up by DHCP (eth0). In my case, as I use vxlan segmentation and default MTU on physical interfaces (1500), on eth0 I have 1450. If you deployed Clearwater using Heat templates, then you need to execute the following command on all nodes which have the second (signaling) interface (for MTU=1450):
sudo ip net e signaling ifconfig set eth1 mtu 1450 And that's it. On Wed, Apr 20, 2016 at 11:51 PM, Rashid <[email protected]> wrote: > Hi Sergey, > > Could you please share how you solved this problem as I am currently > facing the same issue. > > Regards, > > Rashid > > On 20 Apr 2016, at 19:11, Sergey Kolekonov <[email protected]> > wrote: > > 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 > > -- Regards, Sergey Kolekonov
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
