[asterisk-dev] "chan_sip: username mismatch" with TCP/TLS

[Stephane Chazelas]

Hello,

we've got an asterisk deployment on two offices. A "main"
server A in the main office, with

- a number of desk phone extensions (SIP on UDP, type=friend)
- a few roaming extensions (people on the go or in the office(s))
  using SIP+TLS with soft phones on their laptop (type=friend,
  host=dynamic)
- a SIP trunk with "type=peer host=dynamic nat=yes" on TLS
  between that main office and the other small office asterisk
  server B (which itself only has a few desk phone extensions
  registered with it)

B is behind NAT with a dynamic external IP address.

Now, everything goes well until the roaming extensions come to
visit the small office.

What happens then is that when the roaming extensions connect to
A, they show up as coming from the same IP address (though
different TCP source port) as the inter-office SIP peer.

Now, inter-office calls from B to A don't work anymore because,
when trying to match peers, A picks one of the roaming
extensions and one can see:

chan_sip.c: username mismatch, have <roaming1>, digest has <inter-office>

Looking at the source code, in peer_ipcmp_cb, one can read:
"\note Connections coming in over TCP or TLS should never be
matched by port"

And indeed, the code doesn't consider the port when trying to
find a peer.

So, if I understand correctly, that means we can't have more
than one TCP or TLS peer behind one IP address.

I've looked at the jira and svn history and found:
https://reviewboard.asterisk.org/r/354/
https://reviewboard.asterisk.org/r/236/

but that doesn't really explain why we can't use the TCP source
port. I've looked at the "sip show peer" output for all the
peers and the source port is correct.

As a workaround, I did those changes:

on the inter-office trunk definition on B:

fromuser=inter-office
sendrpid=yes

And on A

type=friend # (changed from peer)
trustrpid=yes

And that seems to do the trick, but it seems to me that I should
not have to do that.

https://reviewboard.asterisk.org/r/236/ seems to imply the job
is not finished, and that matching by IP  only is not the correct
solution to the problem.

-- 
Stephane