Asterisk SIP type and Identity Authentication

In asterisk, there are three types of peer: Peer, user, and friend.
Let's take a look at the three types of VoIP-info.

Peer: a sip entity to which asterisk sends CALS (a sip provider for example ). if you want a user (Extension) to have multiple phones, define an extension that CILS two sip peers. the peer authenticates at registration.
User: a sip entity which places callthrough asterisk (a phone which can place callonly). Users authenticate to reach services with their context.
Friend: an entity which is both a user and a peer. this make sense for most desk handsets and other devices. asterisk will create two objects, one peer and one user, with the same name.
If a _ peer _ is defined with host = dynamic it is allowed to register with asterisk to tell asterisk where it can be found (IP Address/host name) and that it is reachable from now on.

Simply put, in this document, type = peer defines that the peer is a service provider, which allows your asterisk to call through the service provider defined here; the user defines the other party as one of your clients and allows the other party to call through your asterisk. friend is both.

But what is the actual situation? Try the following definition:
[1001]
Username = 1001
Secret = XXXXX
Host = dynamic
Port = 5060
Type = peer
Context = from-extensions

Then, use a SIP client to register it with your Asterisk. What happened?
You will find that the client can also be registered!

In fact, the true significance of type lies in how the asterisk processes requests sent to and from the external.
Type = peer
If type is peer, there are two meanings.
1. You can use the other party as a sip service provider and allow your asterisk to call out through the other party.
2. if the other party is logically a client, asterisk will perform authentication on the other party based on the incoming invite request. However, it should be noted that the authentication here does not pass the username and secret, but through the address and port of the other party. there are two situations:
* The address and port of the other party do not match your port in the SIP. in Conf, if your Asterisk allows anonymous incoming calls (allowguest = yes), the incoming calls will be passed to the SIP. in the general configuration of conf. if anonymous incoming calls are not allowed, the incoming calls are rejected directly.
* The peer address and port match any peer setting in the SIP. conf type. The incoming call is uploaded to the context specified by the peer.
Asterisk also provides an insecure parameter to configure the authentication method for peer incoming calls.
Insecure = port | invite
Port: asterisk ignores the port of the peer and verifies a peer based on the address of the Peer. After receiving the invite of the peer, asterisk sends the SIP/2.0 unauthorized message to the peer, the other party is required to send the authentication information, but the authentication information returned by the other party is not actually used.
Invite: asterisk does not verify the initial invite. This means that asterisk directly uses the information in the invite package passed in by the client to try to verify, instead of sending the SIP/2.0 401 unauthorized package to the other party

Type = user
Authentication is performed based on the user and password information in the source invite package. Therefore, the other party cannot and does not need to register it on your asterisk server.

It should be noted that the register is used. If the host of a peer is set to dynamic, Asterisk allows the client to notify the asterisk of the address and port of the peer through register.