[Home]

Summary:ASTERISK-12991: peer matching issue when use type=peer
Reporter:pj (pj)Labels:
Date Opened:2008-10-30 08:28:45Date Closed:2008-12-12 12:17:11.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip-debug.txt
( 1) type-friend.txt
( 2) type-peer.txt
Description:When use type=peer in sip.conf, asterisk doesn't match existing peer and doesn't require invite authentication, as consequence call is then placed from context specified in [general] section in sip.conf (if allowguest=yes).
Workaround is to switch back to deprecated 'type=friend'
issue is caused probably from commit 152020



****** ADDITIONAL INFORMATION ******

sip-friend.txt is correct:
Found peer '333' for '333' from 10.0.0.100:2424

sip-peer.txt is incorrect:
No matching peer for '333' from '10.0.0.100:2424'
Comments:By: Leif Madsen (lmadsen) 2008-11-19 16:30:45.000-0600

I've been using type=peer all day on SVN-trunk-r157893 (and actually a few revisions before this as I was using this yesterday in testing bugs as well) and it is working fine. To me both peer and friend works again.

Can you retest on latest version of trunk to see if the issue has been resolved for you?

Thanks!

By: pj (pj) 2008-11-29 13:58:54.000-0600

issue still exist in Asterisk SVN-trunk-r159853
It seems, that it has some relationship with option 'match_auth_username=yes' in sip.conf, when I remove this option (or turn it off), peer matching seems to work normaly, even If I use 'type=peer'
With 'match_auth_username=yes' I must use 'type=friend' for peer matching to work correctly.

By: Joshua C. Colp (jcolp) 2008-12-10 08:57:11.000-0600

I have tested previous versions and the latest revision. I was able to reproduce this in the previous versions but not the latest. I believe this has already been solved by something else.

By: pj (pj) 2008-12-11 15:27:24.000-0600

it still doesn't work correctly, look into attached sip-debug.txt,
peer is correctly registered, but asterisk doesn't find it ...

[Dec 11 22:17:01] No matching peer for '324p' from '192.168.164.154:10319'
[Dec 11 22:17:01] Looking for 959 in from-guest (domain test.xx.xx)


sip show peer 324p
==>>  Context      : zamestnanci
==>>  Addr->IP     : 192.168.164.154 Port 10319

Asterisk SVN-trunk-r163094


By: Joshua C. Colp (jcolp) 2008-12-11 15:40:52.000-0600

What is your complete sip.conf minus passwords?

By: pj (pj) 2008-12-11 15:43:45.000-0600

[general]
context=from-guest                 ; Default context for incoming calls
srvlookup=yes                    ; Enable DNS SRV lookups on outbound calls
allowguest=yes
match_auth_username=yes
allowsubscribe=no
alwaysauthreject=yes
rtptimeout=15
rtpholdtimeout=180
disallow=all                    ; First disallow all codecs
allow=g729,gsm,ilbc,alaw
language=cz
canreinvite=no
nat=yes
realm=xxx
maxexpiry=400
minexpiry=200
defaultexpiry=350

[phone](!)
type=peer
host=dynamic
qualify=4000
qualifyfreq=20
nat=yes
canreinvite=no
disallow=all
allow=g729,gsm,ilbc
callcounter=yes
busylevel=1
allowsubscribe=yes
subscribecontext=linestates
context=zamestnanci


[324p](phone)
secret=xxx
callerid="Pavel Jezek" <324>

By: Olle Johansson (oej) 2008-12-12 09:53:59.000-0600

type=friend is not deprecated, that's a misunderstanding.

By: Leif Madsen (lmadsen) 2008-12-12 11:11:00.000-0600

Well with this configuration I can confirm that it does not match on the peer.

I tries to find peer 324p, which it can not find for some reason.

By: Digium Subversion (svnbot) 2008-12-12 12:17:10.000-0600

Repository: asterisk
Revision: 163629

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r163629 | file | 2008-12-12 12:17:10 -0600 (Fri, 12 Dec 2008) | 4 lines

When a device registers we need to unlink them (if linked) from the peers_by_ip container and link them back in since their IP address has changed. This would have manifested itself if you configured a new device (as type=peer), registered, and then tried to place a call from the device. Since the peer was not linked into the peers_by_ip container it would have never been found.
(closes issue ASTERISK-12991)
Reported by: pj

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=163629