[asterisk-users] "username mismatch, have <x>, digest has <y>"

[Benny Amorsen]

I have two Asterisks connected using SIP. One is acting as a SIP
"server", the other as a SIP "client". This almost works; but calls
from 50607795 are rejected with this error:

check_auth: username mismatch, have <50607796>, digest has <50607795>

On the "client" I have these accounts configured in sip.conf:

 register => 50607795:test at 10.10.33.228/50607795
 register => 50607796:test2 at 10.10.33.228/50607796

[50607795]
 accountcode=mobiltest
 defaultuser=50607795
 type=peer
 host=10.10.33.228
 canreinvite=no
 insecure=port,invite
 context=from-inside
 secret=test
 fromuser=50607795
 trustrpid=yes
 sendrpid=yes

[50607796]
 accountcode=mobiltest
 defaultuser=50607796
 type=peer
 host=10.10.33.228
 canreinvite=no
 insecure=port,invite
 context=from-inside
 secret=test2
 fromuser=50607796
 trustrpid=yes
 sendrpid=yes


On the "server", these are configured:

[50607795]
 callgroup=
 pickupgroup=
 callerid=test <50607795>
 canreinvite=yes
 context=do_dial
 mailbox=
 secret=test
 type=peer
 disallow=all
 allow=alaw
 allow=ulaw
 host=dynamic
 call-limit=100
 dtmfmode=rfc2833

[50607796]
 callgroup=
 pickupgroup=
 callerid=test2 <50607796>
 canreinvite=yes
 context=do_dial
 mailbox=
 secret=test2
 type=peer
 disallow=all
 allow=alaw
 allow=ulaw
 host=dynamic
 call-limit=100
 dtmfmode=rfc2833

Both servers are running Asterisk 1.6.0.1.

The problem seems to be that the "client" registers twice using the
same IP address and port. The "server" then gets confused and doesn't
try both sets of credentials -- only the last one mentioned in
sip.conf. If I add insecure=invite, then the call is allowed, but the
"server" then believes that it was 50607796 which made the call, when
in fact it was 50607795. Not so clever.

I can see two ways out of this problem:

a) Get the "client" Asterisk to use a unique port number for each
registration to a specific server. This seems like a lot of work for
little gain, because devices like Snom M3 exhibit the exact same
behaviour, so they would remain broken.

b) Make the "server" Asterisk try to match all the "clients" with the
specific IP-address and port, not just one. This seems like the
correct solution.


/Benny