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.
ActiveHold: The entity has problems with switching media flow from the default bi-directional (sendRecv) to any other mode or back. The Server will leave the media state in the (sendRecv) mode even when the media state requested by a local PBX application or bridged peer is inactive or one-way.
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 "K