12 thoughts on - Failed To Authenticate

• Show us the part of sip.conf which you use to register for this account.

  Antony.

  —
  Why are sea-faring brigands unable to calculate the circumference of a circle?
  Because they guess the value of Pi.
  (Sorry, this joke only really works well in German).

  Please reply to the list;
  please *don’t* CC me.

  —

• Sure here it is:
  [general](+)
  register => 3382:XX@IP/3382

  ; Description: Connection to PBX
  [3382]
  type=friend defaultname382
  defaultuser382
  secret=XX
  dtmfmode=RFC2833
  host=IP
  description=Connection to PBX
  context=incoming rtptimeout`
  rtpholdtimeout`
  rtpkeepalive`
  callerid382
  qualify=no canreinvite=no nat=never disallow=all allow=ulaw allow=alaw allow=gsm

  Thanks Jerry

• What’s the association between 3381 and 3382?

  Antony.

  —
  90% of networking problems are routing problems.
  9 of the remaining 10% are routing problems in the other direction. The remaining 1% might be something else, but check the routing anyway.

  Please reply to the list;
  please *don’t* CC me.

  —

• 3381 is the number they want to dial into my asterisk. 3382 is the registered extension to their system.

  Jerry

• Sorry – I’m confused by that.

  You register as 3382. That means that if someone on their system dials 3382, your Asterisk server gets the call.

  I assume extension 8124 was placing the call in the example you gave:

  so I still don’t understand where 3381 comes in.

  Antony.

  —
  I wasn’t sure about having a beard at first, but then it grew on me.

  Please reply to the list;
  please *don’t* CC me.

  —

• 3382,

  I think at first I was only using 3381. That was the extension I
  registered. There was no 3382. Something was going wrong there also.
  (Might have been a similar error), and I could not get that to work either.

  Jerry

• Well my issue has changed now. I have dropped the 3382. Changed back to
  3381. So I am registering 3381 to the other server. The other server is 10.35.229.5. My IP is 10.35.229.11. I have two network cards.

  10.35.229.11 is Eth0
  192.168.1.60 is Eth1

  route looks OK
  route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface
  0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
  10.35.229.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
  192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

  The issue is that the call comes in but the user hears no audio. There is any crazy networking going on – why would the user not hear audio ?
  Thanks

  Jerry

• That makes more sense to me, at least.

  I think eth1 and your routing table are not relevant to this.

  Commonly, because of firewalling and/or NAT.

  Given that your client 10.35.229.11/24 and the server 10.35.229.5/24 are both on the same subnet, it’s not going to be a NAT problem, so I would look at the firewall rules, both on your machine and the one you are connecting to.

  (Please do tell us if the client and server are not connected directly through a switch as I have assumed here, and there’s possibly something more complicated going on.)

  You want to look for firewall rules which will allow UDP in both directions on ports 10000 – 30000 (typically, may vary a bit, but something like that), or alternatively, look for any rules which would block this, and remove them.

  If that doesn’t appear to be the problem, do a packet capture of your SIP
  traffic and look for the Invite and the reply, each with the SDP payloads, to find out what IP addresses and port numbers the client and server are advertising to each other.

  The only other thing I can think of right now is codec compatibility.

  Antony.

  —
  I know I always wanted to be somebody, but I guess I should have been more specific.

  Please reply to the list;
  please *don’t* CC me.

  —

• You could switch to PJSIP and avoid most of this silliness.

  I love Asterisk, but the peer/user/friend model in chan_sip is simply terrible.

  PJSIP is different so there is a learning curve, of course.

  —
  http://help.nyigc.net/

  —

• Hello Antony,

  Monday, August 9, 2021, 4:14:11 PM, you wrote:

  This. Check that the port range in rdp.conf matches that in your firewall UDP settings. Even a slight mismatch in the ranges can result in a surprising number of calls with one-way audio which seem to happen in clusters.

  —
  Best regards, Julian mailto:jb_soft@trink.co.uk

  —

• Hello All,

  I got more information about the “no audio”.

  The incoming call is from 10.37.229.5 – I have two network cards in the box.
  10.35.229.11 eth0
  192.168.1.60 eth1

  When I noticed the incoming address was 10.37.229.5 I thought the audio packets are sending out the default route of eth1. SO I tried to add a route:
  route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface
  0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
  10.35.229.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
  10.37.229.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
  192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

  But I am still not getting audio.

  Anything else I might try ?

  Thanks

  Jerry

• Hello

  Le 11/08/2021 à 15:10, Jerry Geis a écrit :

  Check if your networks in localnet are correctly defined.