SIP Port Mapping

This section contains information about the SIP port mapping feature. SIP port mapping lets you allocate a unique SIP signaling transport address (IP address and UDP port) on the Oracle® Enterprise Session Border Controller in the provider network for each registered endpoint (user agent).

About SIP Port Mapping

You might need to provide a unique signaling transport address for each registered endpoint for admission control, if required by your softswitch vendor. If you have questions about your softswitch, contact the vendor for assistance.

When a Oracle® Enterprise Session Border Controller resides between the endpoints and the softswitch, the softswitch sees the same transport address (that of the Oracle® Enterprise Session Border Controller) for all endpoints. By allocating a unique UDP port for each endpoint, the Oracle® Enterprise Session Border Controller provides each of them a unique transport address.

The following example illustrates the SIP port mapping feature.

The SIP Port Mapping diagram is described below.

The diagram shows UA1, UA2, and UA3 are endpoints within the access network and that the SIP interface for the access network is 172.16.0.15:5060. On the provider network, the SIP interface is at 192.168.24.15, with the SIP port mapping feature enabled. The softswitch/registrar is also located on the provider network at 192.168.24.90:5060.

The diagram shows that port 2001 on the provider network is allocated to UA1 on the access network, port 2002 is allocated to UA2, and port 2003 is allocated to UA3. Because of this allocation, all SIP signaling messages sent from the endpoints in the access network to the softswitch on the provider network travel through an allocated signaling port. For example, all signaling messages between UA1 and the softswitch use 192.168.24.15:2001 as the transport address.

How SIP Port Mapping Works

The Oracle® Enterprise Session Border Controller (E-SBC) allocates SIP port mapping (signaling) ports during a REGISTER request that has registration caching applied. When you define a range of signaling ports for the SIP interface, you create a pool of signaling ports that can be allocated during the REGISTER request.

The E-SBC allocates a signaling port from the pool when it creates the registration cache entry for a Contact in a REGISTER request. It allocates a separate signaling port for each unique Contact URI from the access side. The registration cache Contact entry contains the mapping between the Contact URI in the access/endpoint realm (the UA-Contact) and the Contact URI in the registrar/softswitch realm (the SD-Contact).

The SD-Contact is the allocated signaling port. The signaling port gets returned to the pool when the Contact is removed from the registration cache. The removal can occur when the cache entry expires; or when the endpoint sends a REGISTER request to explicitly remove the Contact from the registrar. When a signaling port returns to the pool it gets placed at the end of pool list; in a least-recently-used allocation method for signaling ports

When the E-SBC forwards the REGISTER request to the softswitch, it replaces the UA-Contact with SD-Contact. For example, if UA1 sends a REGISTER request with a Contact URI of sip:ua1@172.16.0.91:5060, it is replaced with sip:192.168.24.15:2001 when the REGISTER request is forwarded to the registrar.

The same translation occurs when UA1 sends that same URI in the Contact header of other SIP messages. SIP requests addressed to the allocated signaling transport address (SD-Contact) are translated and forwarded to the registered endpoint contact address (UA-Contact).

Note:

The maximum number of registered endpoints cannot exceed the number of signaling ports available. If no signaling ports are available for a new registration, the REGISTER request receives a 503 response.

The E-SBC still processes requests received on the configured SIP port address. Requests sent into the registrar/softswitch realm that are not associated with a registered user will use the configured SIP port address.

Using SIP port mapping with SIPconnect—where unique ports are used for each registered PBX—hinders the E-SBC from routing incoming calls to the corresponding PBX because the E-SBC uses DN for the PBX’s parent during registration, but the incoming INVITE from the softswitch contains the child DN in its Request URI. Thus the E-SBC cannot find a matching SBC-Contact because the username of the Request URI contains the child DN, but the username of the SBC-Contact contains the parent DN.

You can enable SIPconnect support in either the realm configuration or session agent for the SIP access network by setting the sip-connect-pbx-reg option. With this option set and the destination realm configured for port mapping, the E-SBC inserts a special search key in the registration table. Rather than adding the SD-Contact as the key as with regular (non-SIPconnect) registrations, the E-SBC strips user information and instead uses the host and port information as the registration key. The E-SBC still forwards the registration message with an intact contact username.

SIP Port Mapping Based on IP Address

Some registrars need to know that multiple contacts represent the same endpoint. The extension to this feature answers the expectation from registrars that an endpoint registering multiple AoRs will use a single core-side mapped port to show that the AoRs really represent a single endpoint.

When you enable SIP port mapping based on IP Address, the Oracle® Enterprise Session Border Controller supports core-side UDP port mapping based on the endpoint’s IP address. It ignores the username portion of the AoR or Contact.

The Oracle® Enterprise Session Border Controller performs the port mapping allocation and lookup based on all requests using the via-key from the SIP Request. The via-key is a combination of Layer 3 and Layer 5 IP information in the message. The Oracle® Enterprise Session Border Controller performs an additional lookup in the registration table to determine if a via-key already exists. If it does, then the Oracle® Enterprise Session Border Controller uses the port already allocated and does not allocate a new one.

About NAT Table ACL Entries

To enable SIP signaling messages to reach the host processor, the Oracle® Enterprise Session Border Controller adds NAT table ACL entries for each SIP interface. With UDP without SIP port mapping applied, it adds a single ACL entry for each SIP port in the SIP interface configuration. For example:

untrusted entries:
intf:vlan source-ip/mask:port/mask dest-ip/mask:port/mask   prot type    index
0/0:0     0.0.0.0                  172.16.1.15:5060         UDP  static  10
0/3:0     0.0.0.0                  192.168.24.15:5060       UDP  static  16
0/1:0     0.0.0.0                  192.168.50.25:5060       UDP  static  17

Using SIP Port Mapping

When you use SIP port mapping, one or more ACL entries are added to the NAT table to enable the range of ports defined. The NAT table does not support the specification of port ranges. However, it does support masking the port to enable ranges that fall on bit boundaries. For example, an entry for 192.168.24.15:4096/4 defines the port range of 4096 through 8191.

The algorithm for determining the set of ACLs for the port map range balances the need to represent the range as closely as possible, with the need to minimize the number of ACL entries. For example, a range of 30000 through 39999 would result in the following set of ACLs.

untrusted entries:
intf:vlan source-ip/mask:port/mask dest-ip/mask:port/mask   prot type    index
0/3:0     0.0.0.0                  192.168.24.15:30000/4    UDP  static  13
0/3:0     0.0.0.0                  192.168.24.15:32768/4    UDP  static  14
0/3:0     0.0.0.0                  192.168.24.15:36864/4    UDP  static  15

However, the first entry actually enables ports 28672 though 32767 and the last entry allows port 36864 through 40959. If SIP messages are received on ports outside the configured range (28672 through 29999 or 40000 through 40959 in this case), they are ignored.

Acme Packet recommends you use port map ranges that fall on bit boundaries to ensure the fewest possible ACL entries are created and only the configured ports are allowed by the ACLs. For example, a range of 32768 to 49151 provides for 16,384 signaling ports in a single ACL entry (192.168.24.15:32768/2).

Note:

If the ACLs added for the port map range do not include the SIP port configured in the SIP interface; the normal SIP ACL entry for the SIP port is also added.

Dynamic Configuration

Dynamic configuration of SIP port mapping can cause disruption in service for existing registration cache entries; depending on the changes made to the defined port map range. If the range of mapping ports is reduced, it is possible that SIP signaling messages from the registrar/softswitch realm will no longer be sent to the host processor because of the changes in the NAT Table ACL entries.

When the range of mapping ports is changed, any signaling ports in the free signaling port pool not allocated to a registration cache entry are removed from the pool. When an allocated signaling port that is no longer part of the defined mapping port range is released, it is not returned to the pool of free steering ports.

The administrator is warned when the changed configuration is activated after the port map range of a SIP interface has been changed.

Registration Statistics

The SIP registration cache statistics include counters for free and allocated signaling ports. You can issue a show registration command to display the statistics:

17:36:55-190
SIP Registrations          -- Period -- -------- Lifetime --------
                 Active    High   Total      Total  PerMax    High
User Entries          4       4       0          7       4       4
Local Contacts        4       4       0          7       4       4
Free Map Ports    12284   12284       0      12291   12288   12288
Used Map Ports        4       4       0          7       4       4
Forwards              -       -       1         22       4
Refreshes             -       -       3         43       3
Rejects               -       -       0          0       0
Timeouts              -       -       0          1       1
Fwd Postponed         -       -       0          0       0
Fwd Rejected          -       -       0          0       0
Refr Extension        0       0       0          0       0       0
Refresh Extended      -       -       0          0       0

The labels for the first two items reflect the restructured registration cache:

User Entries: counts the number of unique SIP addresses of record in the cache. Each unique address of record represents a SIP user (or subscriber). The address of record is taken from the To header in the REGISTER request. There might be one or more registered contacts for each SIP user. The contacts come from the Contact header of the REGISTER request.
Local Contacts: counts the number of contact entries in the cache. Because the same user can register from multiple endpoints (user agents); the number of Local Contacts might be higher than the number of User Entries.
Free Map Ports: counts the number of ports available in the free signaling port pool.
Used Map Ports: counts the number of signaling ports allocated for registration cache entries. The value of Used Map Ports will equal the number of Local Contacts when the port mapping feature is used for all registrar/softswitch realms in the Oracle® Enterprise Session Border Controller.

SIP Port Mapping Configuration

You configure the SIP port mapping feature on a per-realm basis using the SIP interface configuration. Configure the port map range on the SIP interface for the realm where the registrar/softswitch resides. Port mapping is only applied when the access/ingress realm has registration caching and/or HNT enabled.

The range of SIP mapping ports must not overlap the following:

Configured SIP port, which might be used for signaling messages not associated with a registered endpoint.
Port range defined for steering pool configuration using the same IP address as the SIP interface. If overlap occurs, the NAT table entry for the steering port used in a call prevents SIP messages from reaching the host processor.
To configure SIP port mapping:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter to access the session-router path.
```
ORACLE(configure)# session-router
```
Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
```
port-map-start—Set the starting port for the range of SIP ports available for SIP port mapping. The valid range is 1025 through 65535. The default values is 0 and when this value is set, SIP port mapping is disabled. The valid range is:
- Minimum: 0, 1025
- Maximum: 65535
```
ORACLE(sip-interface)# port-map-start 32768
```
port-map-end—Set the ending port for the range of SIP ports available for SIP port mapping. The valid range is 1025 through 65535. If you set the value to the default 0, SIP port mapping is disabled. The valid range is:
- Minimum—0, 1025
- Maximum—65535
  
  Note:
  If not set to zero (0), the ending port must be greater than the starting port.
```
ORACLE(sip-interface)# port-map-end 40959
```
options—If you want to use SIP port mapping based on IP address, set the options parameter by typing options, a Space, the option name reg-via-key with a plus sign in front of it, type the equal sign and the word all. Then press Enter.
```
ORACLE(sip-interface)# options +reg-via-key=all
```
If you type the option without the plus sign, you will overwrite any previously configured options. In order to append the new options to this configuration’s options list, you must prepend the new option with a plus sign as shown in the previous example.

Save your work using the ACLI done command.

The following example shows SIP port mapping configured for a SIP interface:

sip-interface
        state                          enabled
        realm-id                       backbone
        sip-port
                address                        192.168.24.15
                port                           5060
                transport-protocol             UDP
                allow-anonymous                all
        sip-port
                address                        192.168.24.15
                port                           5060
                transport-protocol             TCP
                allow-anonymous                all
        carriers
        proxy-mode
        redirect-action
        contact-mode                   none
        nat-traversal                  none
        nat-interval                   30
        registration-caching           enabled
        min-reg-expire                 120
        registration-interval          3600
        route-to-registrar             enabled
        teluri-scheme                  disabled
        uri-fqdn-domain
        trust-mode                     agents-only
        max-nat-interval               3600
        nat-int-increment              10
        nat-test-increment             30
        sip-dynamic-hnt                disabled
        stop-recurse                   401,407
        port-map-start                 32768
        port-map-end                   40959
        last-modified-date             2005-09-23 14:32:15

SIP Port Mapping for TCP and TLS

In releases prior to S-C6.2.0, the Oracle® Enterprise Session Border Controller (E-SBC) supports SIP port mapping for UDP and now you can enable this feature for SIP sessions using TCP and TLS. Port mapping enables the E-SBC to allocate a unique port number for each endpoint registering through it by giving it a transport address (or hostport) in the registered Contact.

When you enable this feature for TCP and TLS, the E-SBC designates a port from a configured range for each endpoint that registers with SIP servers in the SIP interface’s realm. You establish that range of ports using the port-map-start and port-map-end parameters. Unlike its behavior with UDP port mapping—where the E-SBC sends requests on the SIP interface from the allocated port mapping, the E-SBC sends all requests over an existing connection to the target next hop for TCP/TLS port mapping. If a connection does not exist, the system creates one. So for TCP/TLS port mapping, only the Contact header contains the transport address of the mapping port (i.e., the transport address of the configured SIP port). And the system refuses TCP and TLS connections on the allocated mapping port.

With TCP/TLS port mapping enabled, the E-SBC sends the Path header with the transport address in Register requests, unless you specify that it should not do so. Standards-conformant SIP servers (that support RFC 3327) might attempt to send requests to the allocated mapping port if the Path header is absent.

Note:

ACL entries in the NAT table that permit TCP/TLS signaling for a SIP port configuration with TCP/TLS port mapping are the same as they would be for a TCP/TLS SIP port without port mapping enabled. Additional ACL entries that need to be set up for UDP port mapping are not required for TCP/TLS port mapping.

RTN 1684

SIP Port Mapping Configuration for TCP TLS

You enable TCP/TLS port mapping in a per-realm basis using the SIP interface configuration; setting the tcp-port-mapping value in the options parameter enables the feature. Enabling this parameter turns on the port mapping feature for UDP as well.

By default, the Oracle® Enterprise Session Border Controller includes the Path header in Register requests it sends from that SIP interface. If you do not this header to be included, however, you can set the value as tcp-port-mapping=nopath.

To enable TCP/TLS port mapping for a SIP interface:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type session-router and press Enter.

ORACLE(configure)# session-router
ORACLE(session-router)#

Type sip-interface and press Enter. If you are adding this feature to a pre-existing configuration, you will need to select and edit it.
```
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
```
options—Set the options parameter by typing options, a Space, the option name tcp-port-mapping with a plus sign in front of it, and then press Enter.
```
ORACLE(sip-interface)# options +tcp-port-mapping
```
If you type the option without the plus sign, you will overwrite any previously configured options. In order to append the new options to the realm configuration’s options list, you must prepend the new option with a plus sign as shown in the previous example.
Save your work.

Terminating Trunk Group URI Parameters and Formats

Terminating trunk group URI parameters appear in the R-URI, and they can be included in by a network routing element to instruct the Oracle® Enterprise Session Border Controller which egress trunk groups to use. By matching the trunk group URI parameter with configured session agents or session agent groups, the Oracle® Enterprise Session Border Controller can locate the terminating gateway. The trunk group name can also be expressed as the IP address of the terminating gateway.

The OCSBC inserting terminating trunk group URI parameters.

In the absence of official SIP standards for transporting trunk groups between signaling elements, the Oracle® Enterprise Session Border Controller allows you to define the URI parameters used in terminating trunk groups.

There are two available formats for the terminating trunk group URIs:

In compliance with the IPTEL draft, the first format has two parameters: tgrp (which can be either a trunk group name or an IP address) and trunk-context (defines the network domain of the trunk group). These appear in the following formats:
- tgrp=”trunk group name”
- trunk-context=”network domain”
  
  An example R-URI with terminating trunk group parameters appears as follows, where the tgrp is TG2-1 and the context is isp.example.net@egwy.isp.example.net:
```
INVITE sip:+15555551212;tgrp=TG2-1;trunk-context=isp.example.net@egwy.isp.example.net SIP/2.0
```
The second format is customized specifically for egress URIs and contains two provisioned parameters: tgrp (or tgname) and context (or tgdomain). This appears as tgrp.context (or tgname.tgdomain), where definitions apply:
- tgrp (tgname)—Provisioned trunk group name for the originating session agent; this value must have at least one alphabetical character, cannot contain a period (.), and can contain a hyphen (-) but not as the first or the last character
- context (tgdomain)—Name of the terminating trunk group context; this value can be up to twenty-four characters
  
  The use of multiple terminating trunk groups is not supported.
  
  The BNF for a single, egress URI with trunk group information conforms to:
```
SIP-URI = "sip:" [userinfo ] hostport uri-parameters [headers ]
uri-parameters = *( ";" uri-parameter )
uri-parameter = transport-param / user-param / method-param
			/ ttl-param / maddr-param / lr-param / other-param
other-param = egressid  / pname [ '=' pvalue ]
egressid = "egress=" egressURI
egressURI = scheme tgname ["." tgdomain]
scheme = "sip:" / token
tgname = ALPHA / *(alphanum) ALPHA *(alphanum / "-") alphanum /
	alphanum *(alphanum / "-") ALPHA *(alphanum) # up to 23 characters
tgdomain = *(domain ".") toplabel # up to 24 characters
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domain = alphanum/ alphanum *( alphanum / "-" ) alphanum
```
  For all trunk group URI support, you must set the appropriate parameters in the SIP manipulations configuration and in the session agent or session agent group configurations.
  
  In the originating trunk group URI scenario, a call arrives at the Oracle® Enterprise Session Border Controller from a configured session agent or session agent group. If this session agent or session agent group has the appropriate trunk group URI parameters and inbound manipulation rules configured, the Oracle® Enterprise Session Border Controller then looks to the SIP manipulations configuration and add the trunk group URI information according to those rules. Those rules tell the Oracle® Enterprise Session Border Controller where and how to insert the trunk group URI information, and the Oracle® Enterprise Session Border Controller forwards the call.
  
  In the terminating trunk group scenario, a call arrives at the Oracle® Enterprise Session Border Controller from, for instance, a call agent. This call contains information about what trunk group to use. If the information matches a session agent or session agent group that has outbound manipulation rules configured, the Oracle® Enterprise Session Border Controller will then look up the SIP manipulations configuration and strip information according to those rules. Those rules tell the Oracle® Enterprise Session Border Controller where and how to remove the information, and the Oracle® Enterprise Session Border Controller forwards the call.