Peer Matching in Asterisk using chan_sip

Asterisk Asterisk SIP
1

Hi Group

Yes this has been addressed before however its not quite working the way I expected.
Im using Asterisk 13.18.5 but have not tested on any other version.
I have multiple accounts being registered from a Yealink phone with only one with a line appearance (Primary line) which is configured as the default account.
Occasionally on outgoing calls, Asterisk matches an account other than the primary account which I can confirm with a SIP debug.

I have tried type=user and type=friend but it still continues to occasionally not match the From: address.

Here is my sip.conf:
[general]
language=en_AU
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
allow=g722
qualify=yes
qualifyfreq=30
insecure=port,invite
nat=no
localnet=192.168.0.0/255.255.0.0
localnet=10.0.0.0/255.0.0.0
localnet=172.16.0.0/12
localnet=169.254.0.0/255.255.0.0
videosupport=no
dtmfmode=auto
allowguest=no
realm=IBC
notifyringing=yes
notifyhold=yes
useragent=IBCCM
sdpsession=IBCCM
srvlookup=no
autocreatepeer=yes
context=DialPlan99
session-timers=refuse
maxexpiry=1800
register_retry_403=yes
trustrpid=yes
sendrpid = pai
tos_sip=cs3
tos_audio=ef
tos_video=af41
tos_text=af41
callcounter=yes
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/mnt/kd/ssl/sip-tls/keys/server.crt
tlsprivatekey=/mnt/kd/ssl/sip-tls/keys/server.key
tlscipher=ALL
tlsclientmethod=tlsv1
callevents=yes
deny=0.0.0.0/0.0.0.0
permit=10.0.0.0/255.0.0.0
permit=172.16.0.0/255.240.0.0
permit=192.168.0.0/255.255.0.0
contactdeny=0.0.0.0/0.0.0.0
contactpermit=10.0.0.0/255.0.0.0
contactpermit=172.16.0.0/255.240.0.0
contactpermit=192.168.0.0/255.255.0.0
alwaysauthreject=yes

[extension_default](!)
directmedia=yes
disallow=all
allow=alaw
allow=ulaw
type=peer
host=dynamic
context=DialPlan1
namedcallgroup=default
namedpickupgroup=default
call-limit = 10
deny=0.0.0.0/0.0.0.0
permit=10.0.0.0/255.0.0.0
permit=172.16.0.0/255.240.0.0
permit=192.168.0.0/255.255.0.0
contactdeny=0.0.0.0/0.0.0.0
contactpermit=10.0.0.0/255.0.0.0
contactpermit=172.16.0.0/255.240.0.0
contactpermit=192.168.0.0/255.255.0.0

[1402](extension_default)
type=peer
secret=#password#

[virtualuser11402](extension_default)
type=user
secret=#password#

[virtualuser21402](extension_default)
type=user
secret=#password#

I know that I need to match on username as Yealink phones do not change the source port for each account as they used to previously.
Am I missing something?

Regards
Mike

2

Anyone? This problem is extremely annoying.

Mike

3

SIP Debug:
<— SIP read from UDP:172.30.30.129:5060 —>
INVITE sip:1404@172.30.30.1:5060 SIP/2.0
Via: SIP/2.0/UDP 172.30.30.129:5060;branch=z9hG4bK2367552560
From: sip:1402@172.30.30.1:5060;tag=3051722501
To: sip:1404@172.30.30.1:5060
Call-ID: 0_4132352449@172.30.30.129
CSeq: 2 INVITE
Contact: sip:1402@172.30.30.129:5060
Authorization: Digest username=“1402”, realm=“IBC”, nonce=“11db3dc2”, uri=“sip:1404@172.30.30.1:5060”, response=“14583fdfe59e5aa177aa16b372e52f97”, algorithm=MD5
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T46G 28.82.0.30
Allow-Events: talk,hold,conference,refer,check-sync
Supported: replaces
Content-Length: 237

v=0
o=- 20385 20385 IN IP4 172.30.30.129
s=SDP data
c=IN IP4 172.30.30.129
t=0 0
m=audio 16634 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
— (15 headers 12 lines) —
Sending to 172.30.30.129:5060 (no NAT)
Using INVITE request as basis request - 0_4132352449@172.30.30.129
Found peer ‘virtual11402’ for ‘1402’ from 172.30.30.129:5060
[Apr 19 08:55:58] WARNING[3599][C-00000026]: chan_sip.c:17236 check_auth: username mismatch, have , digest has <1402>
[Apr 19 08:55:58] NOTICE[3599][C-00000026]: chan_sip.c:26313 handle_request_invite: Failed to authenticate device <sip:1402@172.30.30.

Why is it not matching my user. Is this a bug?

Thanks
Mike

4

Darn I found the problem:

[1402](extension_default)
type=friend

It was matching the first peer on IP Address and ignoring the other user based matching :frowning:

1 Like