 |
Version 6.1 |
|
|
SIP Module
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.
|
|
|
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 media data, too.
Use the WebAdmin Interface to configure the SIP module.
Open the Real-Time pages in the Settings realm, then open the SIP pages.
Click the Transport link to open the SIP Transport Settings.
The Transport panel allows you to configure the network-level options for SIP packet receiving:
- Log Level
- 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.
- Enqueuers
- When this option is set to a non-zero value, received packets are not processed immediately: they are placed into a
special queue and the receiving thread becomes ready to receive a new packet immediately. The option specifies a number
of additional threads that take packets from that queue and process them, sending them to Server or Client SIP transactions.
- Enqueued Limit
- When packets are not processed immediately, but placed into a special queue first (see above), this option limits the
size of that queue. When the number of packets in the queue exceeds this limit, new received packets are dropped.
You may want to increase the number of Enqueuers in this situation.
Use the WebAdmin Interface to configure the SIP module.
Open the Real-Time pages in the Settings realm, then open the SIP pages.
Click the Receiving link to open the SIP Server (UAS) Settings.
The Transactions panel allows you to specify how the SIP Module handles SIP server (UAS) transactions.
- 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.
- Processors
- Use this setting to specify the number of threads used to process SIP Server transactions.
- Object Limit
- Use this setting to specify the maximum number of concurrent server transactions
the SIP Module is allowed to handle. When this number is exceeded, incoming SIP packets with new requests are dropped.
- Event Limit
- Use this setting to specify the maximum number of unprocessed events sent to all active SIP server transactions.
If this number is exceeded, the SIP Server component is overloaded: no new SIP server transactions can be created, and incoming SIP packets with new requests are dropped.
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.
- 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.
If the CommuniGate Password option is enabled for the specified Account, the SIP module
checks if the Account has the SIPPassword setting. If it exists, it is used instead
of the standard Password setting. This feature allows an Administrator to assign
a alternative Account password to be used for the SIP authentication only.
- Send '100 Trying' for non-INVITEs
- If this option is enabled and the client resends a request, the SIP module sends the 100 ("Trying") response even in the request method is not INVITE.
- Always Send '100 Trying' for INVITEs
- If this option is enabled, the SIP module always sends the 100 ("Trying") response before it starts to process an INVITE request.
The SIP Module server component implements several protection techniques:
- UDP packets and TCP connections from Network IP Addresses included into the Denied Addresses
list are dropped without processing.
- When the number of misformed SIP packets received from some Network IP Address address exceeds the specified frequency limit,
that Address is added to the Temporarily Blocked Addresses list.
- When a SIP request is rejected because of some authentication error, the response is sent after some delay, and
the sender Network IP Address is added to the Temporarily Blocked Addresses list
if the number of the authentication errors associated with that Address exceeds the specified frequency limit.
- When a SIP request received from Network IP Addresses included into the Temporarily Blocked Addresses list,
they are dropped without processing.
Use the WebAdmin Interface to configure the SIP module.
Open the Real-Time pages in the Settings realm, then open the SIP pages.
Click the Sending link to open the SIP Client (UAC) Settings.
Transport
The Transport panel allows you to configure the network-level options for SIP packet sending:
- 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.
- UDP 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.
- UDP TOS Tag
- Use this setting to specify the TOS tag for all outgoing SIP UDP packets.
This tag can be used to set the SIP traffic priority on your LAN.
- Use Short Field Names
- If this option is enabled, all SIP packets (client requests and server responses) the Server generates will use
alternative (1-symbol) packet header field names. You may want to enable this option to decrease packet sizes.
Transactions
The Transactions panel allows you to specify how the SIP Module handles SIP client
(UAS) transactions.
- 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.
- Processors
- Use this setting to specify the number of threads used to process SIP Client transactions.
- Object Limit
- Use this setting to specify the maximum number of concurrent client transactions
the SIP Module is allowed to handle.
- Event Limit
- Use this setting to specify the maximum number of unprocessed events sent to all active SIP client transactions.
If this number is exceeded, the SIP Client component is overloaded, and no new SIP client transactions can be created.
Protocol
- 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.
- Timer B
- This option controls the value of the "Timer B" (specified in RFC3261). It controls the
maximum time the INVITE-type transaction will wait for any first response from the called party.
While the standard specifies the 32 seconds value, we strongly recommend to lower this value
to 5-10 seconds: if the remote party does not provide any answer within that time (not even the 100-Trying
response), most likely it is down and there is no need to wait for 32 seconds before reporting this
to the call originator.
Lowering this time allows the SIP Client transaction to try other SRV records (if any exists): if this
timer is set to 32 seconds, the calling user is likely to give up before the next SRV record is tried.
- 487-Wait Timer
- When a SIP transaction is client, a CANCEL request is generated and sent. This setting specifies
for how long the Module should wait for a 487-response from the client.
If no response is received, the Module generates the 487-response itself.
- Send P-Asserted-Identity
- If this option is enabled, and the request sender is authenticated, a P-Asserted-Identity field
is added to the SIP request sent. The field contains a SIP URI with the authenticated Account full name
(sip:accountName@domainName).
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.
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.
Use the WebAdmin Interface to configure the SIP workarounds.
Open the Real-Time pages in the Settings realm, then open the SIP pages.
Click the Workarounds link. The Workarounds table appears:
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:
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.
- NoSubMWI
- The entity supports the Message-summary Event package (to implement MWI - Message Waiting Indicator), but it
fails to send SUBSCRIBE requests to activate this service.
The Server will subscribe the client on registration.
- TCPPing
- When this entity sends a REGISTER request over a TCP connection from a NAT'ed network, do not start to send
the PING packets to that entity. Instead, enable the "Keep Alive" option for the request TCP connection.
Note: most OS have very long time-outs for the "Keep Alive" option. If you plan to use this workaround, it is recommended to decrease these timeouts in the Server OS to 1-3 minutes.
- badUpdate
- The entity advertises support for the SIP UPDATE method, but it incorrectly processes SIP UPDATE requests.
The following Web Site contains a periodically updated
document listing the tested SIP Clients,
the problems discovered and the known workarounds.
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.
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.
The Monitors realm of the WebAdmin Interface allows
Server Administrators 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:
The SIPC frame displays the active SIP Client transactions:
CommuniGate® Pro Guide. Copyright © 1998-2015, Stalker Software, Inc.