[Home]

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:35Date Closed:2008-01-15 14:56:41.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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