Asterisk pjsip configuration - Revision history

Pchero at 12:41, 11 September 2020

2020-09-11T12:41:35Z

← Older revision		Revision as of 12:41, 11 September 2020
Line 237:		Line 237:

	The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with and individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section.		The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with and individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section.

			== PJSIP with Proxy ==
			<pre>
			[myitsp]
			type = endpoint
			; other stuff
			outbound_proxy = sip:192.168.0.1\;lr
			</pre>
			The proxy URIs have the "lr" parameter added. This is because most proxies these days follow RFC 3261 and are therefore "loose-routing". If it doesn't have it set, you will probably get a 404 response from the proxy. The "\" before the semicolon is important to keep the semicolon from being treated as a comment start character in the config file.

	== See also ==		== See also ==
	* https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships		* https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships
			* https://wiki.asterisk.org/wiki/display/AST/PJSIP+with+Proxies - PJSIP with Proxies

	[[category:asterisk]]		[[category:asterisk]]

Pchero: /* Section names */

2020-04-12T21:53:05Z

Section names

← Older revision		Revision as of 21:53, 12 April 2020
Line 13:		Line 13:

	However, in some cases, (endpoint and aor types) the section name has a relationship to its function. In the case of endpoint and aor their names must match the user portion of the SIP URI in the "from" header for inbound SIP request. The exception to that rule is if you have an identify section configured for that endpoint. In that case the inbound request would be matched by IP instead of against the user in the "From" header.		However, in some cases, (endpoint and aor types) the section name has a relationship to its function. In the case of endpoint and aor their names must match the user portion of the SIP URI in the "from" header for inbound SIP request. The exception to that rule is if you have an identify section configured for that endpoint. In that case the inbound request would be matched by IP instead of against the user in the "From" header.

			== Endpoint matching ==
			Depending on the modules loaded, Asterisk can match SIP requests to an endpoint or aor in a few ways:

			* Match a section name for endpoint type sections to the username in the "From" header of inbound SIP requests.
			* Match a section name for aor type sections to the username in the "To" header of inbound SIP REGISTER requests.
			* With an identify type section configured, match an inbound SIP request of any type to an endpoint or aor based on the IP source address of the request.

	== Section types ==		== Section types ==

Pchero: /* IDENTIFY */

2020-02-11T09:34:55Z

IDENTIFY

← Older revision		Revision as of 09:34, 11 February 2020
Line 212:		Line 212:

	Controls how the res_pjsip_endpoint_identifier_ip module determines what endpoint an incoming packet is from. If you don't have an identify section defined, or else you have res_pjsip_endpoint_identifier_ip loading after res_pjsip_endpoint_identifier_user, then res_pjsip_endpoint_identifier_user will identify inbound traffic by pulling the user from the "from:" SIP header in the packet. Basically the module load order, and your configuration will both determine whether you identify by IP or by user.		Controls how the res_pjsip_endpoint_identifier_ip module determines what endpoint an incoming packet is from. If you don't have an identify section defined, or else you have res_pjsip_endpoint_identifier_ip loading after res_pjsip_endpoint_identifier_user, then res_pjsip_endpoint_identifier_user will identify inbound traffic by pulling the user from the "from:" SIP header in the packet. Basically the module load order, and your configuration will both determine whether you identify by IP or by user.

			res_pjsip_endpoint_identifier_ip 모듈에서 사용하는 섹션으로, Asterisk 로 들어오는 Incoming packet 들에 대해 어떻게 Endpoint 를 물릴 것인지를 정의한다. 즉, Incoming request : Endpoint mapper 이다.

			만약 정의된 Identify 섹션이 없을 경우, res_pjsip_endpoint_identifier_user 에서 Endpoint 를 찾는 역할을 담당하게 되는데, FROM header 에서 user 부분만을 떼어서 매칭을 시도하게 된다.

	==== Example ====		==== Example ====

Pchero: /* CONTACT */

2018-12-02T18:53:58Z

CONTACT

← Older revision		Revision as of 18:53, 2 December 2018
Line 226:		Line 226:

	The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with and individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section.		The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with and individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section.

			== See also ==
			* https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships

	[[category:asterisk]]		[[category:asterisk]]

Pchero: /* CONTACT */

2018-12-02T18:28:24Z

CONTACT

← Older revision		Revision as of 18:28, 2 December 2018
Line 225:		Line 225:
	provided by module: res_pjsip		provided by module: res_pjsip

	The contact config object effectively acts as an		The contact config object effectively acts as an alias for a SIP URIs and holds information about an inbound registrations. Contact objects can be associated with and individual SIP User Agent and contain a few config options related to the connection. Contacts are created automatically upon registration to an AOR, or can be created manually by using the "contact=" config option in an AOR section.

	[[category:asterisk]]		[[category:asterisk]]

Pchero: /* IDENTIFY */

2018-12-02T18:13:06Z

IDENTIFY

← Older revision		Revision as of 18:13, 2 December 2018
Line 162:		Line 162:

	What if you don't need to authenticate? You can simply omit the outbound_auth option.		What if you don't need to authenticate? You can simply omit the outbound_auth option.

			=== DOMAIN_ALIAS ===
			provided by module: res_pjsip

			Allows you to specify an alias for a domain. If the domain on a session is not found to match an AoR then this object is used to see if we have an alias for the AoR to which the endpoint is binding. This sections name as defined in configuration should be the domain alias and a config option (domain=) is provided to specify the domain to be aliased.

			==== Example ====
			<pre>
			[example2.com]
			type=domain_alias
			domain=example.com
			</pre>

			=== ACL ===
			provided by module: res_pjsip_acl

			The ACL module used by 'res_pjsip'. This module is independent of 'endpoint' and operates on all inbound SIP communication using res_pjsip. Features such as an Access Control List, as defined in the configuration section itself, or as defined in acl.conf. ACL's can be defined specifically for source IP addresses, or IP addresses within the contact header of SIP traffic.

			==== Example ====
			A configuration pulling from the acl.conf file:
			<pre>
			[acl]
			type=acl
			acl=example_named_acl1
			</pre>

			A configuration defined in the object itself.
			<pre>
			[acl]
			type=acl
			deny=0.0.0.0/0.0.0.0
			permit=209.16.236.0
			permit=209.16.236.1
			</pre>

			A configuration where we are restricting based on contact headers instead of IP addresses.
			<pre>
			[acl]
			type=acl
			contactdeny=0.0.0.0/0.0.0.0
			contactpermit=209.16.236.0
			contactpermit=209.16.236.1
			</pre>

			All of these configurations can be combined.

	=== IDENTIFY ===		=== IDENTIFY ===

Pchero: /* AOR */

2018-12-02T18:05:00Z

AOR

@@ Line 72: / Line 72: @@
 cipher=
 method=
 </pre>

Pchero: /* Example */

2018-12-02T00:19:26Z

Example

← Older revision		Revision as of 00:19, 2 December 2018
Line 150:		Line 150:
	match=203.0.113.1		match=203.0.113.1
	</pre>		</pre>

			=== CONTACT ===
			provided by module: res_pjsip

			The contact config object effectively acts as an

	[[category:asterisk]]		[[category:asterisk]]

Pchero: /* REGISTRATION */

2018-12-02T00:14:20Z

REGISTRATION

← Older revision		Revision as of 00:14, 2 December 2018
Line 136:		Line 136:

	What if you don't need to authenticate? You can simply omit the outbound_auth option.		What if you don't need to authenticate? You can simply omit the outbound_auth option.

			=== IDENTIFY ===
			provided by module: res_pjsip_endpoint_identifier_ip

			Controls how the res_pjsip_endpoint_identifier_ip module determines what endpoint an incoming packet is from. If you don't have an identify section defined, or else you have res_pjsip_endpoint_identifier_ip loading after res_pjsip_endpoint_identifier_user, then res_pjsip_endpoint_identifier_user will identify inbound traffic by pulling the user from the "from:" SIP header in the packet. Basically the module load order, and your configuration will both determine whether you identify by IP or by user.

			==== Example ====
			Its use is quite straightforward. With this configuration if Asterisk sees inbound traffic from 203.0.113.1 then it will match that to Endpoint 6001.
			<pre>
			[6001]
			type=identify
			endpoint=6001
			match=203.0.113.1
			</pre>

	[[category:asterisk]]		[[category:asterisk]]

Pchero: /* Example */

2018-12-02T00:08:35Z

Example

← Older revision		Revision as of 00:08, 2 December 2018
Line 124:		Line 124:
	</pre>		</pre>

			And an example that may work with SIP trunking provider.
			<pre>
			[mytrunk]
			type=registration
			transport=simpletrans
			outbound_auth=mytrunk
			server_uri=sip:sip.example.com
			client_uri=sip:1234567890@sip.example.com
			retry_interval=60
			</pre>

			What if you don't need to authenticate? You can simply omit the outbound_auth option.

	[[category:asterisk]]		[[category:asterisk]]