Most point-to-point T1s that are provisioned are now being backhauled 
over IP. This means that the T1 has to be encapsulated in an IP stream, 
and the timing for the T1 is also embedded in the stream. Any slips in 
the timing may be masked by the backhaul method (you won't see an 
alarm). It also means that now you have the possibility of a dropped or 
out-of-order packet, which was not possible if the circuit were T1/T3 
all the way through. The possibility of timing issues would also be 
increased by the fact that now you are encapsulating twice, once in the 
point-to-point T1, and also at the SIP-to-PSTN interface (assuming the 
PSTN link is TDM). The fax-to-email service itself has to also demux the
 data, and then interprets the result of that as an analog stream using 
software.<br>
<br>You are stacking cards, and eventually they will fall. Personally, I
 think half a percent is a pretty good result. I see about the same rate
 for inbound to my fax servers  We also have outbound fax service using 
one of my fax servers, and I see 4% failure rate on those. I believe the
 difference between the two is that we use SIP on the termination trunk 
for a large number of the calls (anything that is not in our local 
areas). <br>
<br>So, we have TDM in, ethernet transport over OC3 through our network,
 and PRI to the fax server (total errors less than 1%). For the 
outbound, it is PRI from the fax server, ethernet over OC3 through our 
network, terminating in T1 for calls that are local to our POPs, and SIP
 to a long-distance provider for any non-local terminations (total 
errors ~4%). <br>
<br>Lonny Clark <br><br><div class="gmail_quote">On Mon, Jan 24, 2011 at 10:24 AM, Mark Kent <span dir="ltr"><<a href="mailto:mark@noc.mainstreet.net">mark@noc.mainstreet.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I stumbled across a situation where a fax-to-email service gets<br>
inbound calls, from Carrier X, over a PRI into a cisco 5350 which then<br>
relays the calls, via an x-conn PRI, to a directly-attached linux box.<br>
This has worked for years.<br>
<br>
About a year ago, it was revealed that the above-mentioned PRI<br>
connects to the edge of Carrier X's SIP infrastructure.  That is,<br>
calls start from some PSTN-connected fax machine, somewhere in the<br>
USA, go through a PSTN-to-SIP gateway, travel as SIP to the building<br>
where this cisco 5350 is, and then go through Carrier X's SIP-to-TDM<br>
equipment for delivery over the PRI to the cisco 5350.<br>
<br>
This led to some concern, since we all know that fax over SIP can be<br>
problematic.   But everything was working, hundreds of faxes a day<br>
were pulsing through the system.<br>
<br>
Up until September the cisco 5350 was in the same building as Carrier<br>
X's TDM equipment.  In late September, a point-to-point, B8ZS/ESF T1<br>
was used to extend the in-building cross-connect between Carrier X<br>
and the cisco 5350.  The cisco 5350, and related servers, are now<br>
eight miles away (both endpoints in Manhattan, using VerizonBusiness<br>
for the T1, both endpoints "on-net", no ILEC involved).<br>
<br>
Since November, maybe half a percent of the faxes fail to work.<br>
They get a communication error at the start, at the modem negotiation.<br>
The T1 circuit is clean.<br>
<br>
Some people think that failures may not have been reported/noticed in<br>
October, but they occured nevertheless.  This would suggest that the<br>
previous set-up was a very delicately balanced system and the moving<br>
of the cisco5350 eight miles away, necessitating the use of a T1 to<br>
carry the PRI to the new location, may be the root cause of the<br>
failures.  Occam's razor reasoning supports this.<br>
<br>
The grassy knoll people believe that, in November, Carrier X started<br>
an effort to wring more out of their SIP network. Perhaps they started<br>
using different peers in various parts of the country.  Maybe their<br>
PSTN-to-SIP gateways were tuned to use less bandwidth.  When asked,<br>
Carrier X answered a different question, in a fashion similar to a<br>
politician.<br>
<br>
I'm wondering whether any experts here have an opinion to offer?<br>
<br>
Thanks,<br>
-mark<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div><br>