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

invalid contact header witn private ip on reinvite without sdp

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8
    • Component/s: mod_sofia
    • Security Level: public
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      c4775d8
    • GIT Master Revision hash::
      9c8d9cf120dcba7f5fe4ec65bf46c49ac79c8f19
    • Target Version:
      1.8

      Description

      when behind nat, receiving a re-invite without sdp fs puts in the contact header the private ip instead the configured external ip in the 200 OK sent to remote endpoint, and it makes the call hangup with ack timeout because the remote endpoint send the ack to the private ip set in the contact header.

      in the sofia profile i've set ext-sip-ip:autonat:212.30.92.117 and ext-rtp-ip:autonat:212.30.92.117 and the call setup is done correctly until the re-invite without sdp.

      attach tshark log for the call where:

      212.30.92.117 -> fs public ip behind nat
      192.168.254.10 -> fs private ip
      206.62.135.43 -> remote endpoint public ip
      172.26.0.101 -> remote endpoint private ip

      1. freeswitch.log
        83 kB
        Antonio
      2. freeswitch.xml
        11 kB
        Antonio
      3. invite_auth_reinvite_nosdp.xml
        4 kB
        Antonio
      4. tshark_calllog_fail_ack_timeout.txt
        65 kB
        Antonio

        Activity

        Hide
        mikej Mike Jerris added a comment -
        but the same scenario w/ re-invite with an sdp works right?
        Show
        mikej Mike Jerris added a comment - but the same scenario w/ re-invite with an sdp works right?
        Hide
        antonio Antonio added a comment - - edited
        not tested... this re-invite is trigger by a transfer on the remote machine... i can only test it on monday.. sorry :(

        you can see that in the first 200 OK we have:
        Contact: <sip:commsmundi@212.30.92.117:5060>

        on the re-invite:
        Contact: <sip:commsmundi@192.168.254.10:5060>

        it could be some nat issue, since the contact set by the remote endpoint is a private ip.. but in the first invite is the same... and in the nat acl i have:

        sofia:
        <param name="apply-nat-acl" value="notlocalnet"/>

        acl:
        <list name="notlocalnet" default="allow">
        <node type="deny" cidr="192.168.254.0/24"/>
        <node type="deny" cidr="192.168.255.0/24"/>
        </list>

        Show
        antonio Antonio added a comment - - edited not tested... this re-invite is trigger by a transfer on the remote machine... i can only test it on monday.. sorry :( you can see that in the first 200 OK we have: Contact: <sip: commsmundi@212.30.92.117 :5060> on the re-invite: Contact: <sip: commsmundi@192.168.254.10 :5060> it could be some nat issue, since the contact set by the remote endpoint is a private ip.. but in the first invite is the same... and in the nat acl i have: sofia: <param name="apply-nat-acl" value="notlocalnet"/> acl: <list name="notlocalnet" default="allow"> <node type="deny" cidr="192.168.254.0/24"/> <node type="deny" cidr="192.168.255.0/24"/> </list>
        Hide
        mikej Mike Jerris added a comment -
        can you attach a full freeswitch debug here with sip trace turned on
        Show
        mikej Mike Jerris added a comment - can you attach a full freeswitch debug here with sip trace turned on
        Hide
        brian Brian West added a comment -
        Please get the FreeSWITCH log with sip trace enabled and sofia log level turned up to 9.

        /b
        Show
        brian Brian West added a comment - Please get the FreeSWITCH log with sip trace enabled and sofia log level turned up to 9. /b
        Hide
        antonio Antonio added a comment -
        yes, i will do it, unfortunately until monday i cannot test it with this device. i will try to put a sipp to it :)
        Show
        antonio Antonio added a comment - yes, i will do it, unfortunately until monday i cannot test it with this device. i will try to put a sipp to it :)
        Hide
        antonio Antonio added a comment - - edited
        Reproduced, check attached log.

        Also attached the sipp scenario and conf to reproduce.

        If in the configuration i remove the autonat prefix from ext-sip-ip the contact is set to the correct public ip.

        There is some bug when setting the contact ip from the profile url when receiving a invite without sdp.
        Show
        antonio Antonio added a comment - - edited Reproduced, check attached log. Also attached the sipp scenario and conf to reproduce. If in the configuration i remove the autonat prefix from ext-sip-ip the contact is set to the correct public ip. There is some bug when setting the contact ip from the profile url when receiving a invite without sdp.
        Hide
        antonio Antonio added a comment -
        i put the changes in production and is working nice for the past days.

        thanks
        Show
        antonio Antonio added a comment - i put the changes in production and is working nice for the past days. thanks

          People

          • Assignee:
            mikej Mike Jerris
            Reporter:
            antonio Antonio
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development