Menu

freeze after closing RTP stream

Help
tipichris
2005-11-11
2013-05-28
  • tipichris

    tipichris - 2005-11-11

    I have just installed siproxd 5.11 and libosip2-2.2.1 on an old FreeBSD box that I use as a NAT router.

    Clients in the NATed subnet can now succesfully register and receive an incoming call. But when the call is hung on the remote client, the local client does not see the hangup. Debug output ceases with

    ----------------------------------------------------------
    21:18:30 rtpproxy_relay.c:681 rtp_relay_stop_fwd: stopping RTP proxy stream for: 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14 (incoming)
    21:18:30 sip_utils.c:362 comparing callid - matched: 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14 <-> 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14
    21:18:30 sip_utils.c:362 comparing callid - matched: 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14 <-> 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14
    21:18:30 rtpproxy_relay.c:726 closed socket 10 for RTP stream 6000e1836fefa8af11ba1cc171dc0c9f:80.95.48.14 == 6000e1836fefa8af11ba1cc171dc0c9f:80.95.48.14  (idx=1) sts=0
    21:18:30 rtpproxy_relay.c:681 rtp_relay_stop_fwd: stopping RTP proxy stream for: 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14 (outgoing)
    21:18:30 sip_utils.c:362 comparing callid - matched: 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14 <-> 6000e1836fefa8af11ba1cc171dc0c9f@80.95.48.14
    21:18:30 rtpproxy_relay.c:726 closed socket 9 for RTP stream 6000e1836fefa8af11ba1cc171dc0c9f:80.95.48.14 == 6000e1836fefa8af11ba1cc171dc0c9f:80.95.48.14  (idx=0) sts=0

    ----------------------------------------------------------

    netstat reports the Recv-Q on 5060 rising and further registration attempts by the UA timeout. siproxd does not respond to a kill -TERM and has to be finished off with a kill -KILL

    Any suggestions?

     
    • tipichris

      tipichris - 2005-11-11

      Oh, and as soon as the remote UA hangs up, siproxd's CPU usage goes through the roof.

       
      • Thomas Ries

        Thomas Ries - 2005-11-13

        I've never had a similar problem report before.

        Have you tried the latest snapshot? Same error?

        Can you provide more info:
        - complete debug log file including SIP dialogs,
        - GDB stack trace for the thread consuming all the CPU time

        /Thomas

         

Log in to post a comment.