Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: mod_sofia
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Ubuntu
    • Distribution Version:
      Ubuntu 10.04 LTS
    • lsb_release:
      Hide
      No LSB modules are available.
      Distributor ID: Ubuntu
      Description: Ubuntu 10.04.2 LTS
      Release: 10.04
      Codename: lucid
      Show
      No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 10.04.2 LTS Release: 10.04 Codename: lucid
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      ae069dcca74759640094bec63ff3ccb9e66a0943
    • GIT Master Revision hash::
      65631ed36b04566654410b7b22fc5cf8aa48a566

      Description

      From time to time, we see Zoiper 3.6.25251 r25476 sending burst of SUBSCRIBEs (Event: message-summary, CSeq=1, different Call-IDs and same sub host).
      It's similar to FS-5582 and FS-6223 but it doesn't seem to be triggered by expires = 0 or other NOTIFY messages. It happens right after an established new TCP connection: SYN-SYN/ACK-ACK and then burst of SUBSCRIBEs.
      This ends with internal queues (EVENT_DISPATCH_QUEUE, vm globals.event_queue etc) full of messages.

      For what we've understood each SUBSCRIBE fires a MESSAGE_QUERY for each UA subscribed to this host and not only for this particular new subscription. It's using already existing subscriptions.

      (from sofia_presence_handle_sip_i_subscribe() message-summary else-if)

      select proto,sip_user,'%q',sub_to_user,sub_to_host,event,contact,call_id,full_from,
      full_via,expires,user_agent,accept,profile_name,network_ip
      from sip_subscriptions
      where hostname='%q'
      and profile_name='%q'
      and event='message-summary'
      and sub_to_user='%q' "
      and (sip_host='%q' or presence_hosts like '%%%q%%')

      What would be wrong if we further restrict this query by adding the call_id to the where clause (and call_id='%q')?
      In this way we'll only generate one MESSAGE_QUERY for the current SUBSCRIBE, only one MESSAGE_WAITING and one NOTIFY for each subscribed UA.

      Basically what we mean is:

      diff --git a/src/mod/endpoints/mod_sofia/sofia_presence.c b/src/mod/endpoints/mod_sofia/sofia_presence.c
      index a7e4e6f..2d68385 100644
      --- a/src/mod/endpoints/mod_sofia/sofia_presence.c
      +++ b/src/mod/endpoints/mod_sofia/sofia_presence.c
      @@ -4268,9 +4268,9 @@ void sofia_presence_handle_sip_i_subscribe(int status,
                                                                        "full_via,expires,user_agent,accept,profile_name,network_ip"
                                                                        " from sip_subscriptions where hostname='%q' and profile_name='%q' and "
                                                                        "event='message-summary' and sub_to_user='%q' "
      - "and (sip_host='%q' or presence_hosts like '%%%q%%')",
      + "and (sip_host='%q' or presence_hosts like '%%%q%%') and call_id='%q'",
                                                                        to_host, mod_sofia_globals.hostname, profile->name,
      - to_user, to_host, to_host))) {
      + to_user, to_host, to_host, call_id))) {

                              if (mod_sofia_globals.debug_presence > 0) {
                                      switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,

      This happens in our production boxes running an older revision. We tried it in a lab environment, latest rev, using sipp and it seems to behave the same way. We used sipp cause we couldn't make Zoiper fail the same way.

      Thanks

        Attachments

          Activity

            People

            • Assignee:
              anthm Anthony Minessale II
              Reporter:
              rbarroetavena ric
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: