Re: [OpenSIPS-Users] opensips and multiple rtpengine instances

2019-04-26 Thread Vitalii Aleksandrov
It happened that rtpengine with multiple rtp workers sometimes receives RTP packets ordered sequentially but forwards them a bit reordered introducing out-of-order frames. With one rtp worker everything works fine. The idea was to start a couple of single threaded rtpengines and loadbalance

Re: [OpenSIPS-Users] check_source_address()

2019-04-26 Thread Mark Farmer
Thanks Ben, that seems to be the case. I will update the list with the results. Mark. On Fri, 26 Apr 2019 at 14:09, Ben Newlin wrote: > It would cause the issue if they are sending all requests to that domain, > including sequential requests like re-invite, and ignoring the Contact > provided

Re: [OpenSIPS-Users] opensips and multiple rtpengine instances

2019-04-26 Thread Johan De Clercq
I remember that somebody from smartvox opened an issue on this (it was either Pete Kelly or John Quick). Pete,John do you recall ? Op vr 26 apr. 2019 om 15:15 schreef Vitalii Aleksandrov < vitalik.v...@gmail.com>: > Hello opensips users, > > has anybody tried to configure opensips with

[OpenSIPS-Users] opensips and multiple rtpengine instances

2019-04-26 Thread Vitalii Aleksandrov
Hello opensips users, has anybody tried to configure opensips with multiple rtpengine sockets? Logically thinking offer/answer from initial INVITE/OK and from all in-dialog messages must go to the same instance and opensips can load balance only initial INVITEs. I briefly compared

Re: [OpenSIPS-Users] check_source_address()

2019-04-26 Thread Ben Newlin
It would cause the issue if they are sending all requests to that domain, including sequential requests like re-invite, and ignoring the Contact provided in the 200 OK. That is not correct according to RFC 3261, but I have seen many carriers do this. Ben Newlin From: Users on behalf of Mark

Re: [OpenSIPS-Users] check_source_address()

2019-04-26 Thread Mark Farmer
Thank you, that makes sense now. I will keep that in mind for the future. In the meantime I have raised a query with our provider. Additionally, I realised this morning that at our request, our provider is sending calls to us via a domain name instead of an IP. Would that likely cause the issue