Jump to: navigation, search

Migrating from Network SIP Server to SIP Server

If you have been using Network SIP Server (version 7.5 or earlier) for a while, you might consider migrating your environment to use 8.1.1 SIP Server that offers more capabilities. This article describes differences between the two components (Network SIP Server and SIP Server), and describes migration use cases, with migration steps, that might apply to your environment.

Network SIP Server was the first Genesys application supporting the Session Initiation Protocol (SIP). Network SIP Server is used for load balancing among premise SIP Servers. It utilizes simple functionality that can be summarized as follows:

  1. Network SIP Server receives a SIP INVITE message from SIP media gateways.
  2. Based on that INVITE, Network SIP Server generates EventRouteRequest containing T-Library attributes with elements of the INVITE message that Network SIP Server maps into that event.
  3. Network SIP Server receives RequestRouteCall from a routing application.
  4. Network SIP Server sends a 302 response to the INVITE message. The Contact of that request is the same as AttributeOtherDN of RequestRouteCall.
  5. When it receives a SIP ACK message, Network SIP Server generates EventRouteUsed, which matches corresponding RequestRouteCall.

Feature differences between Network SIP Server and SIP Server

How Network SIP Server features are supported in SIP Server

Functionality Of Network SIP Server

Current Support in SIP Server

Comments

1 Receiving the incoming INVITE and generating EventRouteRequest based on that Supported with some difference in the interface Attributes of the Event in SIP Server and Network SIP Server are mapped differently. All the information presented by Network SIP Server can be delivered by SIP Server; however some configuration and URS strategies might need be changed.
2

Responding to INVITE with 302

Supported with some difference in the interface SIP Server cannot put the Contact value of AttributeOtherDN from TRouteCall into the 302 message as is. SIP Server instead applies matching rules to the value of OtherDN (evaluating internal DN or Trunk DN prefixes, or dial plans).
3 Option load-balancing=yes Not supported, but there is a workaround. Network SIP Server in this mode ignores the username of the URI in the incoming INVITE and distributes EventRouteRequest in a round-robin fashion among configured routing points. SIP Server does the opposite, always matching the username to available routing points. Some special configuration is required to enable sending any call to a default routing point in spite of the value of the username.
4 Option load-balancing=no Supported Network SIP Server (and SIP Server) distributes EventRouteRequest on the routing point that matches the username of the URI in the incoming INVITE.
5 Option sip-port Supported Value of sip-port is configurable for both applications.
6 Option t1-timeout Not supported Value of the SIP T1 timeout is hard-coded to 500 ms in the SIP library.
7 Option t2-timeout Not supported Value of the SIP T2 timeout is hard-coded to 4000 ms in the SIP library.
8 Option router-timeout Supported Supported by both applications.
9 Option udp-packets-to-read Not supported
10 Option udp-packets-to-write Not supported
11 Option udp-recvbuf Not supported Currently, SIP Server uses the default size of the buffer, which is 8 KB for Windows. Increasing this value up to 128 KB is known to improve performance for a highly loaded application. This can be done at the OS level.
12 Option udp-sendbuf Not supported SIP Server sets the size of the send buffer to 1 MB. The value is hard-coded.
13 Option enable-sip-port-on-backup Not supported Initially, Network SIP Server did not close the sip-port on backup assuming that the script performing an IP address takeover will take care the SIP traffic. Now, to support a more reliable switchover, the option was added for backward-compatibility. SIP Server always closes the sip-port on the backup server.
14 Mapping values of AttributeExtensions to 302 Not supported Both applications use the same key SIP_HEADERS to define which key-value pairs to map into a SIP routing message. SIP Server supports it only for routing a call by INVITE or REFER (but not for a 302 response). SIP Server cannot map key-value pairs from the RequestRouteCall AttributeExtensions as additional headers of a 302 response.
15 Option resolve-sip-address Supported If set to true, Network SIP Server resolves the host name provided by TRouteCall into an IPv4 address. SIP Server does the same.
16 Option default-routing-destinations Not supported This option provides a list of default URIs to which the server redirects incoming calls (selecting them on a round-robin fashion) if URS is down.
17 Support of OPTIONS request Supported Supported the same way for both applications.
18 Option final-timeout Not supported Network SIP Server keeps a SIP call in memory within this timeout. SIP Server removes a call from memory right after its redirection or rejection. So, any incoming INVITE with the same SIP Call-ID will be treated as a new call.
19 Option num-of-rerouting Not supported SIP Server cannot limit re-routing attempts for the same SIP Call-ID.

Differences in mapping of INVITE elements into EventRouteRequest attributes

Attribute

Network SIP Server

SIP Server

AttributeOtherDN Contact URI From Username
AttributeDNIS To URI To Username
AttributeANI From URI From Username
AttributeExtensions Controlled by the Extensions application-level section Controlled by the INVITE application-level section
AttributeUserData Not supported Controlled by the INVITE application-level section

Network SIP Server maps basic data from INVITE headers to EventRouteRequest attributes as full URIs. SIP Servers maps the same data as usernames. It is unlikely that a URS strategy relies on attributes that are presented by Network SIP Server. However, Genesys recommends reviewing URS strategies during migration. If a strategy expects a URI, configure the INVITE section of the SIP Server application.

In addition to basic attributes, INVITE elements can be configured to be mapped as key-value pairs into AttributeExtensions. Configurations are different but the result is similar. In Network SIP Server, the Extensions application-level section is used. In SIP Server, the INVITE application-level section is used. SIP Server can distribute everything that Network SIP Server can. SIP Server can also distribute INVITE elements as UserData key-value pairs.

Differences in mapping RequestRouteCall attributes

Attribute

Network SIP Server

SIP Server

AttributeOtherDN Contact URI is mapped as is in a 302 message Target DN that is resolved as the Contact in a 302 message by configuration or a dial plan.
AttributeExtensions (key SIP_HEADERS) Any key-value pair of AttributeExtensions can be mapped in a custom header of the 302 message Not supported for a 302 message. Supported only for INVITE and REFER messages.

Migration Use Cases

Two general migration use cases are covered in this section:

Network SIP Server routes calls to SIP Server through ISCC (route type =route) with load balancing off

When load balancing is turned off, Network SIP Server matches the username of the incoming INVITE Request-URI to an available routing point and distributes EventRoutePoint only if there is a successful match. SIP Server does exactly the same.

Here is an example of Network SIP Server actions before the migration:

  1. A call is routed from a routing point of Network SIP Server to the routing point on a premise SIP Server using the External Routing Point on the premise server as an intermediate target.
  2. URS sends RequestRouteCall with AttributeLocation of the premise destination switch.
  3. AttributeOtherDN of that request is formed as a regular DN (routing point on the premise SIP Server).
  4. To provide the origination server with the target in the form acceptable by Network SIP Server, External Routing Points on premise SIP Servers are configured with the Use Override property. The value of this property consists of the entire SIP URI with the Username equal to the name of the External Routing Point and the hostport equal to the SIP address of the premise SIP Server.

Migration includes the following steps:

  1. Creating new Application objects for SIP Server
  2. Connecting new applications with their peer applications
  3. Modifying Network Switch Access Code
  4. Configuring Trunk DN objects for inbound gateways
  5. Configuring Trunk DN objects for destination trunks
  6. Modifying External Routing Point DN objects on destination switches

Creating new Applications objects for SIP Server

Create two new Application objects (for high availability) using the SIP Server application template. Most of the default application parameters will work correctly for SIP Server running in redirect mode. Ensure the following options are configured:

  • sip-link-type=0
  • ringing-on-route-point=false
  • sip-address= <IP address or host name of the host where SIP Server will be running>
  • sip-port = <port used to receive SIP messages>

Configure the new SIP Server applications to work in Warm Standby HA mode.

Use the existing Switch object to associate it with these new applications.

Connecting new applications with their peer applications

Connections of the new applications must replicate Network SIP Server existed connections. You might want to review existing connections to remove the obsolete ones.

Modifying Network Switch Access Code

In the Access Codes tab of the Network SIP Server Switch Properties window, configure a unique Code for each destination switch. In the example, the Code is set to ERP1.

Nsips-access-code.png

Configuring Trunk DN objects for inbound gateways

Configure a DN object of type Trunk for each inbound gateway in your environment, with the following configuration options for each Trunk DN:

  • contact—Set to the IP address of the corresponding inbound gateway.
  • oosp-transfer-enabled—Set to true.
  • prefix—Set to a value different from any access codes configured in Modifying Network Switch Access Code. That will guarantee that this trunk will not be used for call routing to the destination.
Nsips-inbound.png

Configuring Trunk DN objects for destination trunks

Configure a DN object of type Trunk for each destination SIP Server in your environment, with the following configuration options for each Trunk DN:

  • contact—Set to the IP address of the corresponding destination SIP Server.
  • oosp-transfer-enabled—Set to true.
  • prefix—Set to the same value as the access code configured for the switch.
  • replace-prefix—Set to an empty value. That will guarantee that an access code provided by ISCC will be used to find a proper SIP address of the destination SIP Server but will not be included into the URI username of a SIP 302 message.
Nsips-iscc-trunk.png

Modifying External Routing Point DN objects on destination switches

Network SIP Server used the Use Override property to provide the entire URI as AttributeOtherDN of the ISCC RequestRouteCall. Selection of the Use Override property is no longer required. SIP Server resolves a DN into the URI through the Switch's Trunk DNs configuration.

Nsips-externalRP.png

Migration of deployments with load balancing

When Network SIP Server is used for load-balancing it means that:

  • Network SIP Server does not attempt to match the username of the incoming INVITE Request-URI. It distributes EventRouteRequest to the available routing point.
  • Routing points are selected in a round-robin fashion, so any consecutive event is distributed to a different DN.

To satisfy the first bullet point, the Alternate Routing for Calls to an External Destination feature must be enabled in SIP Server. The SIP Server switch must not have any internal resources that match possible usernames in the INVITE Request-URI and the From header. In that case, a call is qualified as an inbound call to be routed to an external destination. SIP Server sends the call to a routing point defined by the default-route-point option.

If an incoming call rate is too high for a single routing point to handle, you can create a fast strategy, which will provide a round-robin call distribution among additional configured routing points.

Performance Considerations

The SIP Server Sizing Tool is a spreadsheet providing for the input of sizing parameters to calculate CPU usage and network bandwidth of a SIP Server application. Use this tool to calculate CPU usage and network bandwidth of SIP Server that has replaced the former Network SIP Server.

The Input & Calculation(Redirect) tab of the Tool is dedicated to the sizing of SIP Server working as a SIP redirect application.

The Tool is located on this page: https://docs.genesys.com/Documentation/SIPS.

Examples of EventRouteRequest for Network SIP Server and SIP Server

INVITE sip:8001@172.21.83.50:5060 SIP/2.0
From: <sip:29111@172.21.83.50:29111>;tag=6CA770E8-0266-415F-A118-CEB42F39C605-1
To: sip:8001@172.21.83.50:5060
Call-ID: 082D1164-7D88-4863-8701-40FCA11340F8-1@172.21.83.50
CSeq: 1 INVITE
Content-Length: 145
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.21.83.50:29111;branch=z9hG4bK57EEFBEE-F235-45FD-924A-C941A9D1942D-1
Contact: <sip:172.21.83.50:29111>

v=0
o=PhoneSimulator 1 1 IN IP4 172.21.83.50
s=incoming INVITE
c=IN IP4 172.21.83.50
t=0 0
m=audio 39111 RTP/AVP 0
a=rtpmap:0 PCMU/8000/1

Network SIP Server: 

	
@16:54:59.9870 [0] 7.5.000.23 distribute_event: message EventRouteRequest
    AttributeEventSequenceNumber    0000000000000007
    AttributeTimeinuSecs    987000
    AttributeTimeinSecs    1504914899 (16:54:59)
    AttributeExtensions    [53] 00 01 00 00..
        'From:tag'    'E009AE79-BFB2-408B-AD4D-CF3F908FEA82-1'
    AttributeOtherDN    '172.21.83.50:29111'
    AttributeThisDNRole    2
    AttributeThisQueue    '8001'
    AttributeThisDN    '8001'
    AttributeCustomerID    'gregb'
    AttributeANI    '29111@172.21.83.50:29111'
    AttributeDNIS    '8001@172.21.83.50:5080'
    AttributeCallUUID    'KB7JRPUN5P1D12AK6V7SNCQJC4000001'
    AttributeConnID    04f402aacccd3001
    AttributeCallID    1
    AttributePropagatedCallType    2
    AttributeCallType    2

SIP Server: 

@16:01:19.3540 [0] 8.1.102.XXX_Debug distribute_event: message EventRouteRequest
    AttributeEventSequenceNumber    0000000000000037
    AttributeTimeinuSecs    354000
    AttributeTimeinSecs    1505430079 (16:01:19)
    AttributeExtensions    [135] 00 03 00 00..
        'OtherTrunkName'    'trunk_29111'
        'From'    '<sip:29111@172.21.83.50:29111>;tag=6CA770E8-0266-415F-A118-CEB42F39C605-1'
        'BusinessCall'    1
    AttributeOtherDNRole    1
    AttributeOtherDN    '29111'
    AttributePartyUUID    'JTNRVQG16D2FBEV53LIVKD6AB0000003'
    AttributeThisQueue    '8001'
    AttributeThisDNRole    2
    AttributeThisDN    '8001'
    AttributeANI    '29111'
    AttributeDNIS    '8001'
    AttributeCallUUID    '1VJ3ICNE8D4HLBAJ7TRPDIMF84000001'
    AttributeConnID    006c02ab4a93f001
    AttributeCallID    16777217
    AttributePropagatedCallType    2
    AttributeCallType    2
    AttributeCallState    0
This page was last edited on January 6, 2022, at 05:57.
Comments or questions about this documentation? Contact us for support!