SIP URI and URL. Part 2 (SIP URI scheme)

Previous articles on SIP:

1. SIP client interaction. Part 1 (Simple Interaction)
2. SIP client interaction. Part 2 (Interaction with the use of a proxy server)
3. SIP URI and URL. Part 1 (URI, URL and URN)

In the first part of the article we figured out what URL, URN and URN are. It's time to talk about the URI and URL used in SIP.

SIP protocol supports multiple URI schemes:

• sip - for SIP
• sips - for secure SIP
• tel - for phone numbers
• pres - for presence
• im - for instant messages
• xmpp - for Jabber
• h323 - for H.323 protocol

First, let's look at the SIP and SIPS URI

SIP and SIPS URI

Since the SIP and SIPS URI schemes are identical , we will speak only of the SIP URI in the text, meaning that this also applies to the SIPS URI.

In addition, we agree that writing in capital letters (SIP) will denote a protocol , and small (sip) - the name of the scheme .
')
As you remember from previous articles, SIP URIs are used in a number of places in a SIP message, in particular in the To, From, Contact, and so on header fields. In addition, the sip URI, just like the mailto URI, can be used on sites as hyperlinks.

In general, the sip scheme looks like this:


Please note that URIs should not contain spaces or line breaks.

USER and PASSWORD

As we remember from the first part of the article, in the URI scheme, the set of user and password is called userinfo. Within sip, userinfo is terminated by a "@" sign. The userinfo part is optional and may be missing; the "@" sign should also be absent.

According to RFC 3261, the user identifies a specific resource on a host. In this case, a host most often means a domain.

If the host supports working with phone numbers, then the user can be specified with the phone number that we want to contact. This is true, for example, when using SIP trunk.

Password allows you to transfer a password. It is not recommended to do this, since in this case the password will be transmitted in the clear.

HOST

Host providing the resource. It uses either a fully qualified domain name (FQDN) or an IPv4 / IPv6 address. It is recommended to use the FQDN wherever possible - this will avoid problems associated with changing the IP address of the host.

PORT

The port to which the request should be sent. If this field is absent, then 5060 for SIP and 5061 for SIPS are used.

Options

Parameters affect the request that will be sent to the URI.

The number of parameters can be arbitrary, but each of them can occur only once. Each new parameter starts with a ";" and has the following syntax:


The sip scheme supports the following options:

• transport
• maddr
• ttl
• method
• lr
• user - not to be confused with user from userinfo

As the URI scheme is extensible, there may be other parameters. In doing so, the User Agent should ignore all unknown parameters.

transport

Determine the protocol to use for sending messages. Typically, UDP, TCP, or SCTP is used, but the scheme allows you to specify any transport-level protocol supported by the SIP client. The default for SIP is UDP. For SIPS, any reliable protocol should be used; by default - TCP.

maddr

Specifies the address of the server, but which should be sent requests for this user. Respectively overwrites the value of the host field. If msddr is present in the URI, the port and transport will apply to it. Usually maddr contains a multicast address.

ttl

Defines a TTL (Time-To-Live) UDP multicast packet. Must be used only if UDP is used as transport and maddr contains a multicast address.

user

Not to be confused with userinfo-> user. Since a phone number can be used as a user name, the case when "+79211234567" is the phone number that the host will connect us to from the case when the same line is the user name on the host should be distinguished (yes, we we can create a user with the name "+79211234567"). To do this, use the parameter user. By default, user = ip. This means that userinfo-> user contains the username on the host. If user = phone, then userinfo-> user is the phone number with which the host should connect us.

It is important to note that this parameter in no way speaks of the capabilities and characteristics of the subscriber represented by the given URI. That is, user = phone should not push us to the idea that the User Agent is a phone that does not know how to work with video calls.

method

Specifies the method to use in the request. The default is INVITE.

lr

Used when routing. We will talk about it in a separate article.

Headlines

Headers that can be added to the request. These can be Subject and Priority.

Below is a table of the use of the constituent parts of the SIP URI scheme for various cases:


In the next article, we will look at tel schemes for phone numbers and pres for presence.