top of page

RTP Media Gateway

Boost the performance of your voice network architecture with the Sippy Media Gateway. The Sippy Media Gateway is the preeminent RTP Proxy platform, slashing CPU load and harnessing the true performance of a clustered network architecture - leveraging the highest Quality of Service (QoS) possible from your infrastructure.

Complementing your Sippy network architecture with SMG succeeds in decreasing traffic processing times and maximizing the power of your mission-critical hardware. Co-locate your Sippy Media Gateway in any geographical location and minimize media transmission latency.

  • Optimize system clustering with multi-stream RTP management.

  • Balance load from mission critical primary servers to RTP Proxy dedicated box - effectively increasing the capacity handling performance of your HW 

  • Retain complete control over Media for NAT traversal and information sensitivity 

  • Geographically deploy Distributed SMG to optimize media transmission latency

Sippy Media Gateway (SMG) Frequently Asked Questions

Q: Is it possible to deploy SMG server on Private Network ?


In 99,9% of cases, SMG server should be configured to run on Public Network as it should be reachable from both calling and called parties for appropriate media traffic traversal. The communication channel between Sippy SoftSwitch and SMG servers is highly recommended to be set up via separate Private channel to get less latency of media session management.


Q: Is it possible to run SMG server on Virtual Machine (VM) ?


Yes, it is possible to deploy SMG server on VM. However, the performance of such VM based server could be much less than you may expect. Our recent performance tests conducted on Digital Ocean platform revealed performance difference in 4+ times (350 vs 1500 media proxied sessions) in comparison to bare metal server of similar hardware configuration.


Q: My switch is configured to use only my SMG Cluster, but I still see some media being handled by my switches internal rtpproxy, why?


By default, the SoftSwitch will use the internal RTPproxy for a small proportion of media. In the event that your configured SMG cluster is unavailable, due to a network partition for example, then the SoftSwitch will attempt to handle media using the internal RTPproxy. The SMG Cluster can be configured to not use the internal media relay under all circumstances.


Q: If my SMG Cluster has four members, how does the system load-balance RTP between the members of the cluster?


Each member of the cluster is given a weight, which allows us to control how much load goes to each node. The default configuration is such that each member has equal weights. This means that each node will get approximately the same amount of traffic.


Q: Is there a way to know which RTP server was used by a specific call using the CDRs?


In version 4.4 of the Sippy SoftSwitch, if you have "Record SDP" enabled, then you can look at the details of your CDR, and view the SDP. There you will find IP address of the media relay used. If you are running a Sippy SoftSwitch earlier than 4.4, or if you do not have the "Record SDP" feature enabled, then you can also find the same information by extracting the SIP logs. Either using the web based SIP Log Viewer, or by accessing the sip.log file directly on your SoftSwitch server.


Q: If a member of the SMG cluster fails, or becomes unavailable, how does the SoftSwitch detect this condition? If the failed member comes back on line, will it be added back

The SMG Cluster sends a ping to all cluster members. If a member fails to respond, then that member will not receive proxy requests. If or when the SMG node comes back online, the SMG Cluster will detect this, and start to utilize the node.

Q: Why do you recommend Intel Enterprise class network cards?

The Intel cards off-load a lot of the interrupt handling to the card itself. This reduces the CPU usage on your SMG node significantly. 

bottom of page