Actions

AlphaCom SIP interface

From Zenitel Wiki

Revision as of 15:06, 30 September 2010 by Egil (talk) (→‎SIP Trunk)

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 RTP media flows directly between the RtpDaemon and the SIP phones, without any involvement from SIPd.

SIP interfacing in AlphaCom is configured in AlphaPro.

A SIP device can be used with AlphaCom in one of two different modes:

  • SIP trunk
  • SIP as station

Both modes can be used in AlphaCom simultaneously, but a given SIP device can only be configured for use in one mode in AlphaCom

Operating modes

SIP Trunk

Trunked mode is intended for connection to an external system with many telephones, it may be a SIP proxy, a SIP PBX or a PSTN gateway. Use this mode if AlphaCom only should know about the SIP proxy/PBX/gateway, not about the individual telephones.

When calling from an AlphaCom station a SIP trunk, the user will usually dial additional digits to address the actual telephone. This may be done in two different ways:

  • The access number to the trunk is configured such that AlphaCom (AMCD) will collect a number subsequent digits, before sending a INVITE with the complete number.
  • The access number to the trunk is configured such that AlphaCom immediately connects to the proxy/PBX/gateway, and subsequent digits are forwarded as #Digits in call.

A SIP Trunk is configured as a virtual AlphaNet Node with the "exchange_class" set to SIP.

To configure access numbers to the trunk for outward dialling, use Call remote exchange feature or Call remote station feature. It the access number itself should included in the outgoing INVITE, use the latter. Either way use "param2" if AlphaCom should collect more digits before sending INVITE.


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. See SIP registrar node - configuration.

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.

Calls from SIP to AlphaCom, trunked mode

A call from SIP trunk has the following properties in AlphaCom:

SIP as Station

For more information, see SIP phone as station.

Function

The following applies to both trunked and station mode.

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. 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. See #Digits in call for more details.

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 via the Linux Console. This is intended for debug and on-site trouble shooting. See SIP trace for details.

Syslog

All trace events on levels 0 - 2 (ERROR) are also sent to syslog.

SIP protocol operation

Consult RFC 3261 for description of SIP, and RFC 4566 on SDP. (http://tools.ietf.org/html/rfc3261 / http://tools.ietf.org/html/rfc4566 ). Important concepts as SIP transactions, Cseq, SIP dialog and SIP call-ID should be looked up here.

This chapter comments on how AlphaCom supports SIP, and about limitations.

First some general comments.

SIP Transport: SIPd supports only SIP over UDP, and receives only on UDP port 5060.

SIP URI usage: SIPd assumes the user part of URIs specify a phone/directory number.

SIPd does currently not support domain names in SIP URIs (AlphaCom does not contain a DNS resolver).

SIPd currently ignores SIP responses not related to INVITE.

REGISTER

Example of an REGISTER transaction from a SIP phone with address 169.254.1.101. 

REGISTER sip:169.254.1.5 SIP/2.0
Via: SIP/2.0/UDP 169.254.1.101:62952;branch=z9hG4bK15fdffffcbd50000
From: <"Smith, J" sip:52304@169.254.1.5;user=phone>;tag=093400009879ffff
To: <sip:52304@169.254.1.5;user=phone>
Contact: <sip:52304@169.254.1.101:62952;user=phone>
Call-ID: 5099ffffa1ccffff@169.254.1.101
CSeq: 260 REGISTER
Expires: 3600
User-Agent: ImaginarySoft ImaginaryPhone 0.0.0.1
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0

The important header fields are To: and Contact:

The To: header must match a directory number defined in the AlphaCom. The user-name part of the SIP URI (before @) must be equal to the directory number in question. Domain (after @) is ignored.

The Contact: header gives the addess where the phone can receive calls. ”:62952” in this example is the UDP port used by this SIP UserAgent. SIPd (since version 01.02) handles registrations from any UPD port. If the port number is not present in the URI, default SIP port 5060 is assumed.

A * in the Contact list will remove the binding for that user. Expires=0 also removes the binding.

SIPd can only store one contact address for each user. The last Register message overwrites earlier contact addresses for that user.

Immediate response will be a ”100 Trying” message.

Successful registration will give a ”200 OK message” 

SIP/2.0 200 OK
Via: SIP/2.0/UDP 169.254.1.101:62952;branch=z9hG4bK15fdffffcbd50000
From: "Smith, J" <sip:52304@169.254.1.5;user=phone>;tag=093400009879ffff
To: <sip:52304@169.254.1.5;user=phone>
Call-ID: 5099ffffa1ccffff@169.254.1.101
CSeq: 260 REGISTER
Contact: <sip:52304@169.254.1.101:62952;user=phone>
Allow: INVITE, ACK, REGISTER, BYE, CANCEL, INFO
Content-Length: 0

Unsuccessfull registrations may return

  • “404 NOT FOUND” if the request was legal, but the number in the To: URI did not match a directory number.
  • “400 BAD REQUEST” if SIP could not parse the To: header

INVITE, incoming to SIPd / AlphaCom

Example of the phone sending INVITE 

INVITE sip:104@169.254.1.5;user=phone SIP/2.0
Via: SIP/2.0/UDP 169.254.1.101:62952;branch= z9hG4bKc61400003a3bffff
From: "Smith, J" <sip:52304@169.254.1.5;user=phone>;tag= f64fffff13050000
To: <sip:104@169.254.1.5;user=phone>
Contact: <sip:169.254.1.101:62952;user=phone>
Supported: replaces
Call-ID: cbc00000b21bffff@169.254.1.101
CSeq: 32627 INVITE
User-Agent: ImaginarySoft ImaginaryPhone 0.0.0.1
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 154

v=0
o=52304 8000 8000 IN IP4 169.254.1.101
s=SIP Call
c=IN IP4 169.254.1.101
t=0 0
m=audio 5004 RTP/AVP 0
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20

The user part of the "request URI" in the first line (behind INVITE), specifies the directory number of station to be called in AlphaCom (Here: number “104” ). (This was corrected in version 01.24, earlier version used the To: header).

The information in the From: header is presented on the display of the called station in AlphaCom. The user name must contain digits only, and is presented as the calling number (52304), and the “display name” is presented as the name of the caller. Display name should be quoted in “”, and contents encoded in UTF-8.

CSeq and Call-ID must be set according to RFC. Regarding the SDP media description: The c=, m= and a= fields are the one used by SIPd.

The IP address for the RTP data is found in c=. It need not be the same as the IP address used by SIP.

The UDP port is the number following “audio” in m=. The RTP payload type is specified in last parameter in m=. AlphaCom only handles three of the static RTP payloadtypes in RFC 3551:

  • 0: PCMU
  • 8: PCMA
  • 9: G722

Dynamic RTP payload types are currently not supported by AlphaCom. a=rtpmap field is therefore not really necessary for AlphaCom.

If the INVITE is valid, SIPd will respond immediately with a 200 OK message, which completes the RTP setup.

The SIP connection is established immediately with a 200 OK, even if connection is not completed to the final destination in AlphaCom. Particularly, SIPd does currently not transmit 180 Ringing status, you only hear the ringing tone in the audio. Also, call to a busy station will result in connection to a busy tone audio signal, no 485 Busy here. Failure/busy tones will be followed by a BYE from AlphaCom. These are limitations of current version, which may be changed later.

Here is the 200 OK message from the example. The most important fields here are c= and m= which gives the IP address and port for the AlphaCom end of the RTP connection. 

SIP/2.0 200 OK
Via: SIP/2.0/UDP 169.254.1.101:62952;branch=z9hG4bK9c5fffff2fe20000
From: "Smith, J" <sip:52304@169.254.1.5;user=phone>;tag= f64fffff13050000
To: <sip:104@169.254.1.5;user=phone>;tag=2076924972
Call-ID: cbc00000b21bffff@169.254.1.101
CSeq: 32627 INVITE
Contact: "Brown, B" <sip:104@169.254.1.5:5060>
Allow: INVITE, ACK, REGISTER, BYE, CANCEL, INFO
Content-Type: application/sdp
Content-Length:   134

v=0
o=Brown 20000001 20000001 IN IP4 169.254.1.5
s=-
c=IN IP4 169.254.1.5
t=0 0
m=audio 61000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

INVITE, outgoing from SIPd / AlphaCom

INVITE sip:52304@169.254.1.101 SIP/2.0
Via: SIP/2.0/UDP 169.254.1.5:5060;branch=z9hG4bK256554362
From: "Brown    " <sip:104@169.254.1.5>;tag=1650601524
To: <sip:52304@169.254.1.101 >
Call-ID: 654880700@169.254.1.5
CSeq: 70335 INVITE
Contact: <sip:104@169.254.1.5:5060>
Max-Forwards: 70
User-Agent: AlphaSip gateway
Subject: Forwarding AlphaCom call
Expires: 120
Allow: INVITE, REGISTER, ACK, BYE, CANCEL, INFO
Content-Type: application/sdp
Content-Length:   136

v=0
o=Brown 20000001 20000001 IN IP4 169.254.1.5
s=-
c=IN IP4 169.254.1.5
t=0 0
m=audio 61000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The From: header contains the name and directory number of the calling AlphaCom station.

Otherwise the same comments as on the incoming INVITE applies here.

SIPd handles 180 ringing status, sets out ringing tone to calling station. 200 OK message is expected to complete the RTP setup. “486 Busy here” and “600 busy everywhere” will setup busy tone to the calling station, and the AlphaCom will retry the setup a few times.

“301 Moved Permanently”, “302 Moved Temporarily” is handled by SIPd (since version 01.24). SIPd will send a new INVITE to the URI specified in the Contact header. (If redirection is to a AlphaCom station, it is handled by SIPd sending the redirected INVITE to self, which result in a second call connected via IP. This should be optimised)

All other status responses >= 300 will terminate the call with a failure tone.

Digits in call

SIPd support two methods for sending and receiving digits during a call. AlphaCom will receive digits sent by both methods in a call. But AlphaCom will send digits in only one format, depending on the SDP negotiation described below.

RFC 4733 RTP events

AlphaCom support rfc4733 (Obsoletes: rfc2833). rfc4733/rfc2833 is the widely supported way of transmitting digit events inside a SIP session. This is a way of embedding DTMF events within the RTP media stream.

There is no configuration in AlphaCom for this. AlphaCom will always offer rfc4733 events. If accepted, AlphaCom will send digits as rfc4733 events. Otherwise AlphaCom will send the events as SIP INFO.

The SDP media description typically looks like 

m=audio 2308 RTP/AVP 0 8 103
a=fmtp:103 0-15
a=rtpmap:103 telephone-event/8000

... where 103 is the RTP payload number. For out going INVITE, AlphaCom will use payload type 103. For incomming call, AlphaCom uses the payloadtype from the incomming INVITE. The outgoing payload number can be changed by setting the NVRAM variable .ex_profile.glob_const.rtp_event_pt from TST console.

AlphaCom isolates the rfc4733 RTP digits to the leg between the SIP-AlphaCom and the outside SIP device. AlphaCom extracts RTP digit events from SIP in the first AlphaCom, before forwarding the audio to other AlphaComs and/or IP stations. The extracted digits are handled out of band according to normal AlphaCom procedures. Digits dialled on the AlphaCom are injected into the RTP stream at the same AlphaCom closest to the SIP link.

RFC 4733 support was relased in 10.60.0.0.

INFO

SIP INFO messages can be used to send and receive single digits dialled during a call.

AlphaCom will send INFO digit messages in a outgoing call when the calling user presses digit keys on the station during the call. DAK keys are used to dial DTMF signals above 9. * = DAK0, # = DAK1 (upper DAK keys, and are labeled * and # on many stations). From AMC version 10.31, DTMF codes A, B, C and D can be dialled by DAK keys 2 to 5.

AlphaCom can receive INFO digits in both incoming and outgoing calls. The handling of the digits will depend on the context, in the same way as dialling from an internal AlphaCom station. * is handled as M-pres, and # as M-release.

Example of an outgoing INFO digit message: 

INFO sip:52304@169.254.1.101;user=phone SIP/2.0
Via: SIP/2.0/UDP 169.254.1.5:5060;branch=z9hG4bK758154553
From: "Brown" <sip:104@169.254.1.5>;tag=290610420
To: <sip:52304@169.254.1.101>;tag=10570000a80cffff
Call-ID: 1097021121@169.254.1.5
CSeq: 70337 INFO
Contact: <sip:104@169.254.1.5:5060>
Max-Forwards: 70
User-Agent: AlphaSip gateway
Content-Type: application/dtmf-relay
Content-Length:    22

Signal=5
Duration=250

The format expected in incoming INFO messages is similar.

“Signal” denote the key pressed. Only one single key can be transmitted or received with each message. Ordinary digits are encoded as a single letter 0 – 9. * and # are encoded as the letters * and # (from verision 01.04). In incoming messages, “Signal=*” and “Signal=10” can be used for *, “Signal=#” and “Signal=11” can be used for #. DTMF digits ABCD is codes as the letters ABCD (from SIPD version 01.13).

Duration is hardcoded to 250 (ms) in outgoing messages, and is ignored for incoming messages.

SIPd Responses

Explanation of what went wrong for selected non-successful SIP responses. Very incomplete ...

  • 400 BAD_REQUEST : Incoming INVITE: Missing To or From URLs, or missing m= lines in SDP part
  • 403 FORBIDDEN : Incoming INVITE: Validation of From: SIP header failed. Invite is accepted if
    • user part of from-URL matches a registrated user, or
    • IP address of from-URL matches a configued "SIP trunk".
  • 503 SERVICE_UNAVAILABLE : Failed to allocate internal data structure


Limitations

Very very incomplete ...

  • Early media not supported (SDP in 1xx responses)
  • Late SDP offer not supported (INVITE with no SDP)
  • SIP authentication not supported
  • SIPS not supported
  • codec negotiation rfc3264 not handled

SIPD implementation notes

AMCD extracts the configuration relevant to SIPd and puts it in a text file, /tmp/sipd_config.json. SIPd reads this file at start up, and when the file changes.

SIPD stores registered SIP stations in a SqLite database in /var/opt/amc/nvram/sipd.sqlite. To see contents: 

sqlite3 -header -column /var/opt/amc/nvram/sipd.sqlite "select * from RegUsers"

SIPD connects to AMCD on TCP port 40000

Retrieved from "https://wiki.zenitel.com/w/index.php?title=AlphaCom_SIP_interface&oldid=51235"