Summary: | ASTERISK-12991: peer matching issue when use type=peer | ||
Reporter: | pj (pj) | Labels: | |
Date Opened: | 2008-10-30 08:28:45 | Date Closed: | 2008-12-12 12:17:11.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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 |