SIP Trunking External Technical Guide
Contents
Disclosure / Confidentiality
The information contained in this document provides technical guidance on Colt’s VoIP Access service and is provided for information only. It does not form part of any contract with Colt. This document may be distributed external to Colt with written permission
Copyright © Colt Group
No part of this document may be reproduced or adapted in any form, including photocopying or storing it by electronic means, except as is necessary for the purpose of the recipient’s dealings with Colt, without the written permission of Colt. Any copies made of any part of this document shall include the notice:
© 2025 Colt Technology Services. The Colt name and logos are trademarks. All rights reserved. No information contained in this document shall be disclosed to any third party without the written permission of Colt.
1. Document Information
1.1 Overview
| Document Name: | SIP Trunking External Technical Guide |
| Version Number: | 2.1 |
| Issue Date: | 10-02-2025 |
| Authors: | Richard Taylor, Harsha Hegde, Rama Vidyasankar,Satyendra Gupta |
| Owner: | |
| File Name & Location: |
1.2 Version History
| Version | Issue Date | Author | Reason for change |
|---|---|---|---|
| 1.1 | 24-Mar-16 | OS | Reaction to Mohieddine’s and Reinhard’s feedback |
| 1.2 | 10-June-16 | RT | Reaction to Ralf and Vincents Feedback |
| 1.3 | 22-June-16 | RT | Global SIP added, Supplementary Services added |
| 1.4 | 09-Nov-16 | RT | Added note about MKI not supported for SRTP |
| 1.5 | 18-May-18 | HH | Media port range of SBC7K added, G722 transcoding supported. And other minor changes |
| 1.6 | 10-AUG-18 | HMF | PN feature update |
| 1.7 | 18-OCT-18 | HH | Media port range modified. |
| 1.8 | 01-Apr-19 | SGK | Appendix updates |
| 1.9 | 27-Jan-20 | HH | Line added to Access type IP-VPN, Changes in section 4,section 5, 6,7,8 and. Appendices C&D. EPN as standard option removed. |
| 2.0 | 05-Jan-24 | HH | Minor Changes |
| 2.1 | 10-FEB-25 | HM | Adding 6.9 CCP Changes to section 8.3 Call forwarding |
2. Glossary
| CC | Country Code |
| CdPN | Called Party Number or ‘B’ Number |
| CgPN | Calling Party Number or ‘A’ Number |
| CLI | Calling Line Identification |
| CLIP | Calling Line Identification Presentation (or Caller ID) |
| CLIR | Calling Line Identification Restriction |
| CAC | Call Admission Control |
| CAPS | Call Attempts Pre Second |
| CCP | Concurrent Call Pool |
| CRL | Call Rate Limit |
| DN | Default Number |
| EPN | Ethernet Private Network |
| FQDN | Fully Qualified Domain name |
| GN | Generic Number (ISUP) |
| ICR | Inbound Call Re-Routing (Product Feature) |
| MGW | Media Gateway |
| NAT | Network Address Translation |
| NP | Network Provided (Screening) |
| NSN | National Significant Number |
| PAI | P-Asserted-Identity (SIP) |
| PDD | Post Dial Delay |
| PI | Presentation Indicator (ISUP) |
| PN | Presentation Number |
| PNR | Partial Number Replacement (Product Feature) |
| PPI | P-Preferred-Identity (SIP) |
| RDN | Redirecting Number |
| RPI | Remote Party Id (SIP) |
| SBC | Session Border Controller |
| SDES | Secure Descriptions |
| SI | Screening Indicator (ISUP) |
| SIP | Session Initiation Protocol |
| SRTP | Secure Real Time Protocol |
| TLS | Transport Layer Security |
| Trunk | A logical entity used for VoIP signalling and media, defined between a unique pair of IP addresses on the Colt SBC and Customer IP-PBX Equipment. |
| Trunkgroup | A group of trunks that share the same DDI number ranges and typically used for resiliency |
3. Overview
Figure 1. VoIP Access Overview
VoIP Access is a SIP Trunking service that provides PSTN Connectivity for customers with an IP-PBX.
This document describes the technical specification of service including:
- SIP protocol support – IETF RFC and other standards compliance, supported protocol features and call flows
- Bearer Services support – Codecs, Fax, Modem, DTMF, and Transcoding
- Numbering & Routing – Supported number / URI formats, CLI handling, Emergency Call Handling, Call Re-routing
- Access Technologies -IP Addressing, NAT traversal, QoS
- Security – Security features, SIP-TLS and SRTP encryption
4. Numbering & CLI Features
4.1 Limitations
A maximum of 300 main numbers except for Spain. For Spain maximum main numbers limit is 100. Number ranges are supported up to 1000 numbers in blocks per trunkgroup ( e.g. 0-100, 200-250, 300- 500 etc..)
4.2 Number Formats
4.2.1 Outgoing Calls (Customer → Colt)
For outgoing calls, the A Number and B Number can be sent in the following formats. In general, COLT recommend to use the number-format +CC NSN for all headers.
| A Number | B Number | |
|---|---|---|
| National Call | +CC NSN 00 CC NSN 0 NSN* NSN | +CC NSN 00 CC NSN 0 NSN* NSN |
| International Call | +CC NSN 00 CC NSN 0 NSN* NSN | 00 CC NSN +CC NSN |
*In countries where national dialling prefix 0 is used
Note: Short-code emergency and special numbers can be sent in NSN (shortcode) or +CC NSN format.
4.2.2 Incoming Calls (Colt → Customer)
For incoming calls, the A and B number can be sent in the following formats (configurable)
Defaults are highlighted
| A Number | B Number | |
|---|---|---|
| National Call | 0 NSN +CC NSN | 00 CC NSN +CC NSN 0 NSN NSN Extension Digits |
| International Call | 00 CC NSN +CC NSN | 00 CC NSN +CC NSN 0 NSN NSN Extension Digits |
4.3 SIP URI Format
Both sip: and tel: (RFC2806) URI formats are supported.
For sip URI formats, the user part must be a valid telephone number in one of the formats described above OR ‘anonymous’. The user=phone parameter may or may not be included. The host part can be an IP address (of the SBC) or a domain name.
4.4 CLI Features
4.4.1 CLIP Screening and CLIR per Call (Default Setting)
This is the default CLI setting on VoIP Access trunks. The CLI from the ingress SIP call leg is normalised and screened to ensure it belongs to a number range allocated to the trunk. If screening fails then the customer Default Number is sent in the Calling Party Number (CgPN) on the egress leg. CLI restriction (CLIR) can be set per call using SIP privacy extensions, by inserting an anonymous From header, or by using a dialling prefix.
Note: Customer shall inform us which number to be used as a default number.
SIP Header Usage
For CLIP Screening, The CLI is taken from the following SIP headers in order of precedence:
- P-Asserted-Identity (PAI)
- P-Preferred-Identity (PPI)
- Remote-Party-Id (RPI)
- From
Example SIP INVITE including From and P-Asserted-Id
In this example the CgPN is taken from the P-Asserted-Identity header
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.91.115.42:5065;branch=z9hG4bK-9796-1-0
From: ;tag=9796SIPpTag001
To: Pstn
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5065
P-Asserted-Identity:
Max-Forwards: 70
Subject: P Asserted Id Test
Content-Type: application/sdp
Content-Length: 135
CLIR per call
CLIR per call can be signalled as follows
- Using a dialling prefix: 141 (UK, Ireland) or 067 (Spain)
- By inserting P-Asserted-Identity header and Privacy: Id header (RFC3323/3325)
- By inserting an Anonymous From header e.g. sip:[email protected] (RFC3323)1
The above results the CgPN being set to “presentation restricted” on the egress leg
Call Forwarding
1 The user part of the From URI can also be ‘Unknown’ or ‘Restricted’ or ‘Unavailable’ (First letter lower case also supported)
If a call is forwarded by the customer, the Redirecting Number (RDN) should be populated in the Diversion Header (RFC5806). If present, this header is used for screening and allows the original calling party number (Colt or Other CLI) to be sent to the far end.
The Redirecting Number can be sent in international (+CC NSN or 00CC NSN), national (NSN with or without national dialling prefix) format.
Example SIP INVITE including Diversion header
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.91.115.42:5065;branch=z9hG4bK-9817-1-0
From: ;tag=9817SIPpTag001
To: Pstn
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5065
P-Asserted-Identity:
Diversion:
Max-Forwards: 70
Subject: P Asserted Id Test
Content-Type: application/sdp
Content-Length: 135
Special Cases
Some types of equipment make use of Referred-by or History-Info headers to capture the redirecting number information. These types of header are currently not supported but can be accommodated on request by applying SIP Message Manipulation rules that copy the content of these headers to the Diversion header.
4.4.2 CLIR Permanent
A trunk can be configured to permanently mark the Calling Party Number as restricted. By default, the redirecting number or generic number (if present) are not marked as restricted.
4.4.3 CLIP No Screening
Calling Line Identification No Screening (CLIPNOSCN) allows an additional CLI to be sent for display purposes. The customer sends the display CLI in the SIP From header and the COLT CLI (used for screening, CDRs, emergency calls) in SIP P-Asserted-Identity header. If the customer is not able to send a P-Asserted-Id header, the display CLI can still be sent in the From header but the Calling Party Number (Network CLI) will be set to the customer default number.
The display CLI can be sent in international (+CC NSN or 00CC NSN) or national (NSN with or without national dialling prefix) format only.
Note 1: This feature does not guarantee that the display CLI is presented to the called party. Support may vary depending on the country and the other network operators used to route the call.
Note 2: In the CDR reports the screened COLT CLI (if PAI sent) or the Default Number is captured as the Calling Party Number. The Display CLI is currently not captured in CDR reports
4.4.4 Presentation Number
Presentation Number allows an alternative CLI that has been pre-authorised by Colt to be sent for display purposes.
The Presentation Number feature we only support E164 number format
Note: This feature does not guarantee that the display CLI is presented to the called party. Support may vary depending on the country and the operators involved.
4.4.5 Multi-site Configurations
Multi-site configurations are those with two or more DDI ranges (usually with different LACs) configured on the same trunk. It is assumed that each DDI range associated with a different customer site or location.
Multisite configurations involve 2 stages of CLI screening i) check CLI belongs to a Trunk Group ii) check CLI is valid for given site. This applies to the standard CLIP Screening feature and also applies to calls which include a Redirecting Number. The CLIP No screening feature is also supported for multisite though the customer is expected to send the display CLI and Colt CLI in the From and PAI headers respectively. If the COLT CLI is not present in PAI, then the default number is used as the network CLI and features such as emergency call handling may not work as expected. Presentation Number is also supported without any restrictions
In order to support emergency call handling, the customer is required to send a valid Colt CLI so that the site that originated the call can be identified. If Colt receives a call with an invalid CLI, the call may fail
The CLI can be sent in international (+CC NSN or 00CC NSN), national (NSN with or without national dialling prefix) format only.
4.5 DNS resolution Support
FQDN configuration is supported. DNS support for resolving FQDNs based on RFC 3263 (Locating SIP Servers) is supported.
4.6 Emergency Call handling
Emergency calls can be sent using the national short code format e.g. 112, 999 or may be prefixed by the country code e.g. +44999
For multi-site configurations, the customer is required to send a valid Colt CLI so that the site that originated the call can be identified and the call routed correctly. If the CLI is invalid the call may be routed incorrectly
5. Signalling
5.1 SIP Protocol Support
5.1.1 Standard Compliance
The VoIP Access service is complaint with the following standards for basic SIP interoperability:
RFCs (Note: These RFC are not the only one’s supported, however there are most common RFCs)
| RFC 3261 | SIP |
| RFC 3264 | Offer/Answer |
| RFC 3311 | UPDATE |
| RFC 3262 | 100rel / PRACK (configurable per trunk) |
| RFC 4028 | SIP Session Timers (configurable per trunk, INVITE or UPDATE method) |
| RFC 3323/3325 | SIP Privacy extensions (Privacy/P-Asserted-Id) |
| RFC 5806 | Diversion Header |
| RFC 4244 | History-Info* |
| RFC 3515 | SIP REFER* |
| RFC 3892 | Referred-By Header*RFC 18 |
| RFC 3326 | SIP Reason Header |
| RFC 1889 & 1890 | RTP – Real-Time Transport |
| RFC 2327 | Session Description Protocol (SDP) |
| RFC 2782 | Describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.* |
| RFC 2806 | URLs for Telephone Calls* |
| RFC 2976 | SIP INFO Method |
| RFC 3204 | MIME Type for ISUP and QSIG |
| RFC 3311 | SIP UPDATE Method |
| RFC 3362 | Real-time Facsimile (T.38) – image/t38 MIME Sub-type Registration |
| RFC 3398 | ISUP to SIP Mapping |
| RFC 4028 | Session Timers in SIP |
| RFC 4474 | Authenticated Identity Management |
| RFC 7433 | Call control UUI data |
*Restrictions apply
Other Specifications
SIP-ISUP interworking according to ITU-T Q.1912.5 and RFC 3398
SIP Connect 1.0 – Compliant
SIP Connect 1.1 – Partially Complaint
- Registration mode is not supported
- TLS is optional (not mandatory)
- The following RFCs are not supported by Sonus: RFC 4967 (Dialstring URI parameter), RFC 5031 (Emergency services URN), RFC 5280 (X.509 PKI CRLs), RFC6140 (“Registration for Multiple Phone Numbers), RFC5876(Updates to Asserted Identity in the SIP protocol), RFC4566 (RFC2327 SDP is supported)
Table 1. Supported SIP Methods
| Method | Supported? |
|---|---|
| INVITE | Y |
| ACK | Y |
| BYE | Y |
| CANCEL | Y |
| UPDATE | Y |
| PRACK | Y |
| OPTIONS | Y |
| REGISTER | N |
| SUBSCRIBE | Y* |
| NOTIFY | Y* |
| INFO | Y* |
| REFER | Y* |
*Supported but normally not used and not used as part of standard product feature set
5.1.2 Transport Types
The following SIP transport types are supported:
SIP-TCP (Port 5060)*
SIP-UDP (Port 5060)*
SIP-TLS (Port 5061)
The TCP/UDP port is fixed on the SBC but can be customised for requests sent towards the customer
The maximum SIP PDU size is 6 K bytes
*Colt can support other than 5060 as signalling port for receiving SIP signalling, however this will be bespoke configuration.
Note: Colt can support any signalling port towards customer SIP equipment.
5.1.3 SIP Trunking Modes
VoIP Access supports Static Mode SIP trunking whereby a SIP trunk is established between a fixed source and destination IP address on the Colt SBC and Customer IP-PBX.
Registration Mode, where the IP-PBX registers to the network and does not require fixed source IP address, is currently not supported.
5.1.4 SIP Timers
SIP Timers protocol retransmission timers are set to the default values recommended in RFC3261 – T1=500ms, T2=4000ms.
The INVITE retransmission, Timer B, applicable for SIP-UDP, is set to T164 by default. For resilient services it is reduced to T13=1.5s (1 retransmission)
An answer supervision timer is set to 300s on Colt gateways (timeout for interval between first 18x and the call being answered). Note that it is possible that calls may be released earlier by an answer timeout elsewhere in the network
The Long Duration Call timer is set to 2880mins (48hrs)
5.1.5 Session Timers
By default SIP Session Timers (RFC4028) are supported using the Re-INVITE method and Session-Expires 1800s (30mins) and MinSE=90s. If the session refresh causes issues e.g. call dropped or muted it can be disabled on request. Note that the IP-PBX does not need to support Session Timers (Colt SBC will act as Refresher in this scenario).
5.1.6 SIP Release to Cause Code Mappings
The table below describes the default mappings (based on RFC3398) between ISUP release cause and SIP error response message sent to and from the customer IP-PBX
In some cases a (country specific) announcement is played before a SIP release is sent ( Can be modified to send SIP release only on customer request)
If a call is released due to a script e.g. call barring the release cause is determined by the script and mapping to SIP release will be as per table below.
Table 2. ISUP CPC-to-SIP mapping
| ISUP | Definition | SIP | Announcement2 |
|---|---|---|---|
| 1 | Unallocated Number | 404 | yes |
| 2 | No Route to Specified Network | 404 | |
| 3 | No Route to Destination | 404 | yes |
| 4 | Send Special Info Tone | 500 | |
| 16 | Normal Call Clearing | 480 | |
| 17 | User Busy | 486 | |
| 18 | No User Responding | 408 | |
| 19 | No Answer From User | 480 | |
| 20 | Subscriber Absent | 480 | |
| 21 | Call Rejected | 403 | |
| 22 | Number Changed | 410 | |
| 27 | Destination Out of Order | 502 | yes |
| 28 | Address Incomplete | 484 | yes |
| 29 | Facility Rejected | 501 | |
| 31 | Normal Unspecified | 480 | |
| 34 | No Circuit Available | 503 | yes |
| 38 | Network Out Of Order | 503 | yes |
| 41 | Temporary Failure | 503 | |
| 42 | Switching Equipment Congestion | 503 | yes |
| 47 | Resources Unavailable Unspecified | 503 | |
| 55 | Incoming Call Barred | 403 | |
| 57 | Bearer Capability Not Authorised | 403 | |
| 58 | Bearer Capability Presently Not Available | 503 | |
| 65 | Bearer Capability Not Implemented | 488 | |
| 87 | Not Member of CUG | 503 | |
| 88 | Incompatible Destination | 503 | yes |
| 102 | Recovery On Timer Expiry | 504 | |
| 110 | Unrecognised Parameter | 488 |
Table 3. SIP to ISUP CPC Mapping
| SIP | Definition | ISUP | Crankback3 |
|---|---|---|---|
| 400 | Bad Request | 41 | yes |
| 401 | Unauthorized | 21 | |
| 402 | Payment Required | 21 | |
| 403 | Forbidden | 21 | |
| 404 | Not Found | 1 | |
| 405 | Method Not Allowed | 63 | |
| 406 | Not Acceptable | 79 | |
| 407 | Proxy Authentication Required | 21 | |
| 408 | Request Timeout | 102 | |
| 409 | Conflict | 41 | yes |
| 410 | Gone | 22 | |
| 411 | Length Required | 127 | |
| 413 | Request Entity Too Large | 127 | |
| 414 | Requested URL Too Large | 127 | |
| 415 | Unsupported Media Type | 79 | |
| 416 | Unsupported URI1 Scheme | 127 | |
| 420 | Bad Extension | 127 | |
| 421 | Extension Required | 127 | |
| 423 | Interval Too Brief | 127 | |
| 480 | Temporarily Not Available | 18 | |
| 481 | Call Leg or Transaction Does Not Exist | 41 | |
| 482 | Loop Detected | 25 | |
| 483 | Too Many Hops | 25 | |
| 484 | Address Incomplete | 28 | |
| 485 | Ambiguous | 1 | |
| 486 | Busy Here | 17 | |
| 487 | Request Terminated | 31 | |
| 488 | Not Acceptable Here | 31 | |
| 500 | Internal Server Error | 41 | yes |
| 501 | Not Implemented | 79 | |
| 502 | Bad Gateway | 38 | yes |
| 503 | Service Unavailable | 41 | yes |
| 504 | Server Timeout | 102 | |
| 505 | SIP Version Not Supported | 127 | |
| 513 | Message Too Large | 127 | |
| 600 | Busy Everywhere | 17 | |
| 603 | Decline | 21 | |
| 604 | Does Not Exist Anywhere | 1 | |
| 606 | Not Acceptable | 31 | |
| N/A | Internal: No Route to Specified Network | 2 | yes |
| N/A | Internal: No Route to Destination | 3 | yes |
| N/A | Internal: No Circuit Available | 34 | yes |
| N/A | Internal: Switching Equipment Congestion | 42 | yes |
| N/A | Internal: INVITE Request timeout/IP Address unreachable | 151 | yes |
5.2 Supported Call Flows
5.2.1 Early Offer
This is the typical call flow for an outgoing call where the SDP Offer is sent in the initial INVITE request (early offer). PRACK/100 rel is enabled by default. Depending on the terminating call leg, there may be one or more UPDATEs sent before answer or RE-INVITE after answer to modify media parameters
Figure 2. Example Early Offer SIP INVITE (Outgoing Call)
5.2.2 Late Offer
Late Offer is where the initial INVITE request does not include an SDP offer. In this case the Colt SBC makes the initial SDP offer in the 183 (rel) and includes the codecs configured on the trunk The SDP answer is expected in the PRACK. In case there is no 183 rel/PRACK, the SDP Offer will be sent in the 200OK (INVITE) and SDP answer is expected in the ACK (INVITE)
In general, the use of early offer is recommended. In the case of late offer pre-announcement or ringing-tones may not heard completely.
Figure 3. Example Late Offer INVITE (Outgoing Call)
Note: For Colt side initiated calls, SDP is always sent.
5.2.3 Call Hold
Call Hold/Resume is supported using Re-INVITE with SDP a=sendonly/inactive/sendrecv as well as the older method with SDP c=0.0.0.0
5.2.4 Call Forward
5.2.4.1 Call Forward using INVITE
In This scenario the IP-PBX initiates a second call leg by sending a new INVITE back to the SBC. For the CLI to be handled correctly, the redirecting number (a valid number range from the customer DDI range) must be populated in the Diversion header. Both the signaling and media are anchored at the IP-PBX
Figure 4. Example Call Forward using INVITE
5.2.4.2 Call Forward using INVITE with optimized media
In this scenario, a late offer SDP exchange on the 2nd call leg, is used to optimize the media path between the 2 call legs (the source and destination of the media stream are the same physical media interface on the SBC). Releasing the media path back to the SBC reduces bandwidth resources. The signaling remains anchored at the IP-PBX
This feature is available by default as long as the PBX supports the required call flow. The second call leg is treated as a separate outbound call and will be billed as such.
Figure 5. Example Call Forward using INVITE with Optimized Media
5.2.4.3 Call Forward using SIP Re-direct
Call forward based on a SIP 3xx Redirection Response is not supported.
5.2.5 Call Transfer
The SIP REFER (RFC3515) method allows an IP-PBX to request the network to transfer a call leg and be notified of the outcome. It is typically used for consultative or non-consultative(blind) call transfer and allows the IP-PBX/endpoint initiating the transfer to drop-out of the call (also known as ‘Take back and Transfer’). This feature is available on special request ONLY and is subject to the limitations outlined below
Figure 6. Example SIP REFER for Non-Consultative Transfer between IP Endpoints
Since there are a lot variations in the usage of SIP REFER, it is advisable to provide a call trace to validate the call flow and header content and ensure in can be supported properly.
Limitations
- REFER target must be an IP endpoint on the same or alternate trunk.
- In general, only non-consultative(blind) transfer is supported. Consultative transfer which relies on the Replaces header (RFC3891) is not supported.
- The Referred-By header (RFC3892) is used to capture the CLI of the IP-PBX/endpoint transferring. Since a CLI in the Referred-By header cannot be screened by Colt, the transferred-to party will see the default CLI configured on the Colt trunk.
5.2.6 Mid Call codec renegotiation, via SIP RE-INVITE
Mid-call codec re-negotiation is supported. If the INVITE does not contain an SDP offer, then all codecs configured on the trunk will be offered.
5.2.7 Forked Calls
The Colt network does not fork SIP request or responses
When upstream forked requests are received, the original request is processed as normal and other requests are rejected with a 482 (Loop Detected)
When a request is forked downstream, the most recent SDP from forked provisional responses and the SDP from the first 200 (as the final SDP) are used.
6. Bearer Services
6.1 Codecs
The following audio codecs are supported for VoIP Access. Not all codecs are enabled by default. The far right column describes whether it’s possible to transcode to other codecs e.g. G.729a to G.711 if there is a codec mismatch.
| Codec | Sample Size | Enabled by Default? | Transcode Support? | |
|---|---|---|---|---|
| 1 | G.729A | 20ms | Y | Y |
| 2 | G.711alaw | 20ms | Y | Y |
| 3 | G.726 (32Kbps) | 20ms | Y | Y |
| 4 | G.722 | 20ms | N | Y |
| 5 | G.722.1 | 20ms | N | Y |
| 6 | G.711ulaw | 20ms | N | Y |
| 7 | iLBC (15.2Kbps)* | 20ms* | N | Y |
*iLBC can fallback to lower bit rate 13.33Kbps/30ms depending on mode parameter in offer/answer
Silence suppression and comfort noise based on RFC3389 (for codecs that do not support discontinuous transmission) are not enabled by default. Note that Colt gateways may insert comfort noise towards the PSTN in case of discontinuous transmission.
Video codecs are currently not supported.
Important Note: In order to insure 100% successful IP to IP calls, we strongly advice customers to support G711Alaw 20ms codec as a fall-back. If customers cannot support the G711Alaw codec then Colt can provide a transcoding capability, however this is a chargeable feature. If neither of above requirements are met, customer takes the risk of having IP to IP calls failed when our end-supplier supports G711 alaw 20 ms only.
RTCP
RTCP is disabled by default but can be enabled on request. RTCP-XR support is a bespoke configuration.
6.2 Media Path
RTP ports used on the Colt SBC are dynamically allocated from UDP port range 1024 to 65148) excluding ports 5060/5061 which are reserved for signalling. There is no restriction on peer RTP port range.
The media path for IP-IP calls between trunks is always anchored at the SBC. Media bypass (also known as media optimisation or direct media) where the media path is established directly between customer endpoints is not supported.
For security, by default, if the source IP address of incoming RTP packets differs from the outbound RTP IP address (negotiated in the SDP Offer/Answer), the traffic will be discarded by the Colt SBC (resulting in one-way audio). This feature can be disabled on request.
- Media IP addresses are negotiated during call setup
- On the SBC, one or more IP addresses are allocated for media. Media addresses are separate from signalling addresses but are in the same subnet and VLAN.
- On the Customer Site, media IP addresses belong to the IP-PBX and IP Phones. They do need to be configured on the Colt trunks but must be reachable from the Colt SBCs
6.3 Transcoding
Transcoding is an optional feature and is disabled by default. It allows customers to connect equipment that supports only a limited set of codecs. Transcoding involves translating the media stream from one encoding format on ingress, to another encoding format on egress and vice versa. Transcoding ensures that calls can be established even when there is no common end-to-end codec.
- In general, transcoding will only be required where the customer has endpoints that do not support G.711alaw (either 1st choice codec or as a fall back)
- It only applies to IP-to-IP call flows (see exceptions below)
- When transcoding is enabled, it is applied selectively, on a call-by-call basis.
- Transcoding only occurs as a last resort when the network and endpoints cannot agree a common codec end- to-end. Usually, this occurs regardless of codec priorities configured in the network and on the endpoints (see exceptions below)
- Transcoding consumes additional DSP resources on the SBC and is only configured when explicitly required
When the codec list on a trunk is customised (codecs removed or added) selective transcoding is enabled by default for all all codecs apart from G.711alaw.This is done to ensure interoperability with other endpoints in the Colt network.
Transcoding for Fax
Fax passthrough is supported but not T.38 transcoding, it will not be configured since in most cases fallback from T.38 to G.711 will work. Transcoding can be enabled manually if a fault is raised.
Transcoding for DTMF and sample size
In some cases a mismatch of DTMF or sample size encoding may cause a less preferred codec to be selected or a call may fail. In these cases, manual configuration is required to support ‘Different DTMF Relay’ or ‘Different Sample Size’
6.4 Fax
Group 3 Fax (V.27 ter, V.29, and V.17) is supported using the T.38 protocol. Typically, the answer side will detect the Fax tone (2100Hz CED answer tone) and initiate a Re-INVITE for T.38. Fallback to G.711 is also supported for endpoints that do not support T.38.
Super Group 3 (V.34) is detected as modem call and will use G.711 passthrough.
Fax ECM (Error Correction Mode) is disabled by default (requires additional DSP resources) but can be enabled on request.
For IP-PBXs that only support G.711 Fax passthrough, fax transcoding (G.711<->T.38) can be enabled to ensure interoperability.
6.5 Modem
Modem Passthrough (V.34) is supported with codec up-speed to G.711 using Re-INVITE. Echo cancellers and Non-linear processing are disabled on detection of a 2100Hz phase reversing modem tone.
6.6 DTMF
Out-of-band DTMF is supported using RFC4733 (updates RFC2833) which defines the RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. The default payload type is Use of RFC4733 avoids distortion that may be caused by compressed audio codecs and avoids signalling path delay associated other out-of-band DTMF techniques such as SIP INFO.
Note: DTMF using SIP INFO is not recommended and supported only on a best effort basis
6.7 Clear Channel
64k unrestricted data channel over RTP can be supported using RFC4040 (Clearmode). The default payload type is 125
Caveats
- Customer endpoints need an accurate clock source to prevent bit errors.
- Clear Channel does not work with applications that require channel bonding e.g. ISDN video
6.8 Call Admission Control (CAC)
Call Admission Control (CAC) defines the maximum call rate and maximum number of concurrent calls that can be supported on a trunk.
A default call-limit of 200 concurrent calls is applied to all trunks unless otherwise specified. There is also a default call rate limit (CRL) of 10 call attempts per sec (CAPS) applied to all trunks. Both limits can be increased on request. Our maximum is 30 calls per sec.
When the call limit or CRL is exceeded on a trunk, the Colt SBC returns a Q.850 release cause 34 or SIP 503 service unavailable error response. When the call limit is exceeded and resilient trunks are available, calls may overflow onto the other trunks.
The call rate limiting uses a token bucket policer which allows the call rate to temporarily burst above the defined limit. Only the calls that exceed the limit are dropped and there is no temporary lockout.
Note: CAPS will be set to lower limit, if call duration is very short. Discuss with local Solution Architect for more information.
6.9 Concurrent Call Pool (CCP)
Apart from call admission control, this feature will allowed to configure combined CAC limit among the two or more Trunks configured in the same SBC. Share pool CAC limit and individual CAC limit together will decides number of call allowed through the trunk. E.g Shared pool limit is assigned as 15, between two trunks and individual call limit is 10, then concurrent calls between two trunk will not exceed 15 and for single trunk there will not be more than 10 calls are permitted.
6.10 Tones & Announcements
The following country-specific tones & announcements are supported
- Local ring back tones played to calling party upon receipt of an alert indication without a media stream or without an indication of in-band tones e.g. 18x with no SDP.
- Tone or announcement played when a call fails – see Section 5 SIP Release to Cause Code Mappings
6.11 Echo Cancellation
VoIP Gateways are equipped with ITU G.165 complaint echo cancellers. These are configured globally (cannot be adjusted per trunk) with an echo tail of 128ms
7. Access Technologies
7.1 Overview
The figure below describes the high level network setup and IP addressing between the Colt VoIP POP and customer equipment.
Figure 7. VoIP Access IP Addressing
For all types of access technology, the following IP address information is required to setup a VoIP Access SIP trunk:
IP-PBX IP Address – the host IP address that initial SIP Requests are sent to.
IP-PBX IP Range – the host or subnet from which SIP requests/responses may originate in the customer network (often the same as IP-PBX IP Address).
Except for NAT customers, both of these addresses must be reachable from the Colt SBC i.e. routable over the Internet, IP-VPN, or Ethernet service
Any subnets used to terminate RTP media e.g. phones, music-on-hold server, conference servers etc must also be reachable from the Colt SBC.
Additional IP addressing may be required depending on the access type used. These are described below.
7.2 Internet
Colt VoIP POPs are connected to the Colt Internet backbone and allows trunks to be established over the public Internet. A set of shared signalling and media public IP addresses are configured on each SBC and are reachable from the Internet.
Colt SBC IP Addressing
Each VoIP POP is configured with Public IPv4 subnet used for Internet connected trunks. Each SBC is configured one or more public SIP signalling and media IP addresses which are shared by all customers and trunks.
NAT Traversal
If the customer IP-PBX and/or IP phones are located behind NAT/NAPT devices , additional configuration is required.
Figure 8 NAT Traversal
Static Port Mapping
The IP-PBX must be reachable via external public IP Address on TCP/UDP port 5060 (or a different port if specified). If the IP-PBX is behind NAT, this will be the external Public IP Address of the NAT device and static NAT ip address/ port mapping will required to forward SIP traffic to the internal private IP address of the IP-PBX.
The static ip/port mapping must be configured on the NAT device and this could be a Colt CPE (configured for NAT) or a customer device (router, firewall etc)
Note: dynamic ip/port mapping using SIP Registration is not supported.
In addition to the above configuration on the customer premise, the Colt SBC must also be configured for NAT traversal
NAT Traversal for Media & Signalling
This feature ensures that the SBC can handle media and signalling to devices located behind NAT/NAPT devices. For signalling it ensures SIP requests within a dialog are routed to the public IP/port of the NAT device instead of the private address in Contact/Route Set. For media, it enables media latching, whereby the SBC waits for the endpoint to send RTP in order to learn the IP address/port to send on instead of using the information negotiated in SDP
NAT Qualification
NAT Qualification is designed to avoid scenarios where media NAT traversal results in media deadlock (no audio in send or receive direction). For example this occurs where a call is forwarded by the IP-PBX, back to the same Colt Trunk, and the media path is via a device is behind NAT. In this case both media ports try to perform latching and prevent RTP being sent in either direction.
To minimise the occurrence of this scenario, the NAT Qualification Table is used to selectively disable NAT traversal techniques for media end points that are not behind NAT but which belong to a trunk which is configured for NAT traversal.
By the default, when NAT Traversal is enabled, the NAT Qualification table is configured with the default RFC1918 private addresses unless otherwise specified
SIP Request URI formatting for NAT
By default, when NAT Traversal is enabled, the host part of the SIP Request-URI is modified to include the private IP address of the IP-PBX.
If multiple trunks are required on the same SBC e.g. for resiliency or multi-country support, up to 26 trunks can be setup with separate SIP signalling IP addresses on the SBC sharing the same customer signalling IP address.
7.3 IP VPN
Connectivity to customers with IP VPN, makes use of the MPLS enabled access switches in Colt VoIP POPs. The Customer IP VPN is terminated on the access switch and presented on a dedicated VLAN interface towards the SBC. A Host Equipment Subnet is configured between the SBC and the access switch which hosts the SIP signalling and media addresses that the customer uses to connect to the VoIP POP from their VPN.
Figure 9. VoIP POP Configuration for IP-VPN
The Host Equipment Subnet is allocated a /27 IP Address range from the customers address space. This is typically an RFC1918 private address range that is routable from the customer a network. The subnet should4 be a /27 due to a design constraint on the Colt SBC5.
If multiple trunks are required on the same SBC e.g. for resiliency or multi-country support, up to 26 trunks can be setup with separate SIP signalling IP addresses on the SBC sharing the same customer signalling IP address.
For each additional POP, or if more than 26 signalling IP addresses are required on the same POP, a separate /27 subnet is required.
SBC Host Equipment Subnet IP Address Allocation e.g. 10.0.0.0/27
| First Useable IP | SBC NEXT HOP | .1 |
| Second Useable IP | RESERVED | .2 |
| Third Useable IP | RESERVED | .3 |
| Fourth Useable IP | SBC MEDIA / INTERFACE ADDRESS | .4 |
4 The one exception is where public IP addresses are used in which case there are no restrictions on the subnet mask
5 The design constraint requires that all (potentially) overlapping subnets (across different customers on the SBC) must use the same subnet mask. The subnet size has been standardised to /27 for this purpose.
- eBGP is standard configuration with IP-VPN. BFD with BGP is a bespoke solution.
| Last Non Broadcast IP N | 1st SBC SIP SIGNALLING ADDRESS | .30 |
| N-n | nth SBC SIP SIGNALLING ADDRESS (1 ≤ n ≤ 26) | .(31-n) |
7.4 Quality of Service
The Colt VoIP network supports Diffserv QoS marking for VoIP traffic. Voice payload is marked with DSCP 46 (EF) and signalling with DSCP 26 (AF31). This allows voice payload and signalling traffic priority over other kinds of traffic across the Colt IP backbone and customer access circuit. `1Q\GFFVFCDSThe DSCP markings correspond to the Premium and Business-1 Class of Service used with the existing COLT IP VPN product.
Table 4. DSCP Markings
| Class of Service | DSCP Marking (codepoint name) | IP VPN CoS Mapping |
|---|---|---|
| Premium (Voice) | 46 (EF) | Premium |
| Business-1 (Signalling) | 26 (AF31) | Business-1 |
Within the COLT IP network only markings from QoS enabled customers are trusted. All other All other traffic (Internet, Web, and Mail) is re-marked to DSCP 0 on ingress to the COLT IP network. Therefore, all Diffserv markings are trusted on ingress to the IMS PoP
For customers with Colt managed Internet Access, end-to-end QoS is provided across the Colt IP backbone using Diffserv markings applied by the Colt SBC and managed CPE. For Internet customers connected outside of the Colt IP backbone (via peerings) traffic (e.g. VoIP over public Internet) is re-marked to DSCP 0 on ingress to the COLT IP network and no QoS is provided
For IP-VPN customers QoS is applied differently depending on whether the IP-VPN is dedicated for voice or used for both voice and data. For a dedicated service, the bandwidth delivered to each VPN site is dedicated to VoIP and there is no QoS applied on the access link. QoS marking is still applied and is used to prioritise traffic across the Colt IP backbone. If the IP-VPN is shared for data and voice, the bandwidth delivered to each site must be dimensioned according to the overall voice and data traffic. Class of Service must be applied on IP VPN sites to ensure voice traffic is prioritised and the appropriate bandwidth assigned to each QoS class.
For Ethernet services, bandwidth is dedicated end-to-end and no QoS or CoS marking is required
8. Multi-Trunk & Resilient Configurations
8.1 Trunk Topologies
The options below describe how multiple SIP trunks can be connected to the same VoIP Access service e.g. for resiliency or multiple country trunks. For a given access network, the combination of the customer IP-PBX IP and SBC IP must be unique for each trunk.
Single POP Topologies
Multiple trunks on the same POP may be used to connect equipment or sites with separate DDIs, for multi-country support where a separate trunk is required for each country, or for expansion if the limit main numbers is exceeded on a trunk. It may also be used for load sharing or resilient configurations where hierarchical call admission control is required (only supported on single SBC).
If multiple trunks are configured on the same POP and share the same access network, by default, all trunks share the same SBC IP address. In this case a separate IP-PBX IP address is required for each trunk. This is the default configuration for multiple trunks on same POP.
Figure 10. Multiple Trunks – Single POP & Separate IP-PBX IP per Trunk
Alternatively, if a single IP-PBX IP is shared for all trunks, a separate SBC IP must be used for
each trunk as shown in the figure below. For this option This option is only supported for customers
with a IP-VPN or Ethernet connection and a maximum of 26 trunks can be configured per SBC
subnet.
Figure 11. Multiple Trunks – Single POP & Single IP-PBX IP
Multi POP Topologies
Multi-POP topologies are typically used for trunks in a resilient configuration since they protect
against the failure of a single POP or SBC. The examples below show how groups of resilient
trunks can be built across separate POPs. These examples assume separate SBC IP address are
setup on the same POP to handle multiple trunks to the same IP-PBX IP (see above).
Figure 12. Multiple Trunks – Dual POP, Single IP-PBX
Figure 13. Multiple Trunks – Dual POP, Separate IP-PBX
Figure 14. Multiple Trunks – Dual POP, Separate IP-PBX (Meshed)
8.2 Trunk Resiliency
Trunk resiliency secures communication against any failure between the customer IP-PBX and Colt SBC. Resilient trunks can also be used for load sharing across multiple SIP peers. One primary trunk can have maximum up to 26 secondary or resilient trunks.
Any of the trunk topologies described in the previous section can be used to provide resiliency or load sharing. For geographic redundancy, secondary trunks can be built on a separate SBC and POP.
8.2.1 Call Routing
Outgoing Call Distribution (Customer → Colt)
For outgoing calls, resilient trunks operate in active/active configuration – calls can be sent to any trunk. The customer decides the outgoing call distribution
Incoming Call Distribution (Colt → Customer)
For incoming calls, resilient trunks can operate as follows
- Active/Standby – In this method a sequential route selection is used. Calls will first be attempted on the primary or active trunk. In the event of primary trunk is unreachable (no response to SIP Invite or TCP timer expiry) or the number of calls exceeds the call limit set, calls will be attempted on the next available secondary(or standby) trunk.
- Load share – In this method round-robin route selection is used routing call which results in 50:50 load-share across available trunks. Therefore it is also called as load sharing. Whenever trunk exceeds call limit set or unreachable will be put off from selection till it restored to normal.
- Proportion- In this method calls can be routed with % of calls. E.g one trunk with 60% of calls and second one with 40%. Out of 10 calls 6 calls are routed through first trunk, whereas 4 calls with second trunk.
8.2.2 Trunk Out of Service and Recovery Methods
Resilient trunks make use of the following failure detection and recovery mechanism
Failure Detection
1st Call (Failure Detected): The Colt SBC attempts call on Trunk 1. When the SIP INVITE transaction or TCP connection timer expires the SBC attempts the call on Trunk 2. An additional PDD is incurred. The SBC blacklists the endpoint ip address belonging to Trunk 1
Subsequent Calls: SBC attempts call on Trunk 2, no additional PDD
The following timers are configured
- SIP-UDP: INVITE retry timer expires – 1.5s (1 retry)
- SIP-TCP: TCP Timeout – 5 Secs
Failure detection using SIP OPTIONs ping is also possible as bespoke configuration.
Recovery Mechanism
Two types of recovery methods are supported a) timer based b) SIP OPTION ping.
When a trunk endpoint is blacklisted a recovery timer is used to determine when the endpoint can be removed from the black list. The recovery timer is set to 180sec (3mins)
After the recovery timer expires calls are attempted again on Trunk 1.
An alternative recovery algorithm is available which uses a SIP OPTION Ping. When an endpoint is blacklisted, the SBC sends a SIP OPTION message every 3s. As soon as the endpoint responds with 200 OK, trunk will be put back into in-service.
8.3 Call Diversion features
Inbound Call Re-routing And Partial Number Replacement
Inbound call re-routing (ICR) and Partial Number Replacement (PNR) are call diversion features that allow calls to be automatically forwarded to a preselected number or number range in the event that a trunk is down due to connectivity failure.
These features are only invoked when all trunks (primary and secondary) are down due to non-reachability. The same trunk failure detection and recovery mechanisms apply.
Call Forwarding Unconditional
This feature is similar to Inbound call re-routing, when invoked calls will be diverted to a pre-selected number always, It does not wait for any response from remote end. Forwarding number is always preselected (Pre-configured) and mapped to a single or multiple DDI number(s).
Call Forwarding on Busy
This feature allows call to be diverted to a preselected number, when remote end response in busy. Forwarding number is always preselected (Pre-configured) and mapped to a single or multiple DDI number(s).
Call Forwarding on No answer
This feature allows call to be diverted to a preselected number, when remote end does not answer, till answer timer expires. Forwarding number is always preselected (Pre-configured) and mapped to a single or multiple DDI number(s).
Call Forwarding on No answer and Busy
This feature allows call to be diverted to a preselected number, when remote end does not answer, till answer timer expires or remote end response is busy. Forwarding number is always preselected (Pre-configured) and mapped to a single or multiple DDI number(s).
9. Global SIP Trunking
Global SIP is used to expand the reach of Colt voice services to countries where Colt does not operate a voice network. The solution is based on SIP Trunking service offered by Colt Partners in those countries
Note: The features supported on Partner SIP Trunking services may differ from those supported by Colt
The scenarios below describe the different ways that a customer solution may be implemented combining SIP trunks delivered on Colts own voice platform (in Colt countries) and SIP trunks delivered on the partner’s voice network.
Note that for scenarios 2a/2b below it is assumed that Colt has an MPLS NNI established with the partner.
Scenario 1a – Partner provides SIP trunk and customer connectivity
Figure 15. Scenario 1a – Partner provides SIP trunk and customer connectivity
In this scenario, the partner delivers both the SIP trunk(s) and connectivity to the customer site. The customer may have other SIP trunks delivered over the Colt network but there is no network-level integration between Colt and the Partner
Note: Customer site could also be indirectly connected to Colt network e.g. if the partner has bi-directional NNI agreement with Colt
Scenario 1b – Partner provides SIP trunk over Public Internet
Figure 16. Scenario 1b – Partner provides SIP trunk over Public Internet
In this scenario, the partner delivers the SIP trunk(s) to the customer site using the public Internet. Similar to scenario 1a, there is no network-level integration between Colt and the partner. The Internet access to the customer site may be provided by the partner, Colt, or another ISP. Also note that the customer site may not be in the Partner country e.g. the customer may aggregate SIP trunks from different onto a single IP-PBX connected to the Internet in a central location.
Scenario 2a – Partner provides SIP trunk to a Colt site over IP-VPN
Figure 17. Scenario 2a – Partner provides SIP trunk to a Colt site over IP-VPN
In this scenario, the partner SIP trunk is delivered to the customer site over a Colt IP-VPN. An MPLS NNI between the partner and Colt is used to extended the IP-VPN to the partners voice network. Any SIP trunks provided by Colt would share the same IP-VPN
The customer site(s) located in the partner country are indirectly connected to the Colt IP-VPN over the customer’s internal WAN network.
Scenario 2b – Partner provides SIP trunk to a Colt site over IP-VPN and provides customer connectivity
This scenario is similar to 2a except the partner also provides IP-VPN connectivity to the local
Figure 18. Scenario 2b – Partner provides SIP trunk to a Colt site over IP-VPN and provides customer connectivity
customer site(s). In this case the MPLS NNI between the partner and Colt, is used to extended the IP-VPN to both the partners voice network and customer sites attached to the partner network.
IP Addressing & VLANs for MPLS NNI based solutions (Scenario 2a, 2b)
IP-PBX / IP-PBX Range
- IP PBX Address and IP-PBX Range are part of the customer network and are used to establish the SIP Trunk
- Both IP PBX Address and IP-PBX Range must be routable from the partner SBC over the MPLS NNI
Partner SBC Subnet (SBC Host Equipment Subnet)
- Used to allocate IP addresses to terminate the customer SIP trunk in the partner network
- Usually an RFC1918 private range min /29 from the customers IP address space. Subnetting requirements may differ from those on Colt SBCs.
- Must be separate subnet from IP-PBX / IP-PBX Range
- SBC Signalling IP is allocated from this range
Partner MPLS NNI
- A per customer VLAN, /30 subnet, and eBGP peering configured on each peering link
- VLAN ids and subnets on the NNI are allocated by Colt (transit network)
10. Security
10.1 Encryption
For additional security, VoIP Access also supports SIP-TLS and SRTP to encrypt signalling and media between the customer equipment and Colt SBC. The following modes of encryption are supported:
- TLS on, SRTP off – only signalling encrypted
- TLS on, SRTP on – signalling and media encrypted
10.1.1 SIP-TLS
SIP-TLS is used to secure SIP signalling between the Colt SBC and the customer IP-PBX. Supported TLS versions are 1.0,1.1 and 1.2 and uses certificate-based authentication based on RSA public/private key pairs and X.509 digital certificates.
Separate TLS (and TCP sessions) are established for incoming and outgoing directions. By default, client authentication is enabled on the SBC, and when the SBC acts in server mode, it will send a certificate request to the client. TLS uses TCP port 5061.
The following TLS cipher suites are supported:
| Authentication Mechanism | Public/Private Key Pair | Confidentiality Cipher and Mode | Integrity Cipher |
|---|---|---|---|
| RSA-WITH-NULL-SHA The integrity cipher used for the TLS record protocol. | RSA | NULL | SHA-1 |
| RSA-WITH-3DES-EDE-CBC-SHA Authentication mechanism in the TLS Handshake protocol. | |||
| RSA WITH AES 128 CBC SHA (Default) Confidentiality cipher and mode for TLS Record protocol. | |||
| RSA WITH AES 128 CBC SHA-256 Confidentiality cipher and mode for TLS Record protocol with SLA-256 as the hash function. | |||
| RSA WITH AES 256-CBC-SHA Confidentiality cipher and mode for TLS Record protocol with AES-256 Encryption. | |||