Asterisk pjsip configuration: Difference between revisions
Line 74: | Line 74: | ||
</pre> | </pre> | ||
=== AOR === | |||
provided by module: res_pjsip | |||
A primary feature of AOR objects(Address of Record) is to tell Asterisk where an endpoint can be contacted. Without an associated AOR section, an endpoint can not be contacted. AOR objects also store associations to mailboxes for MWI requests and other data that might relate to the whole group of contacts such as expiration and qualify settings. | |||
When Asterisk receives an inbound registration, it'll look to match against available AORs. | |||
Registration: The name of the AOR section must match the user portion of the SIP URI in the "To:" header of the inbound SIP registration. That will usually be the "user name" set in you hard or soft phone configuration. | |||
==== Example ==== | |||
First, we have a configuration where you are expecting the SIP User Agent (likely a phone) to register against the AOR. In this case, the contact objects will be created automatically. We limit the maximum contact creation to 1. We could do 10 if we wanted up to 10 SIP User Agents to be able to register against it. | |||
<pre> | |||
[6001] | |||
type=aor | |||
max_contacts=1 | |||
</pre> | |||
Second, we have a configuration where you are not expecting the SIP User Agent to register against the AOR. In this case, you can assign contacts manually as follows. We don't have to worry about max_contacts since that option only affects the maximum allowed contacts to be created through external interaction, like registration. | |||
<pre> | |||
[6001] | |||
type=aor | |||
contact=sip:6001@192.0.2.1:5060 | |||
</pre> | |||
Third, it's useful to note that you could define only the domain and omit the user portion of the SIP URI if you wanted. Then you could define the user portion dynamically in your dialplan when calling the Dial application. You'll likely do this when building an AOR/Endpoint combo to use for dialing out to an ITSP. For example: "Dial(PJSIP/${EXTEN}@mytrunk)" | |||
<pre> | |||
[mytrunk] | |||
type=aor | |||
contact=sip:203.0.113.1:5060 | |||
</pre> | |||
[[category:asterisk]] | [[category:asterisk]] |
Revision as of 23:59, 1 December 2018
Overview
Asterisk pjsip configuration.
Configuration format
[ SectionName ] ConfigOption = Value ConfigOption = Value
Section names
대부분의 경우, 섹션 이름은 아무렇게나 지정할 수 있다. 예를 들어 transport 이름을 [transport-udp-nat] 와 같이 기억하기 쉽게 지정할 수도 있다.
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.
Section types
Below is brief description of each section type and an example showing configuration of that section only. The module providing the configuration object related to the section is listed in parentheses next to each section name.
There are dozens of config options for some of the sections, but the examples below are very minimal for the sake of simplicity.
ENDPOINT
provided by module: res_pjsip
Endpoint configuration provides numerous options relating to core SIP functionality and ties to other sections such as auth, aor and transport. You can't contact an endpoint without associating one or more AoR sections. An endpoint is essentially a profile for the configuration of a SIP endpoint such as a phone or remote server.
[6001] type=endpoint context=default disallow=all allow=ulaw transport=simpletrans auth=auth6001 aors=6001
If you want to define the Caller id this endpoint should use, then add something like the following.
trust_id_outbound=yes callerid=Spaceman Spiff <6001>
TRANSPORT
provided by module: res_pjsip
Configure how res_pjsip will operate at the transport layer. For example, it supports configuration options for protocols such as TCP, UDP or WebSockets and encryption methods like TLS/SSL.
You can setup multiple transport sections and other sections (such as endpoints) could each use the same transport, or a unique one. However, there are a couple caveats for creating multiple transports:
- They cannot share the same IP+port or IP+protocol combination. That is, each transport that binds to the same IP as another must use a different port or protocol.
- PJSIP does not allow multiple TCP or TLS transports of the same IP version (IPv4 or IPv6)
Reloading Config: Configuration for transport type sections can't be reloading during run-time without a full module unload and load. You'll effectively need to restart Asterisk completely for your transport changes to take effect.
Example
A basic UDP transport bound to all interfaces:
[simpletrans] type=transport protocol=udp bind=0.0.0.0
Or a TLS transport, with many possible options and parameters:
[simpletranst] type=transport protocol=tls bind=0.0.0.0 ;various TLS specific options below: cert_file= priv_key_file= ca_list_file= cipher= method=
AOR
provided by module: res_pjsip
A primary feature of AOR objects(Address of Record) is to tell Asterisk where an endpoint can be contacted. Without an associated AOR section, an endpoint can not be contacted. AOR objects also store associations to mailboxes for MWI requests and other data that might relate to the whole group of contacts such as expiration and qualify settings.
When Asterisk receives an inbound registration, it'll look to match against available AORs.
Registration: The name of the AOR section must match the user portion of the SIP URI in the "To:" header of the inbound SIP registration. That will usually be the "user name" set in you hard or soft phone configuration.
Example
First, we have a configuration where you are expecting the SIP User Agent (likely a phone) to register against the AOR. In this case, the contact objects will be created automatically. We limit the maximum contact creation to 1. We could do 10 if we wanted up to 10 SIP User Agents to be able to register against it.
[6001] type=aor max_contacts=1
Second, we have a configuration where you are not expecting the SIP User Agent to register against the AOR. In this case, you can assign contacts manually as follows. We don't have to worry about max_contacts since that option only affects the maximum allowed contacts to be created through external interaction, like registration.
[6001] type=aor contact=sip:6001@192.0.2.1:5060
Third, it's useful to note that you could define only the domain and omit the user portion of the SIP URI if you wanted. Then you could define the user portion dynamically in your dialplan when calling the Dial application. You'll likely do this when building an AOR/Endpoint combo to use for dialing out to an ITSP. For example: "Dial(PJSIP/${EXTEN}@mytrunk)"
[mytrunk] type=aor contact=sip:203.0.113.1:5060