[Spce-user] mr5.1.1 dropping calls

Henk henk at voipdigit.nl
Tue Mar 7 08:28:42 EST 2017


Hi Andrew,

Unfortunately the system is back to 5.01 now, which was more stable. I 
have the original full proxy log available, I will send this in private.
I did some capturing and found that the transaction matching fails when 
a re-invite is send (exact copy of original) after one minute due to an 
expiring 120 second SIP-timer (on the trunk-side).
If you need more information please let me know. I still have a test 
system with the same configuration, but it will take a lot of time to 
reproduce this.

Regards,

Henk

On 7-3-2017 13:08, Andrew Pogrebennyk wrote:
> Hello Henk,
> this can not cause the calls to be dropped. The other error you posted
> before about the transaction matching is more interesting, but we need
> to check it in context. Could you please share the network trace
> (preferably in pcap format) and kamailio-lb.log, kamailio-proxy.log with
> debug level 2:
> ngcp-kamctl lb fifo debug 2
> ngcp-kamctl proxy fifo debug 2
>
> BR,
> Andrew
>
> Henk wrote:
>> Hi,
>>
>> Something else I just found in the lb-logs when starting the loadbalancer:
>>
>> Mar  4 12:42:31 spce lb[28800]: WARNING: sl
>> [../../modules/tm/tm_load.h:148]: load_tm_api(): Cannot import load_tm
>> function from tm module
>> Mar  4 12:42:31 spce lb[28800]: WARNING: sl
>> [../../modules/tm/tm_load.h:148]: load_tm_api(): Cannot import load_tm
>> function from tm module
>>
>> Can this cause calls to be dropped?
>>
>> Regards,
>> Henk
>>
>> On 3-3-2017 11:38, Henk wrote:
>>> Hello,
>>>
>>> After upgrading to mr5.1.1 from 5.0.1 I have problems with calls being
>>> dropped after about 1 minute, especially calls to an asterisk box.
>>> A capture revealed that ACKs are missing. In the debug log I found
>>> lines about failed transaction matching, which may be relevant.
>>> The asterisk extension has default settings with only e164_to_ruri
>>> enabled.in subscriber preferences.
>>>
>>> Debug log:
>>> Mar  1 15:50:23 spce proxy[2768]: INFO: <script>: Relaying request,
>>> du='<null>' - R=sip:127.0.0.1:5080;prxroute=1
>>> ID=3d12a032-7931-1235-d8b5-0050569c3f3f UA='<null>'
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: tm [t_lookup.c:1312]:
>>> t_newtran(): DEBUG: t_newtran: msg id=59904 , global msg id=59903 , T
>>> on entrance=0xffffffffffffffff
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: tm [t_lookup.c:466]:
>>> t_lookup_request(): t_lookup_request: start searching: hash=6524, isACK=1
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: tm [t_lookup.c:424]:
>>> matching_3261(): DEBUG: RFC3261 transaction matching failed
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: tm [t_lookup.c:648]:
>>> t_lookup_request(): DEBUG: t_lookup_request: no transaction found
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: tm [t_funcs.c:285]:
>>> t_relay_to(): SER: forwarding ACK  statelessly
>>> Mar  1 15:50:23 spce proxy[2768]: DEBUG: <core> [forward.c:556]:
>>> forward_request(): Sending:#012ACK sip:127.0.0.1:5080;prxroute=1
>>> SIP/2.0#015#012Record-Route:
>>>
>>> Regards,
>>>
>>> Henk
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> https://lists.sipwise.com/listinfo/spce-user
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
>




More information about the Spce-user mailing list