SIP URI and URL. Part 2 (SIP URI Scheme)
Previous SIP articles:
- SIP customer interaction. Part 1 (Easy Interaction)
- SIP customer interaction. Part 2 (Interaction using a proxy server)
- 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 URIs and URLs used in SIP.
SIP supports several URI schemes:
- sip - for SIP
- sips - for secure SIP
- tel - for phone numbers
- pres - for presence
- im - for instant messaging
- xmpp - for Jabber
- h323 - for the H.323 protocol
First, let's look at the SIP and SIPS URIs.
SIP and SIPS URI
Since the SIP and SIPS URI schemes are identical , later in the text we will talk only about SIP URIs, implying that all this also applies to SIPS URIs.
In addition, we agree that writing in capital letters (SIP) will denote the protocol , and in small letters (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 header fields To, From, Contact, etc. In addition, sip URIs, just like mailto URIs, can be used on sites as hyperlinks.
In general, the sip scheme is as follows:
Note that URIs must not contain spaces or line breaks.
USER and PASSWORD
As we recall from the first part of the article, in the URI scheme, the combination of user and password is called userinfo. As part of sip, userinfo ends with the @ sign. The userinfo part is optional and may be missing; the "@" sign should also be absent.
According to RFC 3261, user identifies a specific resource on a host. In this case, a host is most often a domain.
If the host supports working with phone numbers, then the user can be the phone number we want to contact. This is true, for example, when using the SIP trunk.
Password allows you to pass a password. This is not recommended, as in this case the password will be transmitted in clear text.
The host that provides the resource. It uses either the fully qualified domain name (FQDN) or the IPv4 / IPv6 address. It is recommended that you use FQDN wherever possible - this will avoid the problems associated with changing the host IP address.
The port to which the request should be sent. If this field is absent, then 5060 for SIP and 5061 for SIPS are used.
Parameters affect the request to be sent to the URI.
The number of parameters can be arbitrary, but each of them can occur only once. Each new parameter begins with a ";" and has the following syntax:
The sip scheme supports the following parameters:
- user - do not confuse with user from userinfo
Because the URI scheme is extensible, other parameters may occur. In this case, the User Agent must ignore all unknown parameters.
transportDefine the protocol that should be used to send messages. UDP, TCP, or SCTP are commonly used, but the scheme allows you to specify any transport layer protocol supported by the SIP client. By default, SIP uses UDP. For SIPS, any reliable protocol must be used; the default is TCP.
maddrDefines the server address, but which requests should be sent for this user. Respectively overwrites the value of the host field. If msddr is present in the URI, the port and transport will relate to it. Usually maddr contains a multicast address.
ttlDefines TTL (Time-To-Live) UDP multicast packet. It should be used only if UDP is used as a transport and maddr contains a multicast address.
userNot to be confused with userinfo-> user. Since a phone number can be used as a username, we should distinguish between the case when "+79211234567" is the phone number with which the host will connect us from the case when the same line is the username on the host (yes, we are quite we can create a user with the name "+79211234567"). To do this, use the user parameter. 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 consider that this parameter does not in any way speak about the capabilities and characteristics of the subscriber represented by this URI. That is, user = phone should not lead us to the idea that the User Agent is a phone that does not know how to work with video calls.
methodDefines the method to use in the request. The default is INVITE.
lrUsed in routing. We will talk about him in a separate article.
Headers that can be added to the request. These can be Subject and Priority.
The table below shows the use of the components of the SIP URI scheme for various cases:
In the next article, we will consider tel schemes for telephone numbers and pres for presence.