Important Announcement!

This edition of The Commetrex Outlook will focus on the three major architectural features of our recently announced SIPfaxEngine, each of which, we believe, is reason enough to select this license technology for your OEM development. But first, an important announcement:

We Moved!

Not a big deal, it is just across the street. Our lease expired and our property manager politely said she wasn’t going to renew our lease so our neighbor with the suites on both sides of us could expand into our suite. So, we’re in an all-new suite. Our new address is:

Commetrex Corporation
1100 Northmeadow Parkway
Suite 116
Roswell, GA 30076

All else is the same. Please update your records.

Want to know more? E-mail us at

OpenMMTF Leads the Way

Commetrex has developed fax technologies serving the telecom-equipment developer for over two decades, resulting in a rich library of major system components:

PortableT30® (P30) and the Fax Modem Bundle provide PSTN fax termination.

PowerRelay for T.38 implements the ITU recommendation for real-time IP fax. And TerminatingT38™ combines P30 and PowerRelay to support real-time terminating fax on IP media servers.

Multi-Modal Terminating Fax (MMTF) is an integration of all of these major system components to create a system that allows a media server to terminate faxes from PSTN-IP gateways supporting either T.38 or G.711 pass-through for fax transmissions.

MMTF was the reference standard in the T.38 Interoperability Lab in 2002-2004, and is still widely considered to be the industry’s T.38 benchmark standard to this day.

Learn How to Integrate MMTF today!

pjSIP For Call Control

In the May issue of The Commetrex Outlook, we announced SIPfaxEngine, licensed technology that integrates SIP call control and Commetrex’ industry-best Multi-Modal Terminating Fax (MMTF) to form the technology core of a highly scalable and robust fax server. After much study, we decided to use pjSIP from Teluu and purchased a commercial license for this widely deployed SIP and communications package. We are very pleased with this open-source product.

Since 2005, pjSIP has been developed, maintained, and supported by the same core team; it is compact, and has an excellent reputation for stability and scope. Our license included 12 months of support, but we have only asked Teluu one question in 10 months.

Our initial release of SIPfaxEngine will use pjSIP as a fax-server call-control resource. But OEMs will be able to benefit from our choice and use any of the myriad features included in the package. For example:

SIP Capabilities

Base specs:
o Digest authentication (RFC 2617)

o UDP, TCP, TLS (server or mutual)
o DNS SRV resolution (RFC 3263)
o IPv6


o rport (RFC 3581)
o Service-Route header (RFC 3608)
o SIP outbound for TCP/TLS (RFC 5626)
o Path header (with SIP outbound) (RFC 3327)


o Offer/answer (RFC 3264)
o hold, unhold
o redirection
o transfer/REFER (attended and unattended):

 Base (RFC 3515)
 replaces (RFC 3891)
 Referred-by (RFC 3892)

o sipfrag support (RFC 3420)
o norefersub (RFC 4488)
o UPDATE (RFC 3311)
o 100rel/PRACK (RFC 3262)
o tel: URI (RFC 3966)
o Session Timers (RFC 4028)
o Reason header (RFC 3326, partially supported)
o P-Header (RFC 3325, partially supported)

o RFC 2327 (obsoleted by RFC 4566)
o RTCP attribute (RFC 3605)
o IPv6 support (RFC 3266)

Multipart (RFC 2046, RFC 5621)

Presence and IM:
o Event framework (SUBSCRIBE, NOTIFY) (RFC 3265)
o Event publication (PUBLISH) (RFC 3903)
o MESSAGE (RFC 3428)
o typing indication (RFC 3994)
o pidf+xml (RFC 3856, RFC 3863)
o xpidf+xml
o RPID (subset) (RFC 4480)

Other extensions:
o INFO (RFC 2976)
o AKA, AKA-v2 authentication (RFC 3310, RFC 4169)
o ICE option tag (RFC 5768)
o Message summary/message waiting indication (MWI, RFC 3842)

Compliance, best current practices:
o Issues with Non-INVITE transaction (RFC 4320)
o Issues with INVITE transaction (RFC 4321)
o Multiple dialog usages (RFC 5057)
o SIP torture messages (RFC 4475, tested when applicable)
o SIP torture for IPv6 (RFC 5118)
o Message Body Handling (RFC 5621. Partial compliance: multipart is supported, but Content-Disposition header is not handled)
o The use of SIPS (RFC 5630. Partial compliance: SIPS is supported, but still make use of transport=tls parameter)

NAT Traversal

o RFC 5389
o Some RFC 3489 compatibility
o DNS SRV resolution
o short/long term authentication
o fingerprinting

o RFC 5766
o DNS SRV resolution
o UDP and TCP client connection

o RFC 5245
o host, srflx, and relayed candidates
o aggressive and regular nomination
o ICE option tag (RFC 5768)

NAT type detection:
o legacy RFC 3489

o QoS support on sockets (DSCP, WMM)

Call us at 770-449-7775

Extend Your Media Support

OpenMedia® is also used in SIPfaxEngine.

OpenMedia is Commetrex’ media-processing framework that separates signal-processing software from the underlying hardware, promoting portability and processor independence. Signal processing is isolated from media-specific control, and media control is isolated from the client application. This means servers and gateways that use OpenMedia can share code, use heterogeneous processors, and enjoy the productivity benefits of skill-set separation.

We use OpenMedia in all of our products that support call-stream media processing. But every so often we catch an OEM at just the right moment in a development schedule where he is looking for media technologies and a framework to support them. But it’s rare. Some OEMs have their own proprietary framework. Others prefer to develop their own.
And, although the media-processing framework is a major system component, some just overlook the need in the early stages of project planning. But, for an engineer willing to consider ways to shorten time-to-market and lower costs by licensing outside software, OpenMedia is a sure bet.

Media-processing is done by media-stream transforms (MSTs). Obviously, we encourage the use of our off-the-shelf MSTs, but it’s easy to develop your own. One customer needed to deliver hundreds of proprietary modems. They developed and debugged them using host-based OpenMedia and then moved the code to his embedded product. And it just worked! In spite of our marketing of OpenMedia’s location independence, we were all amazed.

Now we are using OpenMedia as the media-processing framework for our recently announced SIPfaxEngine, making extending its functionality a snap for the OEM user.