Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column

Sending Messages

 

The process by which an underlying transport is chosen for sending of a message is broken up into different steps depending on the type of message.

SIP Request Handling

1. URI Parsing

 The PJSIP stack fundamentally acts on URIs. When sending to a URI it is parsed into the various parts (user, host, port, user parameters). For the purposes of transport selection the transport parameter is examined. This specifies the type of transport. If this parameter is not present it is assumed to be UDP. This is important because it is used in DNS resolution. If a "sips" URI scheme is used an automatic switchover to TLS will occur.

2. DNS SRV Resolution (If host portion is not an IP address and no port is present in the URI)

The transport type from above is used to determine which SRV record to look up. This means that the original URI must include the transport type for TCP and TLS types UNLESS the "sips" URI scheme is used which automatically switches to TLS.

3a. Transport Selection (No explicit transport provided)

Now that the underlying type of transport is known and the resolved target exists the transport selection process can begin.

Connection-less protocols (such as UDP)

A transport, decided upon by a hashing mechanism, matching the transport type and address family is selected.

Connection-oriented protocols (such as TCP or TLS)

An already open connection to the resolved IP address and port is searched for. If the connection exists it is reused for the request. If no connection exists the first transport matching the transport type and address family as configured in pjsip.conf is chosen. It is instructed to establish a new connection to the resolved IP address and port.

Column
Panel
titleOn this Page

Table of Contents
maxLevel2

...

The provided transport is instructed to establish a new connection to the resolved IP address and port.

This does NOT currently attempt to reuse any existing connections. A new one will always be created. This is an issue being tracked under issue ASTERISK-22658
Note
Info

If an existing connection exists to the IP address and port using the specific transport type then it is reused and a new one is not established.


4. Multihomed Transport Selection (Connection-less protocols)

...

Code Block
[system-udp]
type=transport
protocol=udp
bind=0.0.0.0


[system-tcp]
type=transport
protocol=tcp
bind=0.0.0.0
 
 
[system-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=certificate
 
 
[phone]
type=endpoint

This example includes an endpoint without a transport explicitly defined. Since there is only one transport configured this will always be usedfor each address family and transport type each respective one will be used depending on the URI dialed. For requests to this endpoint the logic in section 3a will be used.

...

 

Code Block
[system-internet-udp]
type=transport
protocol=udp
bind=5.5.5.5


[system-internet-tcp]
type=transport
protocol=tcp
bind=5.5.5.5
 
[system-internet-tls]
type=transport
protocol=tls
bind=5.5.5.5:5061
cert_file=certificate


[system-local-udp]
type=transport
protocol=udp
bind=192.168.1.1


[system-udplocal-tcp]
type=transport
protocol=tcp
bind=192.168.1.1
 
 
[system-local-tls]
type=transport
protocol=tls
bind=192.168.1.1:5061
cert_file=certificate
 
[phone-internet]
type=endpoint
transport=system-internet-udp
 
 
[phone-local]
type=endpoint
transport=system-local-udp
 
 
 
[phone-unspecified]
type=endpoint

 

This example includes two three endpoints which are each present on different networks. To ensure that outgoing requests to each endpoint the first two endpoints travel over the correct transport the transport has been explicitly specified on each. For requests to these endpoints the logic in section 3b will be used. For requests to the "phone-unspecified" endpoint since no transport has been explicitly specified the logic in section 3a will be used.

IPv6 Only (Single Interface)

...