A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource.
The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax.
They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message. Its general form, in the case of a SIP URI, is:
The format for a SIPS URI is the same, except that the scheme is "sips" instead of sip. These tokens, and some of the tokens in their expansions, have the following meanings:
- user: The identifier of a particular resource at the host being addressed. The term "host" in this context frequently refers to a domain. The "userinfo" of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and MAY be absent when the destination host does not have a notion of users or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty.
If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephonesubscriber field defined in RFC 2806 MAY be used to populate the user field. There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2.
- password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance,
Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat "user:password" as a single string.
- host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible.
- port: The port number where the request is to be sent.
(:exclaim:) Note: A sip URI with username@hostname:5060 is not the same as username@hostname. If the port number is given, a DNS gethostbyname is used to find the host. If there's is no port number, the hostname is looked up with DNS SRV. This hostname can point to one or several SIP proxy servers.
If you dial a telephone number on a keypad, this is converted into a SIP URI of the form sip:nnnnn@domain;user=phone or sip:nnnnn@host:5060;user=phone
The "user=phone" parameter indicates that the user portion of the URI (the part to the left of the @ sign) should be treated as a tel URI, so "sip:+firstname.lastname@example.org;user=phone" should be treated as tel:+1555000000". Note that tel URI parameters (such as phone-context) as included in the user part, not the SIP URI itself, i.e "sip:121;email@example.com;user=phone" is the same as "tel:121;phone-context=+44"
Typically a proxy server for the domain will use a dial plan to resolve this into a real destination. See also Asterisk Extension Matching
Dial by IP address
Some phones let you dial a destination directly by IP address, e.g. dialling #192168001051 would place a call to 192.168.1.51
Presumably this is resolved into a SIP URI of the form sip:192.168.1.51:5060 ? (TBC)
Back to SIP
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+