Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.12
    • Fix Version/s: None
    • Component/s: mod_sofia
    • Security Level: public
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 7 wheezy
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      732b6e75fe0e940ba1f6ce08835bea0c0ac79186
    • GIT Master Revision hash::
      yes

      Description

      A calls B

      A pust B on hold
      A --> sendonly --> B
                              (Fail)
      A <-- BYE -- B
      A --> 200 OK --> B
      1. 20170102T084323Z-bt.txt
        88 kB
        Stefano Bertuola
      2. FreeSWITCH_master_20170103.log
        86 kB
        Stefano Bertuola
      3. FS_HOLD_Call_hanging.log
        85 kB
        Stefano Bertuola
      4. FS_HOLD_nok_call_hanging.log
        15 kB
        Stefano Bertuola

        Activity

        Hide
        mikej Mike Jerris added a comment -
        this seems to be a trace from the middle of a call. Can you please give a complete description on how to reproduce this issue and confirm you have tested this with latest master code.
        Show
        mikej Mike Jerris added a comment - this seems to be a trace from the middle of a call. Can you please give a complete description on how to reproduce this issue and confirm you have tested this with latest master code.
        Hide
        brian Brian West added a comment -
        Also the hash you outline is from Nov. 5th, This may already be fixed.
        Show
        brian Brian West added a comment - Also the hash you outline is from Nov. 5th, This may already be fixed.
        Hide
        brian Brian West added a comment -
        Please collect a log from START to finish, do not edit the log, then make sure sip trace is on like you have here, then you can get a gcore of the process and attach a backtrace.

        https://freeswitch.org/confluence/display/FREESWITCH/Debugging#Debugging-gcore

        Attach the log and the backtrace to this JIRA, Along with network topology, clients used in this test and a more detailed description of the steps you're taking to accomplish this.

        Thanks,
        /b
        Show
        brian Brian West added a comment - Please collect a log from START to finish, do not edit the log, then make sure sip trace is on like you have here, then you can get a gcore of the process and attach a backtrace. https://freeswitch.org/confluence/display/FREESWITCH/Debugging#Debugging-gcore Attach the log and the backtrace to this JIRA, Along with network topology, clients used in this test and a more detailed description of the steps you're taking to accomplish this. Thanks, /b
        Hide
        sbertuola Stefano Bertuola added a comment -
        Hi.

        I reproduced the problem with latest available to be installed as package: 1.6.13~21~e755b43.

        The configuration is the basic one, with just

           <param name="proxy-hold" value="true"/>

        added in

           /etc/freeswitch/sip_profiles/internal.xml

        Here the scenario:

        1. Two SIP clients registered as `1000` and `1001`
        2. A calls B
        3. A place the call on HOLD
        4. A releases the call while still in HOLD status

        Checking with "show calls", there is still a call in FreeSWITCH.

        Same behavior if B releases the call.

        Br. Stefano
        Show
        sbertuola Stefano Bertuola added a comment - Hi. I reproduced the problem with latest available to be installed as package: 1.6.13~21~e755b43. The configuration is the basic one, with just    <param name="proxy-hold" value="true"/> added in    /etc/freeswitch/sip_profiles/internal.xml Here the scenario: 1. Two SIP clients registered as `1000` and `1001` 2. A calls B 3. A place the call on HOLD 4. A releases the call while still in HOLD status Checking with "show calls", there is still a call in FreeSWITCH. Same behavior if B releases the call. Br. Stefano
        Hide
        mikej Mike Jerris added a comment -
        please confirm with latest master
        Show
        mikej Mike Jerris added a comment - please confirm with latest master
        Hide
        sbertuola Stefano Bertuola added a comment -
        Tested with FreeSwitch 1.9.0~1253~848730a-1~jessie+1.

        Same behaviour. Log attached.
        Show
        sbertuola Stefano Bertuola added a comment - Tested with FreeSwitch 1.9.0~1253~848730a-1~jessie+1. Same behaviour. Log attached.
        Hide
        brian Brian West added a comment -
        I do not believe you have proxy-hold turned on, If you do I believe I shouldn't be seeing this line 'Command Execute playback(local_stream://moh)&#39;, I'm trying to replicate this but I am having difficulty with Bria on my iPhone.

        /b
        Show
        brian Brian West added a comment - I do not believe you have proxy-hold turned on, If you do I believe I shouldn't be seeing this line 'Command Execute playback(local_ stream://moh)&#39;, I'm trying to replicate this but I am having difficulty with Bria on my iPhone. /b
        Hide
        sbertuola Stefano Bertuola added a comment -
        Without "proxy-hold" turned on, the INVITE message with 'a=sendonly' is not sent by other SIP client (just "digested" by FS). In my scenario, "proxy-hold" is used to inform the other side when a call is placed on HOLD.
        Show
        sbertuola Stefano Bertuola added a comment - Without "proxy-hold" turned on, the INVITE message with 'a=sendonly' is not sent by other SIP client (just "digested" by FS). In my scenario, "proxy-hold" is used to inform the other side when a call is placed on HOLD.
        Hide
        brian Brian West added a comment -
        I can not replicate this with our without proxy-hold, When you see the call in show channels, can you attempt to uuid_kill it and let me know what it says?

        /b
        Show
        brian Brian West added a comment - I can not replicate this with our without proxy-hold, When you see the call in show channels, can you attempt to uuid_kill it and let me know what it says? /b

          People

          • Assignee:
            mikej Mike Jerris
            Reporter:
            sbertuola Stefano Bertuola
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development