[VoiceOps] using a T1 to extend PRI service and involuntary fax over sip

[Lonny Clark]

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.

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).

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%).

Lonny Clark

On Mon, Jan 24, 2011 at 10:24 AM, Mark Kent <mark at noc.mainstreet.net> wrote:

> I stumbled across a situation where a fax-to-email service gets
> inbound calls, from Carrier X, over a PRI into a cisco 5350 which then
> relays the calls, via an x-conn PRI, to a directly-attached linux box.
> This has worked for years.
>
> About a year ago, it was revealed that the above-mentioned PRI
> connects to the edge of Carrier X's SIP infrastructure.  That is,
> calls start from some PSTN-connected fax machine, somewhere in the
> USA, go through a PSTN-to-SIP gateway, travel as SIP to the building
> where this cisco 5350 is, and then go through Carrier X's SIP-to-TDM
> equipment for delivery over the PRI to the cisco 5350.
>
> This led to some concern, since we all know that fax over SIP can be
> problematic.   But everything was working, hundreds of faxes a day
> were pulsing through the system.
>
> Up until September the cisco 5350 was in the same building as Carrier
> X's TDM equipment.  In late September, a point-to-point, B8ZS/ESF T1
> was used to extend the in-building cross-connect between Carrier X
> and the cisco 5350.  The cisco 5350, and related servers, are now
> eight miles away (both endpoints in Manhattan, using VerizonBusiness
> for the T1, both endpoints "on-net", no ILEC involved).
>
> Since November, maybe half a percent of the faxes fail to work.
> They get a communication error at the start, at the modem negotiation.
> The T1 circuit is clean.
>
> Some people think that failures may not have been reported/noticed in
> October, but they occured nevertheless.  This would suggest that the
> previous set-up was a very delicately balanced system and the moving
> of the cisco5350 eight miles away, necessitating the use of a T1 to
> carry the PRI to the new location, may be the root cause of the
> failures.  Occam's razor reasoning supports this.
>
> The grassy knoll people believe that, in November, Carrier X started
> an effort to wring more out of their SIP network. Perhaps they started
> using different peers in various parts of the country.  Maybe their
> PSTN-to-SIP gateways were tuned to use less bandwidth.  When asked,
> Carrier X answered a different question, in a fashion similar to a
> politician.
>
> I'm wondering whether any experts here have an opinion to offer?
>
> Thanks,
> -mark
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110124/8f8089bd/attachment-0001.html>