This document provides the technical specification of the Gamma SIP Trunk Service.
This document is written for Network Engineers, System Administrators, Field Engineers, and Technical Consultants who have been tasked with setting up, managing, troubleshooting the Gamma SIP Trunk Service.
This guide assumes that those who use it will have a basic knowledge of VoIP services & protocols.
2. Service Overview
Connexin’s SIP Trunks provide VoIP connectivity for certified PBX’s, allowing inbound and outbound telephony through Connexin’s network for termination with both national and international destinations.
Connexin’s SIP Trunking service uses SIP (Session Initiation Protocol) as the signaling method and offers both Public and Private Access to the service depending on the specific customer needs.
The Connexin SIP Trunking Service includes the following:
- CLIP (Calling Line Identity Presentation);
- CLIR (Calling Line Identity Restriction);
- Call Park, Transfer & Conferencing
- Emergency Call Divert
- Fraud Alert
- CLI presentation flexibility
- Call Admission Control
- Call barring
- Fax and DTMF support
The features listed above are supported in the Connexin network. However it should be noted that the features are not guaranteed to be supported on every CPE platform connected to the Connexin SIP Trunk Service because of vendor interoperability issues.
The Connexin SIP Trunk Service provides SIP signaling as a method for Communication Providers to inter- connect with Connexin’s VoIP network supporting calls to/from the PSTN as well as VoIP to VoIP calling between SIP accounts created within the Connexin SIP Trunk Service. The following types of calls will be supported across this interface:
- Voice calls to/from PSTN or geographic destinations (01,02)
- Voice calls to/from non geographical, corporate or VoIP numbers (03, 05, 08)
- Voice calls to/from Premium numbers (09),UK, International)
- Voice calls to/from Mobile destinations ( 07)
- Voice calls to/from International destinations (00..)
- Operator, Emergency and non-Emergency calls (100, 101,111,112, 116xxx, 118, 123 1800x, 195, 999)
Several number formats are supported for both DDI’s and CLI’s however, not all number formats are supported, for example, TEL URIs using the parameter “phone-context” are not supported and calls utilising such formats may experience issues including loss of service. Details of supported formats appear later in this document.
Connexin offers three design options as standard, for the configuration of the customer’s Connexin SIP Trunk Service.
- A single site working off a single Connexin SBC HA cluster.
- Dual sites in active / standby mode working off different Connexin SBC HA clusters.
- Dual sites in load-balanced mode working off different Connexin SBC HA clusters.
The Connexin network will only respond to messages from equipment where the IP address is defined within the order process.
3. Service Features
3.1. Calling Line Presentation (CLIP)
Calling Line Identification Presentation (CLIP) is a service that transmits a caller’s number to the called party’s telephone equipment during the ringing signal.
If the CPE connected to the Connexin network presents a geographic number in the UK National format, the Connexin Network will pass these details as the A-Number CLI into the PSTN or Mobile network. This outbound presentation will be supported by default if the number presented is as follows:
- A number in the UK national format without a leading zero presented by the Customer Premises equipment (CPE) as the A-number.
- A Connexin provided Geographic Number that is allocated to the Endpoint at order creation
- A Connexin provided Geographic Number that is allocated to the Endpoint at a later date via a Customer Change Request
- A Geographic number that is ported from another Carrier to the Connexin Network
The A-number is checked against a database on the Connexin network of geographic numbers that are allocated to the Connexin SIP Trunk Service Endpoint.
If the number presented does not meet the above criteria, the A-Number CLI presented will be a default CLI, which is the first number in the Connexin allocated Geographic DDI range.
Connexin cannot guarantee consistent presentation of intended CLIs for calls made to mobile carriers as, successful presentation of the intended CLI is entirely dependent on the mobile carriers use of these numbers and specific call flow. Mobile missed calls and voicemail notifications can often use the default CLI, which is the first number in the Connexin allocated account range, rather than the intended CLI for presentation.
When CLIP is requested by the calling party on an inbound call towards the CPE, Connexin will ensure that all CLI information is passed to the Connexin SIP Trunk Service Endpoints; those headers being From, Contact and Privacy header (PAID/RPID)
Headers contained within Invite towards SIP Trunking Endpoint
From: <sip:+firstname.lastname@example.org>;tag=3541226335-339769 Contact: <sip:+email@example.com>
NOTE: With CLIP no modifications are performed for SIP Trunking untrusted requirements. 3.2. Calling Line Restriction (CLIR)
When the calling (A-Party) has requested privacy (CLIR), Connexin will enforce privacy in accordance with RFC3325. Calling party information, including From Address, Contact and associated Privacy Header (PAID) are withheld from an endpoint.
For calls from the CPE to Connexin, the CPE must indicate that CLI is to be withheld by the following mechanism:
- RFC3261 Section 126.96.36.199 and 20.20 which describes the use of an “Anonymous” display field to the From: header to indicate that the client is requesting privacy.
- SIP Privacy which is described by RFC 3323 and RFC 3325
For calls from Connexin to the CPE:
- the From address is set to – “Anonymous”<sip: firstname.lastname@example.org> as per RFC 3323, the contact header is set to Anonymous and the Privacy header (P-Asserted-Identity RFC 3325) is removed from the outbound INVITE to the SIP Trunking endpoint to provide true CLI restriction.
- If the Privacy header contains only “id,” or only “id” and “critical” values, Connexin removes the Privacy header completely.
- The Contact user part is changed to “anonymous.”
Public Side Invite; (Going out to SIP Trunking Endpoint)
From: Anonymous <sip:email@example.com>;tag=3541226365-699915 Contact: <sip:firstname.lastname@example.org:5060>
NOTE(1): NO PAID Header, it has been removed to provide the calling party full anonymity.
3.3. Call Park, Transfer & Conferencing
The Connexin SIP Trunking Service provides the features listed below in the majority of cases but are not guaranteed on every platform connected to SIP Trunking because of vendor interoperability issues:
- Call Parking
- Call Transfer
These features are supported via the SIP re-invite mechanism.
3.4. Emergency Call Divert
The Connexin SIP Trunking Service provides the facility to pre-configure call diverts for both individual numbers and DDI number ranges. Under failure conditions, Connexin can activate either all pre-configured numbers with a single action, or activate individual diverts as necessary. Once activated, these diverts become effective.
The diverted destinations are subject to the same call barring option as the main SIP trunk, e.g. if the end-user does not allow calls to mobiles, then the divert destination options will also exclude mobile numbers.
The end-user will be billed for the diverted leg for all diverted calls.
Connexin does not support emergency diverts to international or other numbers which exceed 11 digits in length.
End-users are constrained to a total maximum of 150 emergency call diverts configured per endpoint at any point in time.
Please note that the emergency diverts are enable within the Connexin core network. The range of standard SIP Trunking endpoint features (e.g. fraud alerts, CLI flexibility, call admission control) do not apply to CLIs with emergency diverts enabled.
3.5. Fraud Alert
Connexin SIP Trunking Service Endpoints are potentially vulnerable to fraudulent spend, particularly if the customer adopts weak access security to their PBX. The fraud alert function is a cost option that allows partners to set pre-arranged spend limits on individual SIP trunks.
These spend limits can be set to monitor both 24hr and 7 day periods with individual figures associated with both. On reaching 85% of the maximum spend in any period, an email and SMS alert will be sent. If the spend reaches 100% of the agreed limit a further email and SMS will be sent and all subsequent calls from that end-point will be barred.
- Calls to the emergency services 999, 112 & 18000 will be unaffected.
- Inbound Calls are not affected
- Calls set-up via the emergency Divert function is excluded in the fraud calculation.
3.6. CLI Flexibility
NON Connexin Registered CLIs can be setup as the Presentation A-Number CLI. The service supports the presentation of the following A-Number CLI types:
- National Significant (1NNNNNNNNN, 2NNNNNNNNN, 3NNNNNNNNN, 7NNNNNNNNN, 8NNNNNNNNN) for UK numbers.
- National Significant with leading zero (01NNNNNNNNN, 02NNNNNNNNN, 03NNNNNNNNN, 07NNNNNNNNN, 08NNNNNNNNN) for UK numbers.
- E.164 (441NNNNNNNNN, 442NNNNNNNNN, 443NNNNNNNNN, 447NNNNNNNNN, 448NNNNNNNNN) for UK numbers.
- SIP E.164 – with leading plus – (+441NNNNNNNNN, +442NNNNNNNNN, +443NNNNNNNNN, +447NNNNNNNNN, +448NNNNNNNNN) for UK numbers.
- UK International (00441NNNNNNNNN, 00442NNNNNNNNN, 00443NNNNNNNNN, 00447NNNNNNNNN, 00448NNNNNNNNN) for UK numbers.
- SIP E.164 – with leading plus – (+CCNNNNNNNNN) for non-UK numbers.
- UK International (00CCNNNNNNNNN) for non-UK numbers.
The presentation of any other A-Number CLI types, badly formatted CLI A-Numbers or UK revenue sharing numbers (9NNNNNNNNN, 09NNNNNNNNN, 449NNNNNNNNN, +449NNNNNNNNN and 00449NNNNNNNNN) is not supported by Connexin and such numbers will be replaced by the default CLI, which is the first number in the Connexin allocated DDI range.
The presentation number must not be a number that connects to a revenue sharing number which will generate excessive or unexpected call charges; the use of such numbers may result in Connexin suspending and/or withdrawing the use of the Presentation CLI Flexible Service.
Presentation of Mobile A-Number CLI types (7NNNNNNNNN, 07NNNNNNNNN, 447NNNNNNNNN, +447NNNNNNNNN and 00447NNNNNNNNN) excludes Personal numbers.
For calls made to the Emergency, Non-emergency & Operator Services (100, 101,111,112,116, 118,123,1800 and 999), only Connexin A-Number CLIs are accepted and must be in the National Significant (with or without a leading zero) or the SIP E.164 – with leading plus – format, any other A-Number CLI or A-Number CLI format will be overwritten by the default CLI, which is the first number in the Connexin allocated DDI range.
All A-Number CLIs will be “normalised” within the Connexin network to the SIP E.164 format for external presentation but Connexin are not responsible for subsequent carriers changing the presented A-Number CLI or it’s format.
3.7. Call Admission Control
Through a process known as Call Admission Control (CAC), the maximum call limit of an endpoint defines its capacity for routing calls in the network. SIP Trunking customers pay a fixed monthly charge for the number of concurrent calls allowed on their endpoint. As each customer endpoint will have 2 ports, one for outgoing and one for incoming the CAC limit will be allocated to both ports to allow maximum flexibility. Thus Connexin will support any combination of incoming or outgoing calls provided the total number of calls does not exceed the total channel allocation (i.e. CAC limit).
- Maximum Total Calls – specifies the overall number of calls the endpoint will support, both ingress and egress.
- Maximum Ingress Calls – specifies the maximum calls that may be placed from that endpoint to the Connexin network.
- Maximum Egress Calls – specifies the maximum number of calls that may be placed to that endpoint by Connexin.
For example, if the channel limits is 100 concurrent calls, and there are 70 ingress calls, the maximum no of egress calls allowed will be 30.
In the case that the call control constraints are exceeded at a SBC, the invites will be rejected with either a SIP Response 486 or 503.
3.8. Call Barring
By default, calls to international and premium numbers will be barred. Restrict access can be altered to:
- International Numbers
- Mobile Number
- Premium rate numbers (i.e. 09….)
Calls to the emergency services 999, 112 remain unaffected irrespective of the barring applied.
3.9. Fax and DTMF support
The Connexin SIP Trunking Service will support Fax and Modem transmission subject to the following constraints:
- FAX and Modem transport in band using G.711 a-law codec is supported.
- Renegotiation to T.38 is supported. (subject to interoperability testing)
The use of G729 for in-band faxes is not recommended as its compressed nature may cause tones and messages to be lost.
If the fax option for an endpoint is set to T.38 enabled then:
- The Connexin network will attempt to re-negotiate [re-INVITE] to T.38 for fax calls for ingress (Customer to Connexin) calls on detection of a fax tone.
- The Connexin network will accept a re-negotiation [re-INVITE] to T.38 for fax calls for egress (Connexin to Customer) calls.
- The re-negotiation must be done using the re-INVITE mechanism after answer.
- Due to different vendor implementations Connexin cannot guarantee T.38 interoperability with all vendors and will not accept responsibility if T.38 interoperability cannot be achieved with a specific vendors implementation.
If the fax option for an endpoint is set to T.38 disabled then:
- All fax calls will be handled as G.711 pass through providing the customer has a G.711 codec available in his media profile.
If calls are made to another CP that does not support the method of transport for the tones, Connexin will not perform any form of inter-working between the two different methods.
The following methods will be supported to transport DTMF tones:
- The Connexin core network will support the generation of ‘In-band’ or ‘RFC2833’ DTMF transport based on end to end negotiation.
- RFC2833 is the preferred method for the transport of DTMF tones. Support of RFC 2833 is dependent on successful codec negotiation and requires the payload type 101 to be assigned. RFC2833 will be used with both G.711.and G.729 codecs.
- In band over G.711 codec only
If a G729 codec is being used then DTMF tones should not be sent in-band, Connexin will not guarantee the delivery of in-band DTMF over a G729 codec.
3.10. Emergency, Non Emergency and other short code Calls
Important Note: This is a VoIP service as defined by Ofcom and can be used to support Emergency Services calls. Once the service is fully operational, 999/112 public emergency call services can be accessed and will be routed to the national emergency call handling agents. The CLI presented will always be the site CLI, indicated as a VoIP service type from Connexin, so that the emergency services operator will check the address details. It is the Operators responsibility to ensure this address associated with the default site CLI is always up to date.
As a VoIP service SIP Trunking may not be possible, in the following circumstances:
- During a service outage where the end-customer loses connectivity for example, owing to a power outage or the failure of DSL routing equipment
- If an end-customer’s account has been suspended
In such circumstances the end-customer should use their PSTN line to make the emergency call.
In addition, the end-user should also be made aware that the emergency personnel would need to confirm the identity and the actual location of the caller when they dial 999/112.
The SIP Trunking service supports routing the following dialed short codes:
- 999 (Access to the Emergency services)
- 100 (Access to Operator Assistance)
- 101 (The national single non-emergency number for the Police Force)
- 111 (The national single non-emergency number for the NHS)
- 112 (Access to the Emergency services)
- 116 xxx (Harmonised Services of Social value)
- 118 (UK Directory enquiries)
- 123 (Access to Speaking Clock)
- 18000* to *18009 (Access to Voice Text Services for the Deaf)
- 195 (Access to Blind & Disabled Directory Enquiry Facilities)
4. Service Characteristics
An endpoint represents the unique IP address used as signalling proxy for Customer Premises Equipment (CPE). This signalling proxy supports SIP protocol, transferring VoIP calls to and from the CPE. Each SIP Trunking customer will have one or more endpoints configured on the Connexin SBC. CPE equipment may connect via a single endpoint or multiple endpoints for added resilience.
The following naming convention is used for identifying endpoints on the Connexin network: Unique Endpoint Name + suffix e.g. DC2NYYABC1234_L1
- The Unique Endpoint Name (DC2NYYABC1234) is an identifier to the Connexin SIP Trunk Service and helps ensure all IP interconnects are easily identified for reporting and fault resolution purposes.
Resilient endpoints can be easily identified by virtue of the fact that the naming convention has been extended to append an ‘A’ (active), ‘S’ (standby) or ‘L’ (load share) to the endpoint name. There will typically be 2 endpoints per design though may be more for larger Load share deployments.
- The Suffix differentiates the endpoint design type i.e.
- _L1: A Loadshare endpoint
- _A1: An Active endpoint in an Active /Standby design
- _S1: A Standby endpoint in an Active/Standby design
4.2. Calling Plans and Number formats
Two calling plans are allocated to each Endpoint: one for incoming calls from the customer to Connexin (ingress), and one for outgoing calls from Connexin to the customer (egress). It is a requirement of the SIP Trunking product that the calling party (A-number) be validated to confirm the format and ensure that the number is owned by Connexin, so that the emergency services have an accurate record of the calling customer.
Presentation CLI (A-Number)
A-numbers (SIP FROM, P-Asserted-ID) should be presented in E.164 format, i.e. +441611234567. The A-number is validated by the SBC and if it is not in the Connexin range it is overwritten with an agreed network CLI from the customer’s Connexin-allocated range. It is a requirement of the SIP Trunking service that the calling party (A- number) be validated to confirm the format and ensure that the number is owned by Connexin, so that the emergency services have an accurate record of the calling customer.
If the CPE connected to the Connexin network presents a geographic number, the Connexin Network will pass these details as the A-Number CLI into the PSTN or Mobile networks. This outbound presentation will be supported by default if the number presented is as follows:
- A-numbers are presented by the Customer Premises Equipment (CPE) in the SIP FROM and P- Asserted-ID fields as E.164 format
- It is a Connexin provided Geographic Number that is allocated to the Endpoint at order creation
- A Connexin provided Geographic Number that is allocated to the Endpoint at a later date via a Customer Change Request
- A Geographic number that is ported from another Carrier to the Connexin Network
If the presented number meets these criteria the A-Number CLI will be sent to the PSTN/next hop network. The delivery of the Presentation Number is dependant on the terminating network and is not under the control of Connexin.
The A-number is checked against a database on the Connexin network of geographic numbers that are allocated to the SIP Trunking Endpoint.
If the number presented does not meet the above criteria, the A-Number CLI that will be presented will be a default CLI , which is the first number in the Connexin allocated Geographic DDI range.
For ingress calls, A-numbers are sent to customers as received by Connexin from other network operators.
Network CLI (A-Number)
Every endpoint must have at least one CLI from the Connexin-allocated range i.e. a non-ported in number. This default number is known as the Network CLI and will be presented in the case of emergency calls and other call scenarios where the presented is invalid. Physical address information must be associated with a network CLI and it is the customer responsibility to ensure this address information remains current.
Connexin supports both Network and Presentation CLIs. For calls from the customer to Connexin where the call terminates on the PSTN, the SIP FROM field is mapped to the presentation CLI and the SIP P-Asserted-ID is mapped to the network CLI.
To ensure the correct Network CLI is passed into the Connexin network and then forwarded to the PSTN Connexin will insert the customer Network CLI Number in E.164 format into the PA-ID, replacing any value received from the customer CPE.
For calls from the PSTN to the Gamma SIP Trunking endpoint, the SIP FROM field will contain the Presentation Number when available and the P-Asserted-ID field will contain the Network Number when available. If only the Network Number is available then this will be mapped to both the SIP FROM field and the P-Asserted-ID field.
B-numbers should be sent to Connexin in the following format:
- UK National 0 NSN (National Significant Number) 44 NSN, +44 NSN and 0044 NSN.
- International 00 CC NSN and +CC NSN (+CC NSN format is offered on limited connections currently,
- check with support).
- Service and emergency calls no leading 0(s), + or CC (Country Code) to be used.
As a default configuration B-numbers will be presented to the customer including a leading 0, (0 NSN); however this is flexible, customers can request that a prefix be inserted, or that their number range include a country code.
Number portability for the SIP Trunking service is fully supported and tested. Number Porting changes are currently carried out manually, and it should be noted that BT will only port to a ‘live’ number; hence the Connexin SIP Trunking endpoints must be configured before the porting can take place.
4.3. Maximum Calls per Second (CPS)
For security reasons, Connexin will also set limits for the maximum calls per second (CPS). The limits dependent on the endpoint design type.
If this constraint is reached, Connexin will log and reject calls with a SIP response 486 or 503.
4.4. Channel bandwidth
The table below gives an estimate of the bandwidth requirements for VoIP calls using G.711, and G.729, note that sample periods of 10 and 20 ms only are supported.
The maximum number of concurrent channels = the available bandwidth/total bandwidth, so if for example a customer has a 512 kbps upload line-speed, assuming no contention, using G.729 with a sample period of 20 ms there will be 512/39.2 ̃ 10 usable concurrent channels available. The figures for VoIP using ADSL access are similar.
Table 1 – Suggested MINIMUM VOIP Bandwidth Consumption over Ethernet, Per Channel
Please note that the above represents the best case, un-contended scenario. Use of other transport protocols (e.g. IPSec), coding mechanisms or contended ‘pipes’ will further increase the minimum bandwidth required.
Generally G.729 is the preferred VoIP codec (the algorithm that encodes and decodes analogue voice to and from digital) when access is via ADSL, owing to its efficient use of bandwidth whilst still providing good audio quality.
4.5. Long Duration Calls
Connexin has a policy of terminating any call that exceeds eight hours.
4.6. IP Addressing and DNS
IP version 4.0 is supported. IP Version 6.0 is not supported.
In terms of the CPE interaction with Connexin’s network, DNS capability, including SRV and A record look up, is not supported.
Voice encoding can be G.711 A-law or G.729-A with either of two sample periods, 10 ms and 20 ms. Currently the most common sample period is 20 ms although, customers may opt for 10 ms, which introduces less latency but at the expense of greater bandwidth. It is important to note that Connexin control the sample period in both the egress and ingress directions of calls made by its customers.
Connexin do not support the use of video codecs and customers should make every effort to ensure that no video codecs are included in any SIP requests.
It is recommended that all CPE’s offer G.711 A-law (20 ms) as a common denominator when negotiating calls, although there is no requirement for this to be the first choice of codec.
Connexin polices the media-stream bandwidth based on the negotiated codec. If a CPE exceeds the bandwidth for a specific codec, RTP packets will be discarded and this will result in poor voice quality.
Silence Supression and Comfort Noise: Connexin support for Silence Suppression and Comfort noise is available to Microsoft Lync connections only.
Ptime: Connexin do not support the negotiation of codec Ptime. One of the two supported voice sample periods must be selected, via the Connexin Portal, for the desired codec, so eradicating the need for Ptime negotiation.
To preserve the quality and continuity of the service, Connexin enforce all the parameters in this section. Customers who do not adhere to these definitions are likely to experience issues with their calls, which may include a loss of service.
4.8. Session Failover and Endpoint resilience
The following scenarios will result in an endpoint as being tagged as ‘out of service’. In the case of resilient designs these scenarios initiate failover to alternative sites.
- Destination Unreachable (ICMP unreachable response)
- SIP Ping failure
- SIP failure response code
This happens in two ways:
- Connexin receives an ICMP unreachable message in response to the INVITE message that it sends out to the endpoint. This could indicate that there is no network route to that destination (i.e. the access method has failed) or the destination is temporarily out of service.
- Outgoing INVITEs are retransmitted from Connexin 3 times. If that limit is reached, Connexin will stop trying that endpoint and initiate failover to another endpoint.
In the case of resilient designs, failover is initiated when Connexin concludes that a SIP Trunking endpoint cannot be reached.
SIP Ping failure
If SIP Ping is enabled at both Connexin and the endpoint and SIP Ping fails to respond favorably. Connexin will send a SIP Ping every 60 seconds. The customers CPE should reply with a 200 OK.
If Connexin does not receive a response within 3 pings, the endpoint is removed from service after the
3rd unsuccessful response. SIP Pings will continue to be sent out every 60 seconds and as soon as 3 responses are received the endpoint will be brought back into service.
SIP Response Codes
When Connexin receives a SIP Final Response, code as detailed in Table 9, in reply to one of its own initial INVITE messages a failover will be initiated in the case of a resilient design. If a SIP response code is received which is not detailed in Table 9 then no failover will occur.
If the SIP response includes a Q.850 reason header then this will take precedence over the SIP response code.
Prevention of Session los
In order to minimise the impact of failure of network components, it is recommended that within the end user’s network (Proxies and CPE) session timers, as specified by RFC 4028 are implemented. The preferred method for CP to request a change of the refresh time is by means of a SIP error response 422 or a Re-INVITE.
To avoid a high volume of Invite-422-ReInvite iterations at the start of the call, where the Session-Expires value in the originating Invite is less than 1800 seconds (as per RFC 4028), it is recommended this value should not be less than 600 seconds. This will not prevent Session Interval Too Small responses entirely and it is highly recommended that the CPs that advertise support of the ‘timer’ feature enable their call-servers to resend the Invite request with the new Session-Expires value upon receipt of a 422 response.
The session refresh time cannot be negotiated by means of UPDATE. The session can be refreshed by means of a Re-INVITE or an UPDATE.
4.9. Customer Premises Equipment
The supply, provisioning and support of all hardware at the customer’s site is the responsibility of the end user.
To ensure compatibility of equipment and ease of installation, Connexin are continually undertaking conformance testing with equipment vendors.
For the CPE devices that have been tested, Connexin suggest the end user to contact their equipment vendor for assistance with the installation of this equipment.
4.10. Network Security
Access to the Connexin SIP Trunk Service from the customers CPE is via IP Authentication and as such, the service will only accept traffic from genuine SIP Trunking endpoints that have been registered on the service.
It is the customer’s responsibility to ensure that calls emanating from their endpoint are legitimate and that all practical steps have been taken to avoid fraudulent activity. This would include secure access to their network by means of a Firewall or a Session Border Controller (SBC).
5. Network Access and Connectivity Options
SIP Trunking endpoints can be configured as public IP addresses allowing access to Connexin SIP Trunking services via public Internet or private interconnect. This access can be provided by Connexin or Third Parties with the following option:
5.1. Public Internet
The customer’s CPE (typically an IPBX supporting SIP) is defined as an ‘endpoint’ within the Connexin SBC, with each endpoint capable of having a number of devices connected to it.
A static public IP address assigned by the customer’s ISP will be configured and used to authenticate the endpoint, providing duplex interconnection to the PSTN.
Quality of service
It is not necessary for the customer to mark traffic on the egress to their network before it enters the Connexin device terminating the internal cross connect and Connexin will not deliver marked voice traffic (Signalling or Media) to the customer.
Connection Types include copper, single or multi-mode fibre and bandwidths ranging from 10Mbps to 1Gbps. Interconnect port types include Layer 3 BGP, Layer 2 VLAN or Layer2 801q VLAN.
6. Protocol & Signaling support
Connexin can offer SIP signalling transport over UDP. The standard is UDP. In cases where PBXs use TCP signalling, SIP Proxy servers/IP gateways are required to convert to UDP on the customer’s premises.
6.1. RFC Support
The Connexin SIP Trunking service supports the following RFC’s. Full compliance is subject to differences in interpretation, interoperability constraints and the exceptions noted below.
Connexin SIP Trunk Service provides SIP signalling as a method for Communication Providers to inter-connect with Connexin’s VoIP network, supporting VoIP to VoIP calling as well as calls to/from the PSTN.
Connexin SIP Trunk Service supports the transport of SIP signalling messages using UDP. SIP messages sent using TCP(except for MS Lync), TLS, SCTP and IPSEC are not supported at present.
SIP V2 is supported between the SBC and the customer CPE. The SIP standard is documented in the Internet Engineering Task Force (IETF) RFC 3261.
Please note that this service does not support H.323, SIP-I, SIP-D and SIP-T.
Format of the SIP INVITE Field
The SIP header requirements in the INVITE packets originated from the CPE should be set as follows:
- Request URI must contain the B-number followed by the assigned Connexin SIP gateway IP address: INVITE sip:01618700000@”IP Address”;user=phone SIP/2.0
- The FROM header must contain your public facing IP address and originating CLI: FROM: <sip:+441618777148@”IP Address”>; tag=3528194925-554920
- The TO header must contain the assigned Connexin SIP gateway IP address and the B-number*:* To: <sip:01618700000@”IP Address”;user=phone>
- SDP payload must be present, and must contain your public IP address. See section 4.7 for supported codecs.
Traffic on the following ports must be forwarded through relevant routers and firewalls on the customer premises to allow access to the Connexin SIP Trunking Network:
- UDP Port 5060 egress/ingress
- UDP all ports between 6000 – 40000 egress/ingress
For ingress calls the INVITE Request Line must contain a SIP URI.
For egress calls from Connexin to the customer the INVITE Request Line will contain a SIP URI.
Example of the initial SIP INVITE
The SIP gateway here is 188.8.131.52 – this will be stated in the SIP Trunking order confirmation.
The CPE IP address is 184.108.40.206 – the public IP address with which Connexin’s SBC communicates. The fields highlighted below must contain the CPE IP address. If the PBX is operating behind a NAT these addresses will need to be NAT’ed by a SIP aware device e.g. an SBC, a router with an ALG, the PBX itself via STUN.
INVITE sip:email@example.com SIP/2.0
Via: SIP/2.0/UDP 220.127.116.11:5080;branch=z9hG4bK-a8b33135
From: “+441414040025″ <sip:+firstname.lastname@example.org>;tag=9fa8f5c74acc1965o0 To: <sip:email@example.com>
CSeq: 101 INVITE
Contact: “+441414040025″ <sip:+firstname.lastname@example.org:5080>
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, replaces
o=- 14849 14849 IN IP4 192.168.1.8 s=-
c=IN IP4 18.104.22.168
m=audio 7776 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000
a=fmtp:18 annexb=yes a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The Via header (the topmost via if there are multiple) is used in conjunction with the layer 3 IP address for authentication. If the address is unknown to our SBC (e.g. LAN address) it will respond 403: Forbidden.
The Contact header advises our SBC where to respond to. If this is a LAN address, or some other addresses which you are not expecting traffic on, the 2-way dialog will be disrupted and calls will not setup correctly.
The c= parameter in the SDP (connection address) is the address to which your user agent is requesting media (RTP) is sent. Again, this needs to be reachable by Connexin’s SBC. If this is not NAT’ed, and you send a LAN IP address, the call may setup OK but you will get one way speech (with the remote party not heard by the SIP Trunking user)
7.3. Supported SIP methods and responses
The list of supported SIP methods is detailed below.
Supported SIP methods