SIP Module

Session Initiation Protocol (SIP) SIP Server Settings SIP Client Settings External Gateways NAT Traversal and Media Stream Proxy Near-End NAT Traversal Far-End NAT Traversal Edge Services Microsoft® Windows Messenger Support SIP Devices Support and Workarounds Routing Monitoring SIP Activity The CommuniGate Pro SIP Module implements the SIP Internet protocols via IP networks. The module is used to receive Signal Requests from remote entities, and to send Signals to remote entities. The SIP protocol does not include the protocols required for actual data transfer (media transfer protocols). Instead, the SIP protocol allows all participating parties to find each other on the network, to negotiate the media transfer protocol(s) and protocol parameters, to establish interactive real-time sessions, and to manage those sessions: add new parties, close sessions, update session parameters, etc.

Session Initiation Protocol (SIP)

The CommuniGate Pro SIP Module implements the SIP protocol functionality. The module uses TCP and UDP listeners to receive SIP request and response packets via these network protocols. It also sends the response and request packets via the TCP and UDP network protocols.

The SIP module parses all received SIP packets, and uses the module subcomponents to process the parsed packets. Request packets are submitted to the SIP Server subcomponent, to a new SIP Server transaction or to an existing one.
The SIP Server component uses the Signal Module to process the request. The responses generated with the Signal module are submitted to the SIP Server transaction, and the SIP Server sends them back to the source of the SIP request.

The Signal module can send a Request to a remote SIP device or to a remote SIP server. The module uses the SIP Client subcomponent to create a SIP Client transaction. This transaction is used to send a SIP Request via an Internet protocol, and to process the Responses sent back.

SIP Request packets received with the SIP Module are submitted to the SIP Server subcomponent, while SIP Response packets are submitted to the SIP Client subcomponent, with two exceptions:

• if no Client transaction can be found for a Response packet, the packet is relayed "upstream" by the SIP Module itself, without using the Signal module.
• if no Server transaction can be found for an ACK Request, a SIP Client transaction is created to relay the ACK Request "downstream".

The CommuniGate Pro SIP module supports UDP and TCP communications, and it also supports secure (TLS) communications over the TCP protocol.

The CommuniGate Pro SIP module supports near-end and far-end NAT traversal, enabling SIP communications for both large corporations with many internal LANs, as well as for home users connecting to the Internet via "dumb" NAT devices.

The session initiation schema described above works correctly only if both parties can communicate directly. If there is a firewall or a NAT device between the parties, direct communication is not possible. In this case, the CommuniGate Pro SIP module builds and manages media proxies, relaying not only the SIP protocol requests and responses, but the actual media data, too.

---

SIP Server Settings

To configure the SIP module, use a Web browser to connect to the CommuniGate Pro Server WebAdmin Interface, and open the SIP page in the Settings realm.
To configure the SIP module, you should have the Can Modify Settings access right.

Click the Receiving link to open the SIP Server (UAS) Settings.

Transport

The Transport panel allows you to configure the network-level options for SIP packet receiving:

Transport Log: Crashes OnlyFailuresMajor & FailuresProblemsLow-LevelAll Info UDP listener   TCP listener Input Channels: off135102550100250500100025003000500075009000other Idle Timeout: 5 seconds7 seconds10 seconds15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 days4 days5 daysweek

Log

Use this setting to specify the type of information about SIP packets and SIP transport the module should put in the Server Log. Usually you should use the Failure (unrecoverable problems only), Major (session establishment reports), or Problems (failures, session establishment and non-fatal errors) levels.
When you experience problems with the SIP module, you may want to set the Log Level setting to Low-Level or All Info: in this case the packet contents and other details will be recorded in the System Log. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.
The SIP module transport records in the System Log are marked with the SIPDATA tag.
Generic SIP information records have the SIP tag.

UDP

To configure the UDP transport, click the UDP listener link. The UDP Listener page will open. By default, the SIP UDP port is 5060.

TCP

To configure the TCP transport, click the TCP listener link. The TCP Listener page will open. There you can specify both secure and clear-text TCP ports. By default, the clear-text SIP TCP port is 5060, and the SIP TLS port is 5061.

Input Channels

Use this option to specify the maximum number of TCP communication channels the module can open. If the number is exceeded, the module will reject new incoming TCP connections.

Idle Timeout

Use this option to specify when the SIP module should close a TCP communication channel if there is no activity on that channel. This helps to reduce the resources used for TCP communication channels on large installations. On the other hand, some SIP clients may not function properly if the server closes its TCP connection on a time-out.

Transactions

The Transactions panel allows you to specify how the SIP Module handles SIP server (UAS) transactions.

Server Transactions Log: Crashes OnlyFailuresMajor & FailuresProblemsLow-LevelAll Info Limit: 1310301003001000300010000other Processors: 13571020301003001000300010000other

Log

Use the Log setting to specify what kind of information the SIP Server subcomponent should put in the Server Log. Usually you should use the Failure (unrecoverable problems only), Major (session establishment reports), or Problems (failures, session establishment and non-fatal errors) levels.
The SIP Server subcomponent records in the System Log are marked with the SIPS tag.

Limit

Use this setting to specify the maximum number of concurrent server transactions the SIP Module is allowed to handle.

Processors

Use this setting to specify the number of threads used to process SIP Server transactions.

Protocol

The SIP Module server component implements Request Authentication for remote clients. If an internal Server component rejects a Request because it does not contain authentication data, the Module adds special fields to the response it sends, facilitating authentication.

Protocol   Advertise Digest AUTH Advertise NTLM AUTH

Advertise Digest AUTH

Select this option to inform SIP clients that the standard DIGEST authentication method is supported.

Advertise Digest NTLM

Select this option to inform SIP clients that the non-standard NTLM authentication method is supported.

The user name specified in the authentication data is processed using the Router component, so Account Aliases and Forwarders, as well as Domain Aliases can be used in authentication names.
The specified Account and its Domain must have the SIP Service enabled.

All CommuniGate Pro Account passwords can be used for SIP authentication.

---

SIP Client Settings

To configure the SIP Client (UAC) settings, use the WebAdmin Interface to open the SIP Module Settings pages and click the Sending link.

Transport

The Transport panel allows you to configure the network-level options for SIP packet sending:

Transport Log: Crashes OnlyFailuresMajor & FailuresProblemsLow-LevelAll Info UDP Request Size Limit LAN: WAN:

Log

Use this setting to specify the type of information about SIP packets and SIP transport the module should put in the Server Log.
This is the same settings as the Transport Log Level setting displayed on the SIP Server settings page.

Request Size Limit

Use this option to specify the size for the largest UDP packet that can be sent within your LAN and outside your LAN. If the SIP module needs to deliver a packet and the protocol is not explicitly specified, the SIP module uses the UDP protocol, unless the packet size is larger than the specified limit. In the latter case the TCP protocol is used.

Transactions

The Transactions panel allows you to specify how the SIP Module handles SIP client (UAS) transactions.

Client Transactions Log: Crashes OnlyFailuresMajor & FailuresProblemsLow-LevelAll Info Limit: 1310301003001000300010000other Processors: 13571020301003001000300010000other

Log

Use the Log setting to specify what kind of information the SIP Client subcomponent should put in the Server Log. Usually you should use the Failure (unrecoverable problems only), Major (session establishment reports), or Problems (failures, session establishment and non-fatal errors) levels.
The SIP Client subcomponent records in the System Log are marked with the SIPC tag.

Limit

Use this setting to specify the maximum number of concurrent client transactions the SIP Module is allowed to handle.

Processors

Use this setting to specify the number of threads used to process SIP Client transactions.

Protocol

Protocol Force Dialog Relaying Relay to Non-Clients for: nobodyclientsnobody Relay via:

Force Dialog Relaying

If this option is disabled, the SIP Module introduces itself only into those SIP dialogs that require its participation (such as those involving NAT/Firewall traversal). If this option is enabled, the SIP module introduces itself into all SIP dialogs opened. This feature can be used for troubleshooting, as all details of dialog transactions are recorded in the Server Log.

Relay to Non-Clients

If this option is set to anybody, the SIP Module acts as an Open Relay: it relays any SIP request to any destination.
To prevent abuse of your server, allow relaying for clients only or for nobody.
The SIP Module will send Requests if at least one the following conditions is met:

• the destination address is listed as a Client IP address.
• the Request is being relayed to devices registered with some Account on your Server.
• the Request is generated by a Local Node (such as a PBX Task).
• the Request sender is authenticated with your Server.
• the Request is received from a network address listed in as a Client IP address (only if this option is set to clients).

If none of these conditions is met, the request is rejected with the 401 ("Authentication required") error code.

Relay via

Enable this option if you want to relay all outgoing packets via some external SIP server. Note that this setting is not used for addresses explicitly routed to external hosts using the .via suffix or other routing methods.

External Gateways

You may want to use your CommuniGate Pro Server with external SIP Gateways. External Gateways can be used to relay calls to the public telephony network (PSTN) and to relay PSTN calls to your Server. These services are usually fee-based and communications with External Gateways may require authentication.
You can also use the External Gateways features if you need to communicate with remote SIP networks using authentication.

Note: if you use an in-house PSTN gateway, it is usually configured to accept all calls from within your LAN (so your Server does not need to use Authentication to relay call Signals to that gateway), and that gateway can be configured to direct incoming connections to a certain CommuniGate Pro Server Account (so there is no need to register your Server with that gateway). In this case you can employ this PSTN gateway without using the External Gateways features.

Use the External Gateway panel to specify the Gateway settings:

Gateway Name: Calls: Authenticate: DisabledAuthProxy-Auth Substitute: From To Username: Domain: Via: Auth Name: Password: Every: never10 seconds15 seconds30 seconds45 secondsminute90 seconds2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour90 minutes2 hours3 hours6 hours12 hoursday2 days3 days Contact:

Gateway Name

Use this setting to assign an internal name to this External Gateway. You will use that name in the Router records to address certain calls to this Gateway. Assign a unique alphanumeric name to each External Gateway you will use.

Domain

Use this setting to specify the External Gateway domain name.

Via

Use this setting if the requests for this External Gateway should not be sent to the network addresses associated with the Gateway Domain name (for example, requests sent to this Gateway should be sent via some proxy).
This setting allows you to specify an alternative domain (DNS) name, an IP address, or a complete SIP URI.

Username

Use this setting to specify a name to be used to register on and (optionally) to call via this External Gateway.
If the value does not contain the @ symbol, the Domain setting is added to form a quialified username.

Password

Use these settings to specify the password to use with the External Gateway.

AuthName

Specify this setting only when the Authentication name to be used with the External Gateway is not the same as the UserName.

Register every

Use this setting to specify how often the SIP Module should send REGISTER Requests to this External Gateway.

Contact

Use this setting to specify the address to be registered with the External Gateway. When a gateway receives an incoming call, it sends the call Signal request to the specified address.
This Contact address usually is an Account on your Server that employs an "auto-attendant" Real-Time Application to answer these calls and to direct them to other Accounts on your Server.

Calls: Authenticate

When this option is not disabled, an authentication header field (Authorization or Proxy-Authorization) is added to all call (INVITE) requests sent to this External Gateway. The Module employs the authentication "nonce" used for the last REGISTER request sent to the Gateway, so make sure your Register Every time period is shorter than the nonce "Time To Live" period of this External Gateway.

Calls: Substitute From

When this option is selected, the From addresses (the caller name and address) of call Signal (INVITE) requests are substituted with the Username (caller masquerading).

Calls: Substitute To

When this option is selected, the To addresses (the caller name and address) of call (INVITE) requests are substituted with the Signal request URI (after removing URI port number and URI parameters).

To create a new External Gateway entry, enter the Gateway Name in the last, empty table element, and click the Update button.

To remove an External Gateway entry, enter an empty string into its Gateway Name field, and click the Update button.

In order to send Signal requests to the External Gateway, you need to specify Router records.

Sample 1.

All calls to 1number@main_domain should be directed to the Provider1 Gateway as requests to call number
All calls to +1number@main_domain should be directed to the Provider1 Gateway as requests to call number
all calls to +number@main_domain (where number does not start with 1) should be directed to the IntlProvider Gateway as requests to call 011number
all calls to 011number@main_domain should be directed to the IntlProvider Gateway as requests to call 011number
all calls to 9number@main_domain should be directed to the LocProvider Gateway as requests to call 415number

Use the following Router records:

NoRelay:Signal:<1*>   = *@Provider1.sipgw
NoRelay:Signal:<+1*>  = *@Provider1.sipgw
NoRelay:Signal:<+*>   = 011*@IntlProvider.sipgw
NoRelay:Signal:<011*> = 011*@IntlProvider.sipgw
NoRelay:Signal:<9*>   = 415*@LocProvider.sipgw

Note: you should use the NoRelay: prefix to avoid turning your Server into an open relay that would allow any external user to relay calls to the External Gateway using your Server credentials.

NAT Traversal and Media Stream Proxy

The "original, "basic" SIP communication model assumes that endpoints can communicate directly, i.e. that all "elements", including SIP clients - phones, softphones, PBX applications), and SIP servers have "real" Internet IP Addresses. In this situation the Server (SIP Proxy) is needed only to establish a call. Media data and in-call signalling requests are sent directly between the endpoints:

CommuniGate Pro supports automatic "NAT traversal" for the standard-based real-time communications.

Near-End NAT Traversal

The CommuniGate Pro SIP Module detects the session initiation requests that are sent from one side of NAT to the other side (a request from a LAN client to a party on the Internet/WAN and vice versa). In this case, the Server uses some local server port (or a set of ports depending on the media protocol(s) used) to build a media stream proxy. The Server then modifies the session initiation request to direct the traffic from both sides to that proxy. The media proxy relays media data between the "LAN leg" and the "WAN leg" of the media connection:

The CommuniGate Pro SIP Module detects session re-INVITE requests as well as BYE requests and update and removes the session proxies accordingly. The time-out mechanism is used to remove "abandoned" media proxies.

The CommuniGate Pro provides NAT proxy services for:

• UDP media protocols
• RTP media protocols based on UDP
• TCP media protocols
• T.120 media protocols based on TCP

Note: If you need the Media Stream Proxy functionality, make sure that the LAN and NAT data is specified correctly on the LAN IPs settings page.

Far-End NAT Traversal

The CommuniGate Pro SIP Module also provides the "far-end" NAT traversal capabilities by detecting requests coming from clients located behind remote Firewall/NATs.
The Module adds appropriate Record-Route and Path headers to these requests and it builds media proxies to relay traffic to and from those clients.

Note: modern SIP clients support various NAT traversal methods (STUN, etc.). Many of these implementations are quite buggy, so it is often more reliable to switch the client-side NAT traversal methods off, and rely on the CommuniGate Pro SIP Module far-end NAT traversal capabilities instead.

Note: due to the nature of the TCP protocol and the Firewall concept, it is not possible (in general) to open a TCP connection to a client behind a far-end NAT ("near-end" NAT configurations do not have this problem). This means that clients behind a far-end NAT cannot initiate TCP (T.120) sessions. To solve this problem, you may want to:

• always initiate TCP sessions from a client that is not behind a far-end NAT/Firewall (these clients accept those invitations and start outgoing TCP connections without a problem)
  or
• use an additional copy of the CommuniGate Pro Server on that remote location as a near-end NAT traversal solution for that network, eliminating a need for far-end NAT traversal on the "main" CommuniGate Pro server
  or
• configure the remote Firewall/NAT to relay all incoming TCP request to the T.120 port (usually, the port 1503) to a particular workstation behind that Firewall.

Edge Services

The CommuniGate Pro SIP Module can be used as an "Edge Service" or ALG ("Application Level Gateway"), providing NAT traversal functionality for users registered on other servers.

The CommuniGate Pro SIP Module detects "media loops", when a call placed from within LAN is proxied to WAN, and then proxied back to the same LAN. In this case the Media Proxies are removed, eliminating unnecessary overhead, and allowing SIP clients to communicate directly within one LAN, while proving registrar services outside that LAN.

The SIP module can detect much more complex loop cases, either avoiding Media Proxies altogether, or minimizing the number of Media Proxies used.

Microsoft® Windows Products Support

The Microsoft "RTC" products (including Windows Messenger) use the standard SIP protocol for audio and video sessions.
These clients use the proprietary SIP protocol extensions for Instant Messaging, Presence, Whiteboard, Remote Assistance and other services. CommuniGate Pro implements the extensions required to support these applications.

The Windows Messenger versions prior to 5.0 are not supported.

The CommuniGate Pro SIP module should have the Advertise NTLM option enabled.

The Windows Messenger audio and video sessions use standard RTP media protocols and these sessions can be used over a NAT/Firewall.
The Windows Messenger Instant Messaging uses the SIP protocol for media transfer and Instant Messaging sessions can be used over a NAT/Firewall.
The Windows Messenger Whiteboard, Application Sharing, and Remote Assistance sessions use T.120 and non-standard protocols and these sessions can be used over a NAT/Firewall.
The Windows Messenger File Transfer sessions use a non-standard protocol and these sessions currently cannot be used over a NAT/Firewall.

SIP Devices Support and Workarounds

Many currently available SIP devices and applications incorrectly implement various aspects of the SIP protocol.
The CommuniGate Pro SIP Module tries to compensate for certain client problems and bugs, based on the type of SIP devices connected to it.

Open the SIP Module settings and click the Workarounds link. A table appears:

Problems/Bugs
Agent Name Microsoft SubPresence NoTCP NoMaddr NoPath BadByeAuth NeedsEpid

To specify workarounds for a certain product, put the product name into the last, empty Table element, select the required workarounds and click the Update button.

To remove a certain product, remove its name from the table, and click the Update button.

A similar table exists for remote sites:

Problems/Bugs
Domain Name Microsoft SubPresence NoTCP NoMaddr NoPath BadByeAuth

When the SIP module is about to relay a Signal request to a remote destination, it applied the workaround methods specified for the request URI domain as well as the methods specified for the target URI domain.

The currently implemented workaround methods are:

Microsoft

The entity is a Microsoft client. Protocol messages are signed, and other SIP protocol derivations are processed.

SubPresence

The entity supports Presence, but does not implement a push-type Presence Agent (Publish). The Server will send SUBSCRIBE requests to monitor the entity Presence status.

noTCP, noMaddr

The entity does not support transport and/or maddr Contact parameters. The Server will modify the Contact data sent to this entity.

noPath

The entity does not support the RFC3327 (Path fields). The Server will modify the Contact data sent to this entity.

badByeAuth

The entity incorrectly calculates Authentication digests for non-INVITE (BYE, NOTIFY, REFER) requests.

needsEpid

The entity uses a non-standard epid= parameter in its From/To URIs and fails to work if the peer does not preserve this non-standard parameter.

The following Web Site contains a periodically updated document listing the tested SIP Clients, the problems discovered and the known workarounds.

Routing

The SIP module immediately (on the first Router call) accepts all signal addresses with IP-address domains, i.e. with domain names like [xx.yy.zz.tt]. Please note that the Router adds brackets to the IP-address domain names that do not have them, and the Router changes the IP addresses of local domains to those domain names. The Router performs these operations before calling the modules.

The SIP module immediately accepts all signal addresses with domain names ending with the .sipgw suffix. The rest of the domain name should specify the name of an External Gateway and the Signal is routed to that External Gateway.

On the final call, the SIP module accepts signal to any domain if that domain name contains at least one dot (.) symbol. If the Relay via option is selected, all these addresses are rerouted to the specified Relay via domain.

Before accepting an address, the SIP module checks if the address does not contain any @ symbol, but contains one or several % symbols. In this case, the rightmost % symbol is changed to the @ symbol.

If the target domain name contains a .udp, .tcp, or .tls suffix, the corresponding transport protocol is used, and the suffix is removed from the target domain name.

Monitoring SIP Activity

The Monitors realm of the WebAdmin Interface allows Server Adminstrators to monitor the SIP module activity. The SIP Monitor page contains two frames - the receiving (Server) frame, and the sending (Client) frame.

The SIPS frame displays the active SIP Server transactions:

SIPS Elements:2
ID	Status	Msgs	Phase	Source	Target	Info
38984	waiting (15s)	0	completed	udp[10.10.0.226:59645]	SIGNAL-40726	OPTIONS sip:ns.stalker.com
38994	waiting (7s)	0	completed	tcp[10.0.14.193:24777]	SIGNAL-40734	MESSAGE sips:user@stalker.com

The SIPC frame displays the active SIP Client transactions:

SIPC Elements:2
ID	Status	Msgs	Phase	Source	Target	Info
35184	waiting (2m)	0	provisioned	SIGNAL-40726	udp[10.0.1.34:5060]	INVITE sip:user@10.0.1.34:5060
35188	waiting (7s)	0	request sent	SIGNAL-40732	udp[10.0.1.34:5060]	MESSAGE sips:user@stalker.com