Actions

Difference between revisions of "AlphaCom SIP interface"

From Zenitel Wiki

(trace and debug)
Line 74: Line 74:
  
 
0,1,2,3,4,5,6,7: Set tracelevel.
 
0,1,2,3,4,5,6,7: Set tracelevel.
      0: Fatal errors only
+
: 0: Fatal errors only
      4: SIP/AlphaNet message trace (default)
+
: 4: SIP/AlphaNet message trace (default)
      7: All internal debug trace also
+
: 7: All internal debug trace also
 
l:  list active calls
 
l:  list active calls
 
h:  This text
 
h:  This text

Revision as of 13:28, 8 August 2007

SIPd Overview

The SIPd is a signalling gateway. It handles call setup and termination requests and does the necessary conversions between the AlphaNet and SIP protocols.

The SIPd runs on the AMC IP. It is connected to one AlphaCom running on the same AMC IP. All requests from AMC stations are received via this AlphaCom node.

The intended usage of SIPd is that it forwards calls to and from SIP phones. SIP phones may be controlled by an external SIP proxy server, such as Cisco Call Manager. Or to interface to POTS or ISDN telephone systems via a SIP gateway.

For sites that do not have a separate SIP proxy server, it is possible to connect the SIP phones directly to SIPd.

Once a call is established, the RTP media flows directly between the AlphaCom and the SIP phones, without any involvement from SIPd.

Function

Overview

The SIPd is configured as a collection of one or more virtual AlphaNet nodes.

Each virtual AlphaNet node gives the IP address of a SIP device. The SIP device can be a SIP proxy server, in turn handling a number of SIP phones. Or it can be one single SIP phone. AlphaCom does not really care about the difference.

SIPd can also act a registrar and proxy server for SIP phones. In that case the IP address of the virtual AlphaNet node is set to be the same as the hosting AlphaCom. The directory numbers of the SIP phones are entered into AlphaPro as remote AlphaNet numbers pointing to the Registar node. SIPd will accept registrations from stations with number found in this list of directory numbers. The IP address and UDP port of the station is stored in a database.

Call setups from AlphaNet nodes are targeted towards one of the virtual AlphaNet nodes. This is performed in two steps:

  1. The AlphaCom looks up the dialled number and finds the destination and link node in its Directory Table and Data Routing Table.
  2. The SIPd looks up the configuration for that Virtual node
a. If the node is set up as proxy/registrar, look up the IP address and UDP port of the phone in the registrar base
b. Otherwise use the IP address of the target SIP proxy in its Virtual Node Table.

Configuration handling

The SIPd Virtual Node Table is configured via AlphaPro

Corresponding number series and node definitions must be configured in the AlphaCom Directory Table and Data Routing Table by using AlphaPro. AMCD transfers the configuration relevant to SIPd in a text file, /tmp/sipd_config.

Calls

The SIPd supports 32 simultaneous calls.

The SIPd only supports audio calls.

SIPd supports SIP phones with auto-answer (results in different SIP signalling with no 180 Ringing messsages).

3 examples of SIP phones tested successfully with SIPd:

  • SIP phone terminals (e.g. Grandstream BudgeTone 100)
  • Analog phones connected to a SIP analog/SIP adapter (e.g. Grandstream HandyTone)
  • SIP softphones (e.g. X-Lite)

Codec negotiation

The SIPd is responsible for codec negotiation. It analyses the codec lists received in the AlphaNet messages and the SDP payload from the SIP messages. If a codec match is found, the call is established, otherwise it is terminated.

The SDP protocol only describes codec capabilities. It is really not a negotiation protocol. SDP allows SIP phones to use any matching codec. However, the SIPd will always pick one and only one codec, which is the first matching codec in the codec lists.

Note! SIP phones that do not use the first matching codec from the codec lists are not supported by SIPd. The AlphaCom can be configured to only send one codec in its codec list. Then this problem will not occur.

Overlapped dialling

In SIP, overlapped dialling means that each digit is forwarded as the user dials it. SIPd supports overlapped dialling. Single digits can be sent and received using the SIP INFO method. Digit transport in RTP (RFC2833) is currently not supported.

The AlphaCom can also be configured to handle the collection of all digits dialled from an AMC station, and waits until it is complete before forwarding the call to SIPd.

Logging

trace and debug

The SIPd offers runtime trace and debug logging by using specific command line options. This is intended for debug and on-site trouble shooting.

The trace-interface is found as an internal unix-socket in AMC: “/tmp/sipd_trace”. Log in via telnet (user: alpha; password: com), and type:

tst -s /tmp/sipd_trace

A few simple input commands are implemented, type single letters;

0,1,2,3,4,5,6,7: Set tracelevel.

0: Fatal errors only
4: SIP/AlphaNet message trace (default)
7: All internal debug trace also

l: list active calls h: This text