Sometimes, Playing Dumb Helps<\/strong><\/h3>\n <\/p>\n
Apparently, there are some situations where the user would rather the call fail, than for it to attempt G.711 as the media transport for an FoIP call. In that case, they will either put T.38 only in the initial SIP INVITE (not recommended for carrier networks), or put G.711 and T.38 in the initial INVITE, but only send CNG (calling tone) in G.711 as, essentially, a recorded message while waiting for the T.38 reINVITE. The idea is for the calling terminal to never send the DCS in G.711 mode, least the called terminal stop sending DIS (its capabilities message) and wait on the modem training, which, of course, will never come. Playing dumb like this will force the call to be T.38 or be nothing at all.<\/p>\n
<\/p>\n
So, how long will the calling server wait? Over 35 seconds, which is a long time in networking terms. If the reINVITE comes, the calling server will accept it and switch to T.38. If, for some reason, the off-ramp\/called gateway(s) did not or could not send the reINVITE, the call fails.<\/p>\n
<\/p>\n
Want to talk FoIP in SIP networks? Give us a call at 770-449-7775 and press 1.[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”grid” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern” el_class=”newsletter_inner_page” css=”.vc_custom_1578991890670{padding-top: 70px !important;padding-bottom: 70px !important;}” z_index=””][vc_column el_class=”newsletter_inner_page_bg”][vc_column_text]<\/p>\n
RFC 6913 Support Now In BladeWare (Release 2.6.0)<\/h3>\n
<\/p>\n
As you may know, Smart FoIP\u2019s patent-pending technology corrects the two biggest Fax over IP (FoIP) problems inherent in SIP-based carrier networks: no more late-T.38 reINVITE problems; no more PCM clock-sync problems causing G.711 pass-through failures. But what about the third big problem: less-than-optimum call routing by the carriers?<\/p>\n
<\/p>\n
You may be aware that in carrier networks, nearly always a fax call begins as a voice call, typically G.711. Other than V.34 calls, the called gateway is responsible for detecting that the called endpoint is a fax terminal and to send a T.38 reINVITE to the calling gateway or server. Obviously, all of this happens after the call has been routed. So, if you\u2019re a service provider or carrier, how can you take control of the routing to get beyond that \u201cless-than-optimum call routing\u201d? To do so, you must determine which calls are likely to be a fax call, and route the call over an IP-only route if possible, at least until it arrives in the called terminal\u2019s local area. And that\u2019s not always simple since the access provider is rarely responsible for end-to-end routing.<\/p>\n
<\/p>\n
But a good start is for the service provider to provision the subscriber\u2019s fax number for that special routing. Often, a subscriber is more than happy to pay a little more for a FoIP trunk that performs since his alternative is an even-higher-priced POTS line. Another approach is for the service provider to apply a heuristic algorithm to the originating point of inbound calls. (If it looks like a duck and walks like a duck, it\u2019s a fax call.)<\/p>\n
<\/p>\n
Yet another way is to support RFC 6913, which BladeWare now does. It turns out that there are IETF RFCs, such as RFC 3840 and 3841, that allow a caller to express routing preferences to the routing entities by using IANA-registered media-feature tags in the SIP Invite. But there was a problem: there was no media-feature tag for \u201cfax\u201d that could be used in the SIP-INVITE header that was registered with the IANA. The solution is the IETF\u2019s RFC 6913, which defines the \u201cSIP.fax\u201d media-feature tag and registers it with the IANA, allowing the originating SIP entity to declare that it prefers a \u201cfax-friendly\u201d route for the call.<\/p>\n
<\/p>\n
You should use a combination of these techniques since RFC6913 is not widely deployed. And you can take matters into your own hands and only deploy fax servers that support RFC6913, then route those FoIP calls over proven routes.<\/p>\n
<\/p>\n
We would be glad to discuss this and any other FoIP issue with you, simply call Commetrex at 1-770-449-7775, and press 1.[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”grid” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern” el_class=”newsletter_inner_page” css=”.vc_custom_1579011662901{padding-top: 70px !important;padding-bottom: 70px !important;background-color: #f6f6f6 !important;}” z_index=””][vc_column el_class=”newsletter_inner_page_bg”][vc_column_text]<\/p>\n
The MX-8 Is Coming!<\/h3>\n
<\/p>\n
You may be aware that NetGen Communications, our sister company that produces and markets Smart ATA to ITSPs and their channel, is partnering with New Rock Technologies (Shanghai) to produce additional products needed by the ITSP. And next to market is the MX product line of access and trunking gateways.<\/p>\n
<\/p>\n
These gateways solve a wide range of enterprise application problems, such as PSTN access for Lync, and include models from four-to-120 ports. But today, they don\u2019t have Smart FoIP, but we\u2019re changing that. First up is the MX8, offering various combinations of station and office interfaces totaling 4 or 8 ports.<\/p>\n
<\/p>\n
But here\u2019s the thing: the 4-port unit lists for only $190 and the 8-port for $295. That means that if you have a BladeWare system that needs PSTN connectivity today but FoIP tomorrow, you can do it without add-in boards. Just drive the MX8 with the FoIP BladeWare. Including Smart ATA in the mix, you have 2-, 4-, 8-port PSTN interfaces for around $50 per port. And you don\u2019t have to give up V.34 because it\u2019s supported by BladeWare, Smart ATA, and the MX8.<\/p>\n
<\/p>\n
When the user is ready, to cut the cord and move to FoIP, just remove the gateway.[\/vc_column_text][\/vc_column][\/vc_row]<\/p>\n","protected":false},"excerpt":{"rendered":"
[vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”grid” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern” el_class=”newsletter_inner_page” css=”.vc_custom_1579011642108{padding-top: 70px !important;padding-bottom: 70px !important;background-color: #f6f6f6 !important;}” z_index=””][vc_column][vc_column_text] Finally! Smart FoIP…<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":553,"menu_order":228,"comment_status":"closed","ping_status":"open","template":"full_width.php","meta":{"footnotes":""},"class_list":["post-4157","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/pages\/4157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/commetrex.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4157"}],"version-history":[{"count":2,"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/pages\/4157\/revisions"}],"predecessor-version":[{"id":5501,"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/pages\/4157\/revisions\/5501"}],"up":[{"embeddable":true,"href":"https:\/\/commetrex.com\/index.php?rest_route=\/wp\/v2\/pages\/553"}],"wp:attachment":[{"href":"https:\/\/commetrex.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}