Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-4102

invite to gateway without registration goes to another wrong host

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: mod_sofia
    • Security Level: public
    • Labels:
      None
    • Environment:
      debian testing x86-64, builded from git 735d98710cb48f5ecdf5c01b05f212a47bc9fe9e (5 apr 2012)
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • uname:
      Linux server9 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux
    • Userland:
      GNU/Linux
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      735d98710cb48f5ecdf5c01b05f212a47bc9fe9e
    • GIT Master Revision hash::
      735d98710cb48f5ecdf5c01b05f212a47bc9fe9e
    • Target Version:
      1.9

      Description

      I have same issue with build from 18 feb 2012.
      Calls (invite) through gateway without registration goes to another host -

      gateway without registration:
      <include>
       <gateway name="mcm">
        <param name="username" value="none"/>
        <param name="password" value="none"/>
        <param name="realm" value="95.128.224.36"/>
        <param name="register" value="false"/>
       </gateway>
      </include>

      another gateway:
        <gateway name="79272361150">
         <param name="username" value="79272361150"/>
         <param name="realm" value="multifon.ru"/>
         <param name="password" value="DDDDDDDDD"/>
         <param name="expire-seconds" value="90"/>
         <param name="register" value="true"/>
         <param name="register-transport" value="udp"/>
         <param name="ping" value="20"/>
         <param name="stun-enabled" value="false"/>
        </gateway>

      listed in fs_cli -x 'sofia status':
                  external::mcm gateway sip:none@95.128.224.36 NOREG


      dialplan:
      <action application="bridge" data="{absolute_codec_string=G729}sofia/gateway/mcm/89050257199"/>


      problem:
      invite goes to another host 193.201.229.35 (ip addr of another gateway), not 95.128.224.36

      what i see in sip invite:
      - in route - wrong gateway
      Route: <sip:gw+79272361150@193.201.229.35:5060;transport=udp;lr>;gw=79272361150
      - and in contact - rigth gateway
      Contact: <sip:gw+mcm@149.126.23.150:5080;transport=udp;gw=mcm>

      full sip invite:

      Via: SIP/2.0/UDP 149.126.23.111:5080;rport;branch=z9hG4bK0pQ24743FZcgD
      Route: <sip:gw+79272361150@193.201.229.35:5060;transport=udp;lr>;gw=79272361150
      Max-Forwards: 69
      From: "Anton" <sip:none@95.128.224.36;transport=udp>;tag=cB34p87y8jHQN
      To: <sip:89050257111@95.128.224.36>
      Call-ID: 61ad2156-fe7a-122f-96a7-6cf0490bfc2c
      CSeq: 26738813 INVITE
      Contact: <sip:gw+mcm@149.126.23.111:5080;transport=udp;gw=mcm>
      User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-735d987 2012-04-05 08-18-55 +0000
      Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY
      Supported: timer, precondition, path, replaces
      Allow-Events: talk, hold, refer
      Content-Type: application/sdp
      Content-Disposition: session
      Content-Length: 206
      X-FS-Support: update_display,send_info
      Remote-Party-ID: "Anton" <sip:273@95.128.224.36>;party=calling;screen=yes;privacy=off
      1. example.xml
        0.6 kB
        Stanislav Zapolsky
      2. freeswitch.log
        114 kB
        Stanislav Zapolsky
      3. full_log.txt
        46 kB
        Anton F.
      4. full_log2.txt
        46 kB
        Anton F.
      5. INVITE.txt
        8 kB
        Anton F.
      6. OPTIONS.txt
        1 kB
        Anton F.
      7. sip.pcapng
        6 kB
        Stanislav Zapolsky
      8. sipp_scenario.xml
        1 kB
        Stanislav Zapolsky

        Issue Links

          Activity

          Hide
          autoadmin Auto Admin added a comment -
          Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours.
          If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue.

          Thanks,
            Jira Admin
          Show
          autoadmin Auto Admin added a comment - Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours. If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue. Thanks,   Jira Admin
          Hide
          autoadmin Auto Admin added a comment -
          Since there has been no change to the status of this issue, it is being closed for inactivity

          Thanks,
            Jira Admin
          Show
          autoadmin Auto Admin added a comment - Since there has been no change to the status of this issue, it is being closed for inactivity Thanks,   Jira Admin
          Hide
          tc Travis Cross added a comment -
          Tepidly reopening for evg who thinks he can show this is a bug.
          Show
          tc Travis Cross added a comment - Tepidly reopening for evg who thinks he can show this is a bug.
          Hide
          brian Brian West added a comment -
          Reopen if you have more details please.

          /b
          Show
          brian Brian West added a comment - Reopen if you have more details please. /b
          Hide
          stszap Stanislav Zapolsky added a comment - - edited
          Please reopen this issue.
          We are facing exactly the same problem right now and can easily reproduce this in test environment. Our setup:
          host 192.168.88.254 with FS (version "FreeSWITCH Version 1.7.0+git~20160620T155904Z~dc13f59ee8~64bit (git dc13f59 2016-06-20 15:59:04Z 64bit)" )
          host 192.168.88.233 with sipp
          We used default FS config with only etc/freeswitch/sip_profiles/external/example.xml file modified (file attached). sipp is imitating a registrar. It always replying 401 to first REGISTER and 200 to second. 200 response contains Service-Route header (sipp scenario attached).

          Steps to reproduce:
          1. start FS
          2. FS sends REGISTER message for "gate_service_route" gateway to sipp
          3. sipp replies 401
          4. FS sends second REGISTER with Authorization header
          5. enable debug
          console loglevel 7
          sofia loglevel all 9
          sofia profile external siptrace on
          6. I manualy start a call
          originate sofia/gateway/gate_noreg/0000000000 &echo()


          What happens:
          FS sends INVITE to host "193.201.229.35" but it is totally unrelated to "gate_noreg" gateway.

          What we expext to happen:
          FS sends INVITE to "example.com" as specified in its config

          I tried to dig in sofia-sip code and I think that nua_registration_by_aor() function from nua_register.c is strange. If it can't find nua_registration matching aor argument it simpy returns whatever nua_registration it sees first. In our particular test case while iterating through nua_registration list this function ignores nua_registration for "gate_noreg" because it's not ready and returns nua_registration for "gate_service_route" which contains nr_route parameter. The nr_route parameter is than used in nua_registration_add_contact_and_route() function which adds it to msg object as Route header.

          This is simplified part of backtrace while sending invite through gate_noreg:
          {code}
          nua_client_request_sendmsg() from nua_client.c
          nua_registration_add_contact_to_request() from nua_register.c
          nua_registration_for_request() from nua_register.c
          nua_registration_by_aor() from nua_register.c //here nua_registration object for wrong gateway is returned and later passed to nua_registration_add_contact_and_route()
          nua_registration_add_contact_and_route() from nua_register.c //here nr_route parameter from nua_registration is added to msg object as Route header
          {code}

          Maybe additional aor check is needed in nua_registration_add_contact_and_route() or somewhere else? Or maybe I completely misunderstood what this code does?

          Without Servie-Route header in response to REGISTER everything works fine.
          Show
          stszap Stanislav Zapolsky added a comment - - edited Please reopen this issue. We are facing exactly the same problem right now and can easily reproduce this in test environment. Our setup: host 192.168.88.254 with FS (version "FreeSWITCH Version 1.7.0+git~20160620T155904Z~dc13f59ee8~64bit (git dc13f59 2016-06-20 15:59:04Z 64bit)" ) host 192.168.88.233 with sipp We used default FS config with only etc/freeswitch/sip_profiles/external/example.xml file modified (file attached). sipp is imitating a registrar. It always replying 401 to first REGISTER and 200 to second. 200 response contains Service-Route header (sipp scenario attached). Steps to reproduce: 1. start FS 2. FS sends REGISTER message for "gate_service_route" gateway to sipp 3. sipp replies 401 4. FS sends second REGISTER with Authorization header 5. enable debug console loglevel 7 sofia loglevel all 9 sofia profile external siptrace on 6. I manualy start a call originate sofia/gateway/gate_noreg/0000000000 &echo() What happens: FS sends INVITE to host "193.201.229.35" but it is totally unrelated to "gate_noreg" gateway. What we expext to happen: FS sends INVITE to "example.com" as specified in its config I tried to dig in sofia-sip code and I think that nua_registration_by_aor() function from nua_register.c is strange. If it can't find nua_registration matching aor argument it simpy returns whatever nua_registration it sees first. In our particular test case while iterating through nua_registration list this function ignores nua_registration for "gate_noreg" because it's not ready and returns nua_registration for "gate_service_route" which contains nr_route parameter. The nr_route parameter is than used in nua_registration_add_contact_and_route() function which adds it to msg object as Route header. This is simplified part of backtrace while sending invite through gate_noreg: {code} nua_client_request_sendmsg() from nua_client.c nua_registration_add_contact_to_request() from nua_register.c nua_registration_for_request() from nua_register.c nua_registration_by_aor() from nua_register.c //here nua_registration object for wrong gateway is returned and later passed to nua_registration_add_contact_and_route() nua_registration_add_contact_and_route() from nua_register.c //here nr_route parameter from nua_registration is added to msg object as Route header {code} Maybe additional aor check is needed in nua_registration_add_contact_and_route() or somewhere else? Or maybe I completely misunderstood what this code does? Without Servie-Route header in response to REGISTER everything works fine.

            People

            • Assignee:
              anthm Anthony Minessale II
              Reporter:
              fr.butch Anton F.
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:

                Development