1. Why do we need SIP peering? When SIP was developed, there was no need for SIP peering. SIP was considered to be as open as email. Like everybody can send emails to everyone, every SIP user should be able to contact every other SIP user via SIP. Therefore, two requirements are necessary: - The SIP provider of the caller must allow calling SIP URIs which are outside of the local SIP domain. - The SIP provider of the callee has to allow incoming SIP calls from callers outside of the local domain. For further discussion, a SIP services which fulfill these two requirements will be referred as "open SIP service". Currently there are lots of open SIP services, e.g. iptel.org or fwd.pulver.com. But there are also other SIP services, which are "closed" or "restricted". Closed means, that the SIP service provider allows only internal SIP calls (when calling other users of this SIP service provider). All calls to other users will be routed via the PSTN. Restricted means, that the SIP service provider allows SIP calls from/to certain domains, but not all domains. This of course requires authentication of incoming calls. (examples of closed service providers are yahoo broadband, inode, vonage, IMS/NGN) There are mainly 3 reasons why a service provider does not offer an open service, but only closed or restricted: - business model: The service provider need the PSTN fees for its business model. - security: The service provider is afraid of possible security impacts - spit: The service provider is afraid of SPIT (VoIP SPAM) which will probably occur sooner or later (like email spam) Having "open" SIP providers while other SIP providers are "closed" leads to several interconnection problems. Following are a few examples: - A user of an open SIP service calls a user of a closed SIP service using the callee’s SIP URI. The callee’s SIP provider ignores the incoming SIP messages, causing failed call setups (without any information why the call failed). - A user of a closed SIP service calls a user of an open SIP service via its E.164 phone number. Although the callee can be called directly via ENUM+SIP, the call will be routed via the PSTN causing higher call setup times, call costs and probably worse quality due to multiple transcoding and packetization. - Two users want to have a SIP video conversation amongst them. Both SIP providers support video sessions, but as the interconnect between both providers will be done via the PSTN, there is no possibility to have multimedia session (video, IM, presence). To resolve these issues, a dedicated peering mode is necessary. Probably lots of people will argue that peering is not necessary and SIP providers should just open their SIP services. But this will lead to the same problems we have with email. Further, if there are service providers which do not want open there service for everybody, their position should be accepted. Even if a service provider opens its SIP service, it might want to apply some restrictions on how the interconnect will be done. Thus, to encourage SIP providers to open their SIP service, we need to offer them mechanisms to authenticate other service providers. There are several ways to authenticate SIP users or other SIP service providers, e.g: SIP over TLS (certificate based authentication), IP address based (TCP or TLS as UDP can be spoofed easily), SIP identity-draft, SIP+S/MIME, SIP+domainkeys, Layer2 VPNs, IPsec, ... Regardless of the technology the service provider requires for authenticating calls, the technology must be somehow announced to the other service providers. This is the reason why we need - draft-lendl-domain-policy-ddds-02.txt and - draft-lendl-speermint-federations-02.txt These drafts define federations and how a service prodiver can publish its peering policies (= federation memberships). 2. What is a federation A federation is like a club. All the members share a common interest. In case of VoIP peering, the members share the common wish to interconnect directly via SIP instead of the old style TDM/SS7 interconnect. A federation needs at least 2 members (this is like a bilateral peering agreement), but usualy may have several members which treat each other as identical. There will be lots of different federations with different goals an dinterconnect policies. E.g. one federation may have to policy to have settlement free peering (sender keeps all) and everbody may participate as long they authenticate via TLS. Other federations may still stay with current settlement policies (termination fees ...) and members most fulfill certain requirements (e.g. must be a mobile operator ...). Thus, it may often happen that a VoIP service provider is a member of several federations. The next sections shows how service providers may participate in several federations and how the domainpolicy technology can be used to achieve "plug-and-play" interworking in several federations. 3. Use Cases - The Federations In the following example we show the use case of a VoIP service provider. This virtual VoIP service provicer is located in Austria and offers VoIP services via cable technology. It is an early adopter of the "triple play" offering TV, Internet and Voice to its customers. Let's call this VoIP service provider "CableItsp1". There are also other cable technology based VoIP service providers in Austria. As they mostly have their local regions without overlapping, these cable guys are not competitors. Their competitors are traditional voice service providers (VSPs). These cable guides set up a federation called "cable-guys-austria" to fight jointly against their competitors. Further there business model is not based on selling voice mintues, but an a monthly subscription fee with flat rate. Thus, having settlement free voice interconnect between each others will be a benefit as they can simplify their billing systems. Further, there is a worldwide federation called "voip-providers-international" which allow every VoIP service provider to join and allow settlement free worldwide interconnect - as long as the members pay they monthly federation subscription. Thus this federation may be interesting for VoIP service providers with a lot of international connections. To have one more example, there is an Austrian federation called "voip-peering-austria" which still insists of interconnect fees. Thus, the simple but very reasonable goal is to keep VoIP calls on IP and avoid transcoding and gatewaying for TDM based interconnect. The settlement must be still agreed bilatereal between the VSPs. All of these federations have different goals and different interconnect policies: cable-guys-austria ================== subscription fee: no settlement: no fees technology: SIP via UDP via IPsec (commom shared secret) via well known IP addresses URI (identifier): http://www.cableguysaustria.at/peering-v1 domain-suffix: cableguysaustria.at voip-providers-international ============================ subscription fee: yes, monthly settlement: no fees technology: SIP via TCP with IP access lists SIP-port: 5080 URI (identifier): http://www.voip-providers-international.com/peeringv1 voip-peering-austria ==================== subscription fee: no settlement: fees must be agreed bilateral technology: SIP via TLS, certificate signed by voip-peering-austria TLS-port: 6666 URI (identifier): http://www.voip-peering-austria.at/TlsPeeringV1 Note: Why some use a dedicated port instead of the SIP default port will be described later. 4. Finding and Peering 4.1. Is the callee reachable via SIP? Before any interconnect policies can be applied, the originating service provider has to find out to which VSP a phone number belongs. These can be done via lookup tables. Probably the most open and commen lookup mechanism is ENUM, especially infrastructure ENUM. The VSP registers the ENUM domains for its numbers and announces the SIP URI for inbound routing in the NAPTR. Thus, the originating service provider performs an IENUM lookup for the called phone number. If there is no ENUM entry for a called number, the originating VSP will send the call to its PSTN gateway as usual. If there is a SIP URI in ENUM, the next step is: 4.2. Does the callee's VSP accept VoIP interconnect from the originator? The SIP URI returned from the IENUM lookup points to the terminating service provider. Thus, the domain in the SIP URI is the "key" to find out the peering policies of the terminating service provider. For example, the IENUM lookup for the called number returns sip:+4312345@sip.itsp66.com. Then, the domain "sip.itsp66.com" will be used as the input data for the domainpolicy algorithm described in draft-lendl-domain-policy-ddds. The originating service provider will perform NAPTR DNS lookups for the domain "sip.itsp66.com" with service types "D2P+...". In this example, there will be 3 NAPTRs returned: $ORIGIN sip.itsp66.com. IN NAPTR 10 50 "U" "D2P+SIP:fed" "!^.*$!http://www.cableguysaustria.at/peering-v1!" . IN NAPTR 20 50 "U" "D2P+SIP:fed" "!^.*$!http://www.voip-peering-austria.at/TlsPeeringV1!" . IN NAPTR 30 50 "U" "D2P+SIP:fed" "!^.*$!http://sipxyconnect.example.org/!" . Now the originator verifies the published federation identifiers agains a local table, in which the originating VSP has configured its federation membership. If there is a matching federation, the next step will applies. 4.3. Apply the federation policies Different federations will use different techniques to interconnect and authenticate each other. Thus, before sending the call to the terminating VSP, the federatations policy must be applied. E.g. if a federation authenticate each other using TLS with certificates signed by the federation's CA, the border proxy must switch to TLS and present the proper certificate to the ingress point of the terminating VSP. Some of these "attributes" must be applied by the border proxy (e.g. tranport protocol, dedicated SIP signaling port, TLS certificate ...) whereas others might be application agnostic (e.g. IPsec encryption, VPNs ...). 5. ENUM routing and federation policies When a VSP publishes its ingress proxy for VoIP peering in ENUM, it publishes only a single NAPTR. Although then ENUM standard allows publishing of several "SIP NAPTRs" for a certain number there is no semantics defined how to deal with multiple received SIP NAPTRs (serial forking? parallel forking? which one to choose?). Thus it is suggested to publish only a single SIP NAPTR in ENUM. Using plain ENUM and plain SIP, all incoming requests for a certain phone number will be received on the same ingress proxy. This is fine in a "open SIP service" environment, but not in a dedicated peering scenario where traffic from certain peering partners should be received on certain ingress points. A common use case is the use of TLS. As TLS does not allow "virtual hosting", authentication with different certificates for different peering partners requires a dedicated socket for each "TLS domain". Another use case is peering in a dedicated VLAN with public IP addresses. If a VSP has an ingress proxy in the public Internet and an ingress proxy in a private LAN (for dedicated peering partners), there must be an algorithm which allows to originating VSP to resolve from the common SIP URI to the respective IP address (public or private). This can be done by applying federation policies to the SIP URI. We will call these "override attributes" as they override the default SIP routing behavior described in RFC 3263. Each federation defines its override attributes which allow to "manipulate" the default RFC3263 call routing according to the federation's policy. Currently the openser domainpolicy module supports the following override attributes: - port_override: If this attribute is set, the port in the destination URI is set to this port. Setting an override port disables NAPTR and SRV lookups according to RFC 3263. - transport_override: If this attribute is set, the transport parameter in the destination URI is set to the specified transport ("udp", "tcp", "tls"). Setting an override transport also disables NAPTR lookups, but retains an SRV lookup according to RFC 3263. - domain_prefix: If this attribute is set, the domain in the destination URI will be prefixed with this "subdomain". E.g. if the domain in the request URI is "example.com" and the domain_prefix contains "inbound", the domain in the destinaton URI is set to "inbound.example.com". - domain_suffix: If this attribute is set, the domain in the destination URI will have the content of the attribute appended to it. E.g. if the domain in the request URI is "example.com" and the domain_suffix contains "myroot.com", the domain in the destination URI is set to "example.com.myroot.com". Thus, using override attributes manipulates the destination URI - the socket to which the message will be sent. Nevertheless, the request URI (the SIP URI in the first line of the SIP request) is untouched as will always be the value of the ENUM lookup. 6. Configuring inbound routing This section shows how the previously presented VSP "CableItsp1" configures it inbound routing. As desrcribed earlier, CableItsp1 is member of 3 different federations, each having its own interconnect policies. 6.1. ENUM CableItsp1 chooses a simple format for its NAPTRs: the user part is the E.164 phone number and the domain part is its domain cableitsp1.at, for example: $ORIGIN 5.4.3.2.1.3.4.e164.arpa. IN NAPTR 10 50 "U" "E2U+sip" "!^.*$!sip:+4312345@cableitsp1.at!" . 6.2. Announcing federation memberships CableItsp1 announces its federation memberships (= its interconnect policies) in the DNS: $ORIGIN cableitsp1.at. IN NAPTR 10 50 "U" "D2P+SIP:fed" "!^.*$!http://www.cableguysaustria.at/peering-v1!" . IN NAPTR 20 50 "U" "D2P+SIP:fed" "!^.*$!http://www.voip-peering-austria.at/TlsPeeringV1!" . IN NAPTR 30 50 "U" "D2P+SIP:fed" "!^.*$!http://www.voip-providers-international.com/peeringv1!" . 6.3. Federation ingress configuration 6.3.1 Federation cable-guys-austria As this federation uses IPsec for authentication, CableItsp1 decided to use a dedicated IP address 11.22.33.44 on its border proxy for dealing with the IPsec stuff. Thus, the domain cableitsp1.at.cableguysaustria.at (SIP URI domain + domain-suffix according to the federation policies) will resolve to 11.22.33.44. CableItsp1 configues the IPsec to use the shared secret of the federation and forbidds any SIP signalling from/to 11.22.33.44 without IPsec. The list of IP addresses of interconnect partners (members of this federation) will be downloaded once a day from the federations web server and the IPsec configuration will be updated accordingly. In the openser call routing, inbound calls from this federation can be detected by: if(dst_ip==11.22.33.44) { log("message received via IPsec\n"); ... }; 6.3.2 Federation voip-providers-international This federation uses SIP over TCP over port 5080. Thus, CableItsp1 configures its border proxy to also listen on port 5080 for TCP, and adds the IP addresses of the peers to the IP access list on its firewall. In the openser call routing, inbound calls from this federation can be detected by: if( (dst_port==5080) && (proto==TCP) ) { log("message received via TCP port 5080\n"); ... }; 6.3.3 Federation voip-peering-austria This federation uses TLS for authentication. CableItsp1 generated a certificate signing request (CSR) using the openssl tools. This CSR was signed by the voip-peering-austria CA. Then the border proxy was configured to listen on port 6666 for TLS and use the respective certificate and CA list: listen=tls:10.10.0.41:6666 tls_server_domain[10.10.0.41:6666] { tls_certificate = "/etc/certs/voip-peering-austria/cert.pem" tls_private_key = "/etc/certs/voip-peering-austria/privkey.pem" tls_ca_list = "/etc/certs/voip-peering-austria/cacert.pem" tls_method=TLSv1 tls_verify_client = 1 tls_require_client_certificate = 1 } In the openser call routing, inbound calls from this federation can be detected by: if( (dst_port==6666) && (proto==TLS) ) { log("message received via TLS on port 6666\n"); ... }; 7. Configuring outbound routing The call routing configuration for domainpolicy based routing is rather simple: if (dp_can_connect()) { # check the domainpolicy of the destination # apply domain policy if (dp_apply_policy()) { t_relay(); exit; } ... } The configuration for the domainpolicy module is mainly entering the federation policy in the domainpolicy table. The domainpolicy table consists of the following columns: id: unique id rule: Name of column containing the domain policy rule name which is equal to the URI as published in the domain policy NAPTRs (the federation identifier). att: The override attribute. Name of column containing the AVP's name. If the rule stored in this row triggers, than dp_can_connect() will add an AVP with that name. val: Value of the override attribute. Name of column containing the value for AVPs created by dp_can_connect(). comment: a description of these table entry The id and comment table are not used by openser. The following table shows the required domainpolicy table for the previously defined federations: id rule type att val comment 1 http://www.voip-providers-international.com/peeringv1 fed portoverride 5080 2 http://www.voip-providers-international.com/peeringv1 fed transportoverride tcp 3 http://www.voip-peering-austria.at/TlsPeeringV1 fed tls_client_domain voip-peering-austria 4 http://www.voip-peering-austria.at/TlsPeeringV1 fed portoverride 6666 5 http://www.voip-peering-austria.at/TlsPeeringV1 fed transportoverride tls 6 http://www.cableguysaustria.at/peering-v1 fed transportoverride udp 7 http://www.cableguysaustria.at/peering-v1 fed sendsocket 11.22.33.44 Further, it requires the configuration of a TLS client domain and the AVPs for the domainpolicy module: tls_client_domain["voip-peering-austria"] { tls_certificate = "/etc/certs/voip-peering-austria/cert.pem" tls_private_key = "/etc/certs/voip-peering-austria/privkey.pem" tls_ca_list = "/etc/certs/voip-peering-austria/cacert.pem" tls_method=TLSv1 tls_require_server_certificate = 1 } modparam("domainpolicy", "port_override_avp", "portoverride") modparam("domainpolicy", "transport_override_avp", "transportoverride") modparam("domainpolicy", "domain_prefix_avp", "domainprefix") modparam("domainpolicy", "domain_suffix_avp", "domainsuffix") modparam("domainpolicy", "sendsocket_avp", "sendsocket")