SIP – Authenticated Vs Unauthenticated Calls

Home » Asterisk Users » SIP – Authenticated Vs Unauthenticated Calls
Asterisk Users 4 Comments


I’m running into an issue as follows, in simplified form:

A remote Asterisk box, when registered/peered via SIP to a central server, and makes a call to that central server, is *sometimes* authenticated and calls go through properly (via from-internal context), and *sometimes* is unauthenticated, and all calls are greeted with congestion() via the from-sip-external context. Yes, as you can tell, FreePBX is in play here too.

Grabbing captures of a working call vs a non-working call, I’m seeing on the working call, the central Asterisk server is responding to the INVITE with a 407 Proxy Authentication Needed, box responds, call goes through. On the non-working calls, the central Asterisk server is responding with a simple 100 Trying, then 200 OKs the session as it throws it into from-sip-external assuming the box is not authenticated.

So… and pardon my rambling above… why is this the case? In what circumstances would Asterisk respond to the same peer differently, seemingly at random?

I’m happy to provide any details required, but I’m having a brain freeze on what would be relevant at this point.

Thanks for any pointers or ideas!


4 thoughts on - SIP – Authenticated Vs Unauthenticated Calls

  • Tim Nelson wrote:


    chan_sip can match to a peer a few different ways:

    1. The user portion of the From header matches a configured peer in sip.conf
    2. The received IP address/port matches a configured peer in sip.conf using “insecure=very” or combination thereof.

    It’s possible that you are relying on #1 but not explicitly overriding the user portion in the calling Asterisk using fromuser. Without doing this the user portion carries caller ID number information, with can obviously change between calls.

    That’s my best guess without “sip set debug on” output for a non-working call and the configuration.


  • Tim Nelson wrote:

    Registration just tells the remote system what your IP address/port is for sending calls.

    You don’t *have* to send CID like you are. You can override using fromuser to ensure that the specific peer is *always* matched and authenticated. CID can be conveyed in an alternate header, like Remote-Party-ID. The options involved for RPID are “sendrpid=yes” on the caller box and “trustrpid=yes” on the receiving box.

    It’s possible, without logs and such it’s only a guess.

  • 1 nov 2012 kl. 15:13 skrev Joshua Colp :

    Agree, all comments are pure speculations at this point.

    Try removing the user object to simplify. If you have type=friend, change to type=peer and you will *only* get IP/port-based matching and can configure your system in a controlled way. There are just a few situations where you actually benefit from having type=friend and match object names with Caller ID numbers.