[OpenSIPS-Users] OpenSIPS 'ignoring' incoming '200 OKs' in the middle of a call

[Bogdan-Andrei Iancu]

Been there, got myself burned by this issue :D....

And I'm glad it helped you.

Regards,

Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
   http://www.opensips.org/events/Summit-2017Amsterdam.html

On 04/05/2017 10:05 PM, Jock McKechnie wrote:
> Sweet mother Macree, that's it!
>
> This one has been driving me up the wall for several _weeks_ and it
> never occurred to me to do a tcpdump of it because... I could see it
> fine in an ngrep.
>
> Thank you very much, Bogdan, I can't tell you how grateful I am for the hint.
>
>   - JP
>
> On Tue, Apr 4, 2017 at 6:34 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>> Hello Jock,
>>
>> According to the "Bad" debug output, OpenSIPS does not receive the 200 OK
>> reply at all. As you can see, starting with line 52, the incoming 100 Trying
>> is handled by process 24205, up to line 94 (time 08:41:53). AFter that
>> silence, nothing is received until 08:42:25 when a BYE is received.
>>
>> Maybe the 200 OK are discarded by OS (in terms of not be delivered to the
>> application level) as the UDP packet is too large and fragmented (and some
>> fragments are missing) ?? have you checked with a pcap to see if the 200 OK
>> is fragmented ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>>    OpenSIPS Founder and Developer
>>    http://www.opensips-solutions.com
>>
>> OpenSIPS Summit May 2017 Amsterdam
>>    http://www.opensips.org/events/Summit-2017Amsterdam.html
>>
>>
>> On 03/27/2017 05:56 PM, Jock McKechnie wrote:
>>> Greetings all;
>>>
>>> This is in continuation with a message I sent last week ('OpenSIPS
>>> debug logging SIP packets it deems non-local'). I've been beating my
>>> head against this problem for almost three weeks now and I'm really
>>> hoping someone might be able to offer some insight. Either the problem
>>> is really, really stupid - or it's seriously nasty.. and unfortunately
>>> I'm just not grokking this one.
>>>
>>> I have a "good" call flow and a "bad" call flow. The "good" one looks
>>> like the below:
>>> SIP Call Source (pjsip) -> LoadBalancer (OpenSIPS) -> Destination
>>> (FreeSWITCH)
>>>
>>> The bad one:
>>> SIP Call Source (pjsip) -> Proxy (OpenSIPS) -> LoadBalancer (OpenSIPS)
>>> -> Destination (FreeSWITCH)
>>>
>>> In both flows above the Source, LoadBalancer and Destination servers
>>> are the same machines, the only change is the addition of a Proxy
>>> between the Source and the LoadBalancer. In the former call flow
>>> everything works exactly as expected - the call originates, makes it
>>> through the LoadBalancer and gets passed onto the Destination, and all
>>> returning messages are routed as expected, the call comes up, the call
>>> tears down, life is good.
>>>
>>> When the middleman Proxy is added all of a sudden the LoadBalancer
>>> stops seeing 200 OKs from the Destination box. The LoadBalancer DOES
>>> see 100 Tryings, so it's not completely busted, but it ignores/doesn't
>>> receive/something the 200 OKs. And I just cannot figure out why it's
>>> decided it can't see these.
>>>
>>> I've compared both traps and signaling fields and besides an
>>> additional Via (the Proxy) and tag differences, they appear identical
>>> to my eyes. I've verified it's not local firewall (if it was the
>>> OpenSIPS shouldn't have seen the 100 Trying either, but I've also
>>> totally dropped the fw to no avail), the messaging is all following
>>> the same networking path, it's coming in on the correct interface on
>>> the LoadBalancer, the obvious in other words.
>>>
>>> I've simplified the LoadBalancer config to the point it's not
>>> "balancing" and is just sending to a specific FreeSWITCH box and the
>>> behaviour is consistent. I've tried this on three versions of OpenSIPS
>>> - 1.8.5, 1.8.8 and 1.11.6 and the behaviour is also consistent across
>>> versions.
>>>
>>> I have a bunch of traps and debug in the hopes someone might spot
>>> something. These are all coming from a 1.8.5 release of OpenSIPS, for
>>> what it's worth, although given it's across multiple versions
>>> (including LTS), I'm guessing the version does not have anything to do
>>> with it.
>>>
>>> The opensips config I'm using is:
>>> https://pastebin.com/LPNHtrVC
>>>
>>> The "Good" ngrep trace:
>>> https://pastebin.com/y8Way7Vq
>>>
>>> The "Good" level 9 debug output:
>>> https://pastebin.com/pwJvdafp
>>>
>>>
>>> The "Bad" ngrep trace where you can see it ignoring the 200 OKs:
>>> https://pastebin.com/9b322irb
>>>
>>> The "Bad" debug output:
>>> https://pastebin.com/MVdWDEgx
>>>
>>>
>>> I've replaced the IPs in our flow with bogus hostnames to (hopefully)
>>> illustrate things clearly - using hostnames, the call flow looks like:
>>> Source.Me.com -> (Proxy.Me.com) -> LoadBalancer.Me.com ->
>>> Destination.Me.com
>>>
>>> The destination number, 8005000300, is a test number on our platform -
>>> although it is (presumably) a real US number, we're not routing this
>>> out into the "Wild". The source is similarly a bogus number for
>>> testing purposes.
>>>
>>> If anyone has any suggestions, theories or insights, I cannot describe
>>> to you how grateful I would be to hear them. By necessity I have to
>>> add this additional Proxy into the call flow, so I -need- to make this
>>> work.
>>>
>>> As always, my thanks,
>>>    - Jock
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>