I do like the idea of a cohesive overview of how SipX communicates.

So a couple of thoughts on this to add..

Assuming your focusing on phone calls, not IM et al.

You separated transport from interface which is good. Adding BRI, and
DS0 [i.e. pots, 1mb] and perhaps H323, RTP, and T.38 might fill out the
transport list more.

You might want to make the distinction on interfaces clearer regarding
TDM Gateways and SBCs.

So a second type of interface (where a Gateway to TDM is the first)
would be an SBC. In terms of SBCs there is the native SipXbridge and
then various 3rd Parties (Ingate, Acme Packet, etc.).

SipXbridge has certain distinctive implementation characteristics such
is communicating via port 5080. Another is SipXbridge is recommended to
sit behind a Firewall NATed.

The 3rd party SBC options prefer to *not* sit behind a firewall, at
least one that NATs the external IP address. The 3rd party SBC support
for a Firewall's NATing varies from none, to limited, to unlimited. A
3rd party SBC can use port 5060 to communicate signaling with an ITSP.
There is at least one SBC that can convert H323 connections to SIP.

Lastly there is the SipX to SipX connection (distinctly different than
the Gateway or SBC) which comes into play for multisite organizations,
and federation connection between separate organizations. A multisite
(multi-SipX) organization may use a Campus LAN, internal WAN, or
internal MPLS VPN to facilitate SipX Sip Domain to SipX Sip Domain
communication directly without SipXbridge or an SBC as an interface.

Most of this subject is academic, but a concise though thorough running
through of the options would be beneficial in defining scope.

don

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Todd Hodgen
Sent: Friday, December 30, 2011 4:29 PM
To: 'Discussion list for users of sipXecs software'
Subject: [sipx-users] SIP versus PRI

This email is intended as the beginning of a discussion on the sipXecs
users
list to benefit people that are looking for information on types of
trunks
to connect to sipXecs.  Please consider adding to this document with
relevant facts, and I will make it a wiki document for the benefit of
the
community.

PRI (Primary Rate Interface) is an ISDN based standard, that uses
Channels
in the PRI for individual calls.   It is delivered over T1 and E1.  It
supports G711 calls.  It uses a common signaling channel (D-Channel) to
control the 23 voice calls (US).

SIP trunks are IP based, and use the Session Initialization Protocal for
its
common signaling channel.  They support calls based on several codec,
including G711, G729, G726, etc.

These distinct technologies require a gateway between them to be able to
process calls from a PRI to SIP.

If you have a PRI that you need to connect to sipXecs, you will need a
Gateway to perform the translation from PRI to sipXecs' SIP
implementation.
Patton and Audiocodes are the two most commonly used gateways within the
sipXecs discussion list.

If you have a connection to an ITSP that is providing SIP trunks, it
will be
via an IP connection.  This connection can use either Username/Password
Authentication, or it can use a Static IP address configuration.  Both
are
supported using the integrated sipxbridge.

In PRI and SIP trunk implementation, DID calls are accepted within
sipXecs
by simply inserting the DID number into the Alias field of a given
extension, or matching the extension number to the digits delivered by
the
service provider.  Both are acceptable methods.

*** Caution - Some ITSP implementations of SIP cause issues with DID
deliver.  As just one example, they must be able to accept Invites
without
SDP.
In my experience, Broadvox requires a static IP address for correct DID
deliver on their legacy network (I'd love to have that proven wrong and
see
a working configuration for it)

Comments on other ITSP's welcome and encouraged here
..........................................................

_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

"The information in this electronic mail message is the sender's confidential 
business and may be legally privileged. It is intended solely for the 
addressee(s). Access to this internet electronic mail message by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful."
"The sender believes that this E-mail and any attachments were free of any 
virus, worm, Trojan horse, and/or malicious code when sent. This message and 
its attachments could have been infected during transmission. By reading the 
message and opening any attachments, the recipient accepts full responsibility 
for taking protective and remedial action about viruses and other defects. The 
sender's employer is not liable for any loss or damage arising in any way from 
this message or its attachments."
"In connection with representing sellers and/or buyers in real estate 
transactions, Coldwell Banker Residential Brokerage real estate sales 
associates have absolutely no authority to create binding contractual 
obligations on behalf of a seller or on behalf of a buyer via any written or 
verbal communications including, but not limited to email communications." 
[v1.0.07.109]
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to