SIP URI scheme
The SIP URI scheme is a Uniform Resource Identifier (URI) scheme for the Session Initiation Protocol (SIP) multimedia communications protocol. A SIP address is a URI that addresses a specific telephone extension on a voice over IP system. Such a number could be a private branch exchange or an E.164 telephone number dialled through a specific gateway. The scheme was defined in . Operation. A SIP address is written in user@domain.tld format in a similar fashion to an email address. An address like: instructs a SIP client to use the NAPTR and SRV schemes to look up the  SIP server associated with the DNS name voip-provider.example.net and connect to that server. If those records are not found, but the name is associated with an IP address, the client will directly contact the SIP server at that IP address on port 5060, by default using the UDP transport protocol. It will ask the server (which may be a gateway) to be connected to the destination user at 1-999-123-4567. The gateway may require the user REGISTER using SIP before placing this call. If a destination port is provided as part of the SIP URI, the NAPTR/SRV  lookups are not used; rather, the client directly connects to the specified host and port. As a SIP address is text, much like an e-mail address, it may contain non-numeric characters. As the client may be a SIP phone or other device with just a numeric, telephone-like keypad, various schemes exist to associate an entirely numeric identifier to a publicly reachable SIP address. These include the iNum Initiative (which issues E.164-formatted numbers, where the corresponding SIP address is the number '@sip.inum.net'), SIP Broker-style services (which associate a numeric *prefix to the SIP domain name) and  the e164.org and e164.arpa domain name servers (which convert numbers to addresses one-by-one as DNS reverse-lookups). SIP addresses may be used directly in configuration files (for instance, in Asterisk (PBX) installations) or specified through the web interface of a voice-over-IP gateway provider (usually as a call forwarding destination or an address book entry). Systems which allow speed dial from a user's address book using a vertical service code may allow a short numeric code (like *75xx) to be translated to a pre-stored alphanumeric SIP address. Spam and security issues. In theory, the owner  of a SIP-capable telephone handset could publish a SIP address from which they could be freely and directly reached worldwide, in much the same way that SMTP e-mail recipients may be contacted from anywhere at almost no cost to the message sender. Anyone with a broadband connection could install a softphone (such as Ekiga) and call any of these SIP addresses for free. In practice, various forms of network abuse are discouraging creation and publication of openly reachable SIP addresses: In the server logs, this looks like: an attempt to call a Palestinian mobile telephone (Israel, country code  +972) by randomly trying 9- (a common code for an outside line from an office PBX), 011- (the overseas call prefix in the North American Numbering Plan) and 7- (on the off-chance a PBX is using it instead of 9- for an outside line). Security tools such as firewalls or fail2ban must therefore be deployed to prevent unauthorised outside call attempts; many VoIP providers also disable overseas calls to all but countries specifically requested as enabled by the subscriber. SIPS URI scheme. The SIPS URI scheme adheres to the syntax of the SIP URI, differing only in that the  scheme is codice_1 rather than codice_2. The default Internet port address for SIPS is 5061 unless explicitly specified in the URI. SIPS allows resources to specify that they should be reached securely. It mandates that each hop over which the request is forwarded up to the target domain must be secured with TLS. The last hop from the proxy of the target domain to the user agent has to be secured according to local policies. SIPS protects against attackers which try to listen on the signaling link. It does not provide real end-to-end security, since encryption is only  hop-by-hop and every single intermediate proxy has to be trusted.