[Spce-user] Call does not stop after hang-up

[Henk]

Hi Marcos,

That depends on the end-device.

You could try to enable a stun server on the client side (public server 
or Sipwise) or change protocol. Sometimes the router changes packets 
(SIP ALG), in that case I have good experiences by changing to TLS where 
the router cannot change packets anymore.

Which end device are you using?

Regards,

Henk


On 9-1-2019 14:23, Marcos Pytel wrote:
> Thank you Hank!
>
> What I can do to solve this?
>
> Regards,
> Marcos.
>
> -----Mensaje original-----
> De: Spce-user <spce-user-bounces at lists.sipwise.com> En nombre de Henk
> Enviado el: miércoles 9 de enero del 2019 10:10
> Para: spce-user at lists.sipwise.com
> Asunto: Re: [Spce-user] Call does not stop after hang-up
>
> Hi Marcos,
>
> I can open your capture using Wireshark 2.4.2, there is definitely an empty route header involved, see below
>
>           CSeq: 13484 BYE
>           Max-Forwards: 70
>           Route:
> <sip:10.7.255.253;r2=on;lr=on;ftag=0-73697030-34aa4c64;ngcplb=yes;nat=yes;socket=udp:10.7.255.253:5060>
>           Route:
> <sip:127.0.0.1;r2=on;lr=on;ftag=0-73697030-34aa4c64;ngcplb=yes;nat=yes;socket=udp:10.7.255.253:5060>
>           Route:
>           Route:
> <sip:127.0.0.1:5062;lr=on;ftag=0-73697030-34aa4c64;did=bbc.471;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=UnN2VC5nMxpOaH0/Di9DdxojagYTZHxTZyU3
>
> Regards,
>
> Henk
>
>
> On 9-1-2019 13:15, Marcos Pytel wrote:
>> Hi Adrew!
>>
>> I captured it with sngrep tool.
>> I'm using "WireShark Version 2.4.3 (v2.4.3-0-g368ba1ee37)" and I can open it without problems. I don't know what is wrong.
>>
>> Thank  you!
>> Marcos.
>>
>> -----Mensaje original-----
>> De: Andrew Pogrebennyk <apogrebennyk at sipwise.com> Enviado el:
>> miércoles 9 de enero del 2019 07:02
>> Para: Marcos Pytel <marcos.pytel at cotesma.com.ar>; 'Alex Lutay'
>> <alutay at sipwise.com>; spce-user at lists.sipwise.com
>> Asunto: Re: [Spce-user] Call does not stop after hang-up
>>
>> On 01/08/2019 08:18 PM, Marcos Pytel wrote:
>>> Jan  8 16:11:35 sipwise lb[4196]: ERROR: rr [loose.c:188]:
>>> find_next_route(): failed to parse Route body Jan  8 16:11:35 sipwise
>>> lb[4196]: ERROR: rr [loose.c:855]: after_loose(): failed to find next
>>> route Jan  8 16:13:14 sipwise lb[4211]: ERROR: <core>
>>> [core/udp_server.c:607]: udp_send():
>>> sendto(sock,0x7f64290db8f0,1089,0,10.7.255.250:5060,16): Invalid
>>> argument(22) Jan  8 16:13:14 sipwise lb[4211]: CRITICAL: <core>
>>> [core/udp_server.c:612]: udp_send(): invalid sendtoparameters#012one
>>> possible reason is the server is bound to localhost and#012attempts
>>> to send to the net Jan  8 16:13:38 sipwise lb[4213]: ERROR: <core>
>>> [core/forward.h:219]: msg_send_buffer(): udp_send failed
>> Hi Marcos,
>> yes, this is the problem and most probably it's caused by wrong route or contact headers from the end device.
>> Unfortunately, I still can't open the new pcap file you've provided ("The capture file appears to be damaged or corrupt.
>> (pcap: File has 823214080-byte packet, bigger than maximum of 262144)") How did you capture it? Did you press Ctrl+C to stop capture before copying the file from your machine?
>> Anyway, I would suggest to check the headers, especially in the 200 OK received from callee. There must be something wrong.
>>
>> Also, as a generic hint sometimes it helps activating topology stripping feature (set kamailio.lb.security.topos.enable: 'yes' in config.yml if you are on mr6.5.x release) because then we are stripping the rec-route headers. But it will not help with bad INVITE or 200 from the UA.
>>
>> Hope this helps,
>> Andrew
>>
>> _______________________________________________
>> 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
>
>