Summary: | ASTERISK-01714: Incoming calls from FWD no longer work since CVS HEAD 2004/05/24 | ||
Reporter: | oliver (oliver) | Labels: | |
Date Opened: | 2004-05-27 19:46:35 | Date Closed: | 2008-01-15 14:56:41.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) chan_sip.c.patch ( 1) chan_sip.c.patch | |
Description: | Since the CVS-update of 2004/05/24 in the HEAD-branch, incoming calls from FWD are no longer accepted, due to an authentication-error. Asterisk seems to always want authentication. I've tried setting "insecure=very" for FWD's entry, but that doesn't solve the problem. If I roll chan_sip back to a version from before the change on 2004/05/24, all is fine. ****** ADDITIONAL INFORMATION ****** Asterisk CVS-HEAD-05/28/04-01:31:28 Snippet from "sip.conf": [fwd.pulver.com] type=friend callerid="Free World Dialup" <> context=<context> username=<username> secret=<secret> fromdomain=fwd.pulver.com host=fwd.pulver.com nat=yes insecure=very canreinvite=no disallow=all allow=ulaw | ||
Comments: | By: Mark Spencer (markster) 2004-05-27 20:01:56 Are calls actually coming to you from fwd.pulver.com? By: kuj (kuj) 2004-05-27 20:21:10 Confirmed here as well. The changes in chan_sip.c (1.395) seem to be the culprit. Older versions work. Later ones will result in debug output like so: May 26 17:26:50 NOTICE[-1137075280]: Failed to authenticate user "xxxxxxxxxx" <sip:xxxxxxxxxx@yy.yy.yy.yy>;tag=zzzzzzzzzz The xxxxxxxxxx are the caller-id of the calling users, in my cases here. chan_sip checks inbound calls first against known users, then against the peers. If I defined all potential callers in their own [xxxxxxxxxxx] user section (sip.conf) and made them "insecure=very", the inbound calls *should* succeed. (Have only verified so far that in find_user the call is matched against the new user entry in sip.conf, using the old code) While that helps me call myself (as I know my various caller-id's), it's not a general fix :-) By: oliver (oliver) 2004-05-27 20:22:17 Hey Mark, They should be coming in from there, as all calls from FWD do end up in the proper specified context, which I think could only happen in this case when the host matches. Am I correct here? By: kuj (kuj) 2004-05-27 20:48:24 Confirmed with the new (1.401) chan_sip: inbound calls from unregistered callers fail with May 27 18:36:57 NOTICE[-1148245072]: chan_sip.c:6377 handle_request: ^@Failed to authenticate user DisplayName <sip:17473861973@sipphone.com>;tag=376761602 (This one made from myphonebooth.com, hence their "From" header.) Adding [17473861973] type=user insecure=very to sip.conf will let the call through. By: Mark Spencer (markster) 2004-05-27 22:30:25 Just add some debug to check_user and see if it's matching the peer. If it is, it should be ignoring the authentication when insecure=very. Mark By: kuj (kuj) 2004-05-28 01:12:33 In check_user, when checking the peer for insecure=very, p->peersecret and p->peermd5secret are set to empty strings (which check_auth is supposed to check). However, two lines further down, when calling check_auth, different values are passed as arguments 6 and 7 (peer->secret and peer->md5secret). I guess these should match (setting them to empty when insecure=very and then passing the empty ones to check_auth as arg 6,7). I'll attach chan_sip.c.patch that sets the check_auth parms to p->peersecret and p->peermd5secret. That fixes things for me. Or should instead the peer->secret and peer->md5secret be "blanked" when insecure=very?????? By: kuj (kuj) 2004-05-28 11:26:32 Oops, looks like I uploaded the patch file twice. They are identical. Blame the browser's "Back" key :-) By: Mark Spencer (markster) 2004-05-28 11:33:01 Fixed in CVS By: Digium Subversion (svnbot) 2008-01-15 14:56:41.000-0600 Repository: asterisk Revision: 3102 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r3102 | markster | 2008-01-15 14:56:41 -0600 (Tue, 15 Jan 2008) | 2 lines Really don't authenticate if we're not supposed to authenticate (bug ASTERISK-1714) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3102 |