Bell Canada SIP Trunking

Transcription

1 Bell Canada SIP Trunking Service Interface Specification 1.3

2 VERSION HISTORY Version Date Author Reason /02/2010 Jérôme Grenier First draft /02/2010 Jérôme Grenier Included peer review /03/2010 Jérôme Grenier Confirmations after specific lab tests and added some diagrams /04/2010 Jérôme Grenier More confirmations after lab tests and end-to-end timeout assessment /04/2010 Jérôme Grenier Adjustments following final peer review /04/2010 Jérôme Grenier Adjusted the Negotiation section to reflect the change in G.729 negotiation /02/2011 Jérôme Grenier Added a note in the DNS section to clarify that the public DNS must not be used to resolve the siptrunking.bell.ca SIP domain. Added a note in the DTMF section, pertaining to in-signal tones in situations of multiple IP-TDM conversions. Removed content from the section, pertaining to allowing unknown originating numbers /05/2012 Jérôme Grenier Changed the requirement on the To header for outgoing calls, in the Addressing section to cover for transcoded calls. Version 1.0 Page 2

5 THE INFORMATION CONTAINED HEREIN IS INTENDED FOR BELL SIP TRUNKING CUSTOMERS AND EQUIPMENT VENDORS ONLY. IT MAY NOT BE REPRODUCED OR DISCLOSED TO OTHERS, EXCEPT AS SPECIFICALLY PERMITTED IN WRITING BY BELL. THE RECIPIENT OF THIS MATERIAL, BY ITS RETENTION AND USE, AGREES TO PROTECT THE SAME AND THE INFORMATION CONTAINED THEREIN FROM LOSS, THEFT OR COMPROMISE. Version 1.0 Page 5

6 1. Introduction This document describes the technical specifications of Bell s SIP Trunking service interface. It covers voice (both signaling and media) as well as underlying data requirements. Note that only the specifications described herein are supported by Bell s SIP Trunking service and are subject to future changes. Here s a high-level view of the infrastructure involved: Bell s SIP Trunking service interface complies with most of the requirements and recommendations of the SIP Forum s SIPConnect 1.0 specification [1]. Please find the full compliance matrix in Version 1.0 Page 6

7 Appendix A SIPConnect 1.0 Compliance Matrix, at the end of this document. This document, along with the appendix, describes this compliance in detail, as well as other Bell-specific complements (ex.: dial plan, call forward, heartbeats, trunk group selection, capacity management, additional CODECs, etc). All throughout this document, references to SIPConnect 1.0 requirement numbers, as listed in Version 1.0 Page 7

8 Appendix A SIPConnect 1.0 Compliance Matrix, are made using the following syntax: {x}. 2. High-Level Customer Deployment Bell s SIP Trunking service is compatible with a multitude of customer voice network topologies, particularly as it only has to be aware of as many or as few SIP/RTP demarcation points in the customer network. For instance, if a topology-hiding Enterprise Session Border Controller is used by the customer as the sole (potentially geo-redundant) SIP Trunking demarcation point, then Bell s routing logic will be totally agnostic to the way calls are handled passed the customer s SBC, in its voice network. The following diagram depicts a typical IPVPN customer deployment where the demarcation points consist of geo-redundant pairs of Enterprise SBCs. It also shows two branch sites available through the customer s WAN, but not directly reachable from Bell s SIP Trunking infrastructure. Note that customers can use a SIP proxy server, as described in SIPConnect 1.0 {19}, but are not required to. In particular, customers can expose their voice network through an SBC, SIP proxy, IP- PBX directly and even expose their IP phones for direct media traffic exchange. Security and media traffic latency are the two main factors influencing the amount of exposure a customer will provide. Version 1.0 Page 8

9 3. Infrastructure 3.1 Core Network Bell s core infrastructure is composed of the following components: 3 pairs of Service Edge routers o Geo-redundant: Montreal, Toronto, Calgary o Active-Active model o Locally redundant 3 pairs of Session Border Controllers {98} o Geo-redundant: Montreal, Toronto, Calgary o Hot-standby model o Locally redundant Multiple TDM gateways o Geographically distributed Note that all appliances have internal hardware redundancy. Automatic failover occurs at all levels (internal, local and site). In some exceptional cases, active/answered calls might not fail over successfully. 3.2 Access Network Bell s SIP Trunking service is supported over either Bell s IPVPN or Ethernet Interworking data services. In either case, QoS must be properly applied, bandwidth properly provisioned, routing properly configured and the customer s VPN(s) must be extended to Bell s core infrastructure for voice traffic to flow in both directions. Each customer VPN interconnecting with Bell s SIP Trunking infrastructure is isolated from other customer s VPNs. The following diagram depicts an IPVPN customer (Customer A) with a VRF that is extending to two SIP Trunking SBC sites (Toronto and Calgary) and that is accessible from this customer s Site 1 and Site 2. The diagram also shows an Ethernet Interworking customer (Customer C) that extends two VLANs from his main site in order to access two SIP Trunking SBC sites. Version 1.0 Page 9

10 Note that G.711 calls are estimated to require approximately 100 kbps each (in each direction), while G.729 [2] calls are estimated to require approximately 40 kbps each (in each direction), on these data services. 4. SIP Service Extensions A customer s WAN terminates to Bell s infrastructure through one or more SIP Service Extensions, corresponding to Bell s Session Border Controller sites (Montreal, Toronto and Calgary). Bell uses the customer s IP addressing scheme to establish L3 routing. No public IP addresses are required {35, 36}. With IPVPN, once a customer s WAN has connectivity to a Bell SBC site, through a SIP Service Extension, all of the customer s VoIP equipment on the WAN (common VRF) can access the SBC site, to place and receive calls. Likewise, if this VRF is extended to another SIP Service Extension, then all of the customer s VoIP equipment has access to both SIP Service Extensions. Bell requires two /30 subnets and one /28 subnet from the customer, per SIP Service Extension. The next L3 hop towards Bell s SBC is the customer-facing interface on the CE router. With Ethernet Interworking, customers access different SBC sites through separate VLANs. A router on the customer s premises is required. Routing to the customer s IP subnets is done either statically or dynamically. Bell recommends using dynamic routing. Bell requires one /30 subnet Version 1.0 Page 10

11 and one /28 subnet from the customer, per SIP Service Extension. The next L3 hop towards Bell s SBC is the customer-facing interface on the SE router. Each customer s SIP Service Extension will be provisioned with a virtual IP address assigned to a Bell SBC site. This is the IP address that CPE/PBXs must send their SIP traffic to, on the standard 5060 port. Bell uses this approach instead of exposing a DNS server {9, 6, 20, 22, 23, 24, 97}. The same IP address will also be used as Bell s media endpoint. For the media traffic, ports will be allocated dynamically. Establishing multiple SIP Service Extensions allows for geo-redundancy for both inbound (towards the customer) and outbound (towards Bell) calls. The following diagram depicts SBC site failover on an outbound call. Because all voice traffic (signaling and media) passes through Bell s SBCs, the selection of SBC for both inbound and outbound calls influences the latency of the media traffic. Given the impact of network latency on media traffic, optimizing the SBC selection is quite important. For inbound traffic, routing is determined upfront at design time. For outbound traffic, routing is determined at call time and depends on the advertized origin of the media traffic. The following diagram depicts an outbound call where, although the signaling traffic from the IP phone goes through the main IP-PBX in Toronto, the Calgary SBC site is selected as media traffic will flow more efficiently between Bell s SBC and the IP phone in Calgary. Version 1.0 Page 11

12 Note that the above design applies only when media endpoints are directly reachable from Bell s SBCs, from an RTP traffic perspective. 5. Quality of Service SIP Trunking uses QoS to ensure priority of voice traffic over other network traffic, using specific values {66}. Note that for either access type the QoS design philosophy is to have end points do the marking whenever possible. 5.1 IP VPN For IPVPN, layer 3 QoS based on DSCP is used. The following DSCP settings are honored on the IP/MPLS network for Voice Class of Service {116} : Signaling: CS5 (DSCP value of 40) Media: EF (DSCP value of 46) Incoming Traffic Bell marks each packet with the above DSCP values. The demarcation point into the customer s network is the LAN interface on the Bell-provided CE router. The customer is responsible for propagating or modifying QoS values from that point forward. Outgoing Traffic The customer is responsible for marking the packets towards Bell s infrastructure, using the above values. If the customer is not able to set these values, then a request can be made to have those values set on the CE router. Version 1.0 Page 12

13 5.2 Ethernet For Ethernet, layer 2 QoS based on P-bit is used. Both signaling and media use P-bit value 5. Incoming Traffic Bell marks each frame with the above P-bit value. The customer is responsible for propagating or modifying QoS values from its network premise equipment forward. 6. Transport Outgoing Traffic The customer is responsible for marking the frames towards Bell s infrastructure, using the above value. UDP is used for SIP, RTP and RTCP [3]. Given the supported SIP headers and message body types, as well as CODECs and RTP packetization time, datagrams typically fit within the standard 1500 bytes MTU, so no IP fragmentation is necessary. However, fragmented packets are correctly reassembled by Bell s infrastructure. Standard ports are used for all traffic types, but the customer is allowed to specify a non-standard SIP port. For Bell media endpoints, RTP/RTCP [3] ports are determined dynamically in the range. 7. Signaling Bell s SIP Trunking service supports RFC-3261 as the call signaling protocol {7}.Bell s core infrastructure uses SBCs at the edge {25}, acting as SIP back-to-back user agents (B2BUA), to handle all incoming and outgoing traffic. The following elements are explicitly unsupported by Bell: TCP/SCTP SIPS/TLS Registrations {4, 29, 30, 31, 32, 33, 34, 37, 38, 42, 99, 101, 124, 125} {21, 27, 28, 40, 123} Bell s infrastructure uses RFC-3261 mechanisms to learn a customer s SIP capabilities and advertise its own {1, 2}. Bell supports provisional response acknowledgements, as specified in RFC {8}. Bell also supports the UPDATE method, as specified in RFC-3311 {11}. Their use in a particular dialog will depend on the CPE/PBX advertising their support {87, 88}. Bell supports the following methods: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, and UPDATE. Specifically, Bell does not support the following methods: REFER [4], SUBSCRIBE and NOTIFY [5]. Bell only supports the SDP MIME type: application/sdp. Only sip: and tel: URI schemes are supported {60}. Please refer to the Addressing section for more details on supported URI formats. Note that compact headers are supported, however Bell will never use them when issuing requests or responses. Since Bell s demarcation points (SBCs) act as B2BUAs, RFC-3581 {15} is not applicable. Customers are therefore not required to support it {93}. Generally, Bell applies the optimizations described in RFC-3725 {16}. For instance, SDP offers are sent on original INVITE requests. Bell recommends that customers apply the same kinds of optimizations {94}. Version 1.0 Page 13

14 In order to complete the call path correctly, while optimising loop detection, the Max-Forwards header must be set to at least DNS For inbound call routing, DNS is used to determine which IP address(es) and port(s) should be used to reach the customer s demarcation SIP endpoint {26}. The resolution is based on the PBX/CPE FQDN (ex.: pbx1.sipt.customer.com) assigned to the trunk group selected to deliver the incoming call. Note that customers do not have to be publicly authoritative on the domains, as this is a closed client-server system running over private networks. However, domains have to be unique among Bell s SIP Trunking customers. Bell hosts the DNS entries internally {17}. Each FQDN can map to a list of at most three (3) IP addresses/ports, which will be tried in sequence. SRV resource records {6, 18} are used internally. NAPTR records {96} are not used/supported. Note that for a given FQDN, the same IP address cannot appear twice, even if with different ports. Please refer to the Checking CPE/PBX Status and Inbound Failover sections for more details on how the DNS entries are used. Note that, on outbound calls, customers must not use the public DNS in order to resolve the siptrunking.bell.ca SIP domain. Bell may use this domain as a placeholder for a future web presence. Please refer to the SIP Service Extensions section for more details on how to determine the next SIP hop for outbound calls. 9. Addressing 9.1 Calls Terminating at the Customer Bell will send call requests using E.164 addressing {3} prefixed with a + symbol {62, 64, 65} : Request-URI: From: John Smith To: John Doe Anonymous calls will use the following syntax {63} : From: Anonymous For customers who didn t subscribe to the Calling ID Name and Number service feature, all calls will use the following origination syntax {63} : From: <sip:siptrunking.bell.ca> Customers who subscribe to Bell s toll-free service will receive the local conversion number instead of the 800 number that was actually dialed by the caller. 9.2 Calls Originating from Customer CPE/PBXs must use the following syntax when placing calls on Bell s SIP Trunking service. Originating number addressing format {43, 46, 47, 57, 58} : From: Version 1.0 Page 14

15 Note that the ;user=phone header parameter is required. Numbers provided can represent an end user, system, or anything the customer wants {105}. Caller numbers must be known to the SIP Trunking service. Only numbers assigned by Bell and dedicated to its SIP Trunking service will be provisioned. Calls with unknown numbers or invalid formats will be rejected with a 404 Not Found response. As described in the Privacy section, CPE/PBXs can also use P-Asserted-Identity and P-Preferred-Identity headers in addition to the From header to identify the originating number and display name, as they take precedence over the From header {46, 47}. Regular calls can keep using only the From header to identify the caller {52, 56, 102, 103}. Destination number addressing format {59, 60, 61, 114} : Request-URI: To: or Request-URI: tel:[allowed-dialstring] To: tel:[allowed-dialstring] Note that all tel URI parameters described in RFC-2806 [6] and RFC-3966 [7] are ignored. Bell s SIP Trunking service will accept call requests with destinations according to the North American Numbering Plan. Here are the accepted dial strings {45} : E.164 number with a leading + 10 digits and 1+10 digits for local and long distance call 0+10D call (operator assistant North-America LD call) 01+International NDC (from 8 to 35 digits, operator assistant international call) 011+International call 101+xxxx+NDC call (from 13 to 40 digits, casual dial call) 211, 311, 511, 411, 611, 711, xxx xxxx call Toll Free call 800, 888, 877, and 976 call 0 (operator call) 00 (LD provider operator call) Calls targeting location-dependent services, like N-1-1 (except 9-1-1), 1-xxx and 310-xxxx will be routed on the PSTN according to the originating number (as presented to the PSTN). Hence, if the CPE/PBX modifies the originating number for any reason, the end user might end up interacting with a non-local service. If the service receives a request for a destination number that is not in service or has a malformed number, a proper announcement treatment will be applied. Note that the service will accept 10 digit and 11 digit call requests for local and long distance calls. If a 1 prefix is present, it will be ignored. No announcement will be generated based on the presence or absence of this prefix. Depending on the purchased rate centers and method of trunk group selection, long distance charges may apply. Version 1.0 Page 15

16 The above specifications only describe the requirements for direct interconnection with Bell s SIP Trunking service. Customers are free to implement their own internal dial plan, as experienced by their user community. 10. Authentication The CPE/PBX must authenticate at each outbound call (INVITE request), through a digest challenge {38, 39, 126}. The username and password required for any given call depends on the trunk group selected to place the call {41}. Note that to avoid unnecessary challenges, the CPE/PBX can include its authentication credentials using the current nonce value in each request sent to Bell {100}. A given nonce value can only be reused within its originating dialog. By default, all of a customer s trunk groups will share the same username-password pair. Customers will be able to request that specific sets of trunk groups share a distinct usernamepassword pair. A process will also be in place to change the username-password pair on a given trunk group, for cases where there s a concern of a password possibly having been compromised. 11. Media 11.1 Negotiation Media session negotiations use RFC-3264 / RFC-2327 {10, 67}. The SDP offer sent by the CPE/PBX must always be present on the INVITE request for outbound calls (early offer model). The SDP offer sent by Bell will always be present on the INVITE request for inbound calls. Session negotiation must be performed through either re-invites or UPDATEs (RFC- 3311) {81}. Bell could send either, but will only send UPDATEs if the CPE/PBX advertizes its support through the Allow header. The CPE/PBX must include an attribute specifying the media endpoint s desired directionality (i.e. a=inactive/sendonly/recvonly/sendrecv) as described in RFC-3264 for all media streams listed in the SDP offer or answer {68}. Bell will also honor this rule {68}. Bell accepts SDP offers using c= to indicate an inactive stream {69}. Bell will either use the a=inactive or c= syntax, and sometimes both in the same SDP construct. Symmetric RTP {71} can be used, but Bell will only enforce it in cases where it is required as a NAT traversal technique, because of address/port translation issues (please refer to the Network Address T section for more details). Otherwise, contact information (IP address and port) provided by the CPE/PBX through SDP offers and answers will be honored by Bell. If customers plan to use G.729 or G.729a [2] for some or all of their calls, they must request Bell to enable transcoding on their SIP Trunking service Payload RTP is used to transmit all media traffic, as described in RFC-3550 {70}. Supported CODECs for voice samples are: G.711 u-law {72} G.729 [2] G.729a [2] Version 1.0 Page 16

17 For all CODECs, a packetization time of 20ms {72, 117} is supported. G.711 streams support the conveyance of DTMF {74, 76}, fax and TTY signals (refer to sections DTMF, Fax and TTY respectively for more details). RFC-2833 is also supported as an RTP payload {75, 76} (refer to section DTMF for more details). For the types of streams they wish to handle through SIP Trunking, customers are required to support the above RTP payloads and CODECs, except for G.729/G.729a. Bell s SIP Trunking service does not support G.711 A-law {72, 73} Early Media CPE/PBXs are required to support early media, in particular since some calls imply ringing generated by the far end: 1. upon receipt of SDP answers in any 183 Session Progress, 200 OK, or 202 Accepted message the CPE/PBX must immediately disable any locally generated call progress tones and cut-through the early media to the end-user as described in RFC-3261 {84} 2. after sending an SDP offer, the CPE/PBX must be prepared to receive media on all offered recvonly or sendrecv transport protocol / transport port / CODEC (media stream) combinations {85} 3. upon receipt of media on any such media stream, the CPE/PBX must immediately disable any locally generated call progress tones and cut-through the early media to the end-user as described in RFC-3261 {86} 11.4 Progress Tones CPE/PBXs are required to locally generate call progress tones in response to the following subset of standard SIP response codes. Selection of the particular tone is left to the customer or equipment manufacturer s discretion {83} : 180 Ringing 400 Bad Request 403 Forbidden 404 Not Found 408 Request Timeout 480 Temporarily Unavailable 482 Loop Detected 483 Too Many Hops 486 Busy Here 500 Server Internal Error 503 Service Unavailable 504 Server Time-out 600 Busy Everywhere 604 Does Not Exist Anywhere CPE/PBXs are required to locally generate call progress tones in response to the other SIP response codes where some form of tone is applicable {122}. Alternately, CPE/PBXs could apply error handling logic such as failover routing, for some of the above SIP response codes. Version 1.0 Page 17

18 11.5 DTMF Bell supports both audio tones-based DTMF {74} and RFC-2833 {75}. Customers are also required to support both {5, 76}. Support for RFC-2833 only covers the payload type described in section 3 (RTP Payload Format for Named Telephone Events) of the RFC and only the DTMF events (0-9, *, #, A- D, flash) described in section As a general rule, RFC-2833 is preferred over audio tones-based DTMF because of its resilience to temporary network impairments. However, when multiple IP-TDM conversions are likely on certain call paths, audio tones-based DTMF is recommended Echo Cancellation Customers are required to apply echo cancellation as described in ITU-T G.168, if applicable, on their premises {77}. Note however that Bell will provide G.168-compliant echo cancellation for calls to and from the PSTN {77}. Acoustic echo cancellation is also recommended Silence Suppression / Comfort Noise Generation 11.8 Fax Bell recommends avoiding such media alteration techniques {118} as they tend to degrade audio quality. Bell recognizes fax signals in G.711 calls, as described in ITU-T G : in-band 2100 Hz tones (+/- 15 Hz) in conjunction with phase reversals at 450 ms intervals (+/- 25 ms) {78}. Upon detection of this tone: 1. echo cancellation is disabled and remains disabled for the duration of the call or until one of the following events occurs {79} : a. no single-frequency sinusoid is present as defined in Section 7 of G.168 b. the end of the call is detected c. the end of data transmission is detected by the lack of fax tones on the channel 2. disable the high pass filter {80} 3. disable voice activity detection (VAD) and comfort noise generation (CNG) {80} 4. switch from an adaptive/dynamic jitter buffer to a fixed-length jitter buffer {80} a. Bell uses a 50ms buffer in this case {119} Customers who wish to handle fax calls must follow the above specifications {78, 79, 80}. Note that Bell s SIP Trunking service doesn t support T.38 {82, 120, 121} Modem Bell s SIP Trunking service does not support the reliable conveyance of modem signals {78}. Version 1.0 Page 18

19 11.10 TTY Bell s SIP Trunking service supports the reliable conveyance of TTY/TDD signals over G.711. Moreover, the service is supported (where available). 12. Network Address Translation Bell s SBCs translate customers private IP addresses/ports found in SIP signaling, SDP offers/answers as well as at the IP/UDP level (including RTP/RTCP [3] traffic), into Bell internal IP addresses/ports, and vice-versa. As a result, the customer s private L3/L4 information isn t available to other Bell IP services customers. Note that elements of RTCP [3] packets are not translated and therefore should not contain private information. Bell s SIP Trunking service interface typically expects proper NATing to be done by CPE/PBXs, especially when using modern topology hiding devices such as Enterprise SBCs. In this regard, customer-initiated NAT traversal solutions like STUN or ICE are not required {36, 92}. However, some NAT-traversal facilities are provided. For SIP signaling sent by the CPE/PBX, Bell s SBCs will perform hosted NAT traversal when the topmost Via header s sent-by value of a received request matches its Contact header URI host address and both are different from the source IP address of the received packet. In this case, Bell s SBCs will respond to the actual source IP address and port of the packet. Note that for a given media session, once Bell s SBC receives the first RTP packet, only RTP packets from the same source IP address and port will be allowed going forward. If a media session is changed as part of a call (re-negotiation), this restriction would be re-evaluated. Bell s SBCs send RTP traffic using the same source IP address/port as the IP address/port they advertize as their media endpoints in the SDP (symmetric RTP) {71}. However, Bell doesn t enforce this rule on behalf of the CPE/PBX (as a potential NAT traversal technique), by ignoring the CPE/PBX-provided SDP contact information and sending RTP traffic towards the observed media source. Such mechanism could be put in place in special cases where NAT presents particular concerns, but it is not Bell s recommendation. 13. Trunk Groups Bell s SIP Trunking service uses the concept of trunk groups to model logical pipes that all calls, inbound or outbound, take to travel between the SIP Trunking infrastructure and the customer s voice network. Trunk groups can be unidirectional or bidirectional. They each have specific inbound, outbound and total capacity thresholds. Some treatments can be applied when these thresholds are exceeded. Please refer to the Capacity Management section for more details. Version 1.0 Page 19

20 For inbound calls, specific phone numbers or ranges are assigned to a given trunk group. Only numbers of the same rate center can be assigned to a given trunk group. This implies that when one of these numbers is dialed, the call routes through its assigned trunk group, towards a given CPE/PBX FQDN {44, 127}, through a specific sequence of SBC sites (depending on the customer s SIP Service Extensions). All of these mappings are done at service provisioning time. For outbound calls, the CPE/PBX can determine which (outbound) trunk group is to be used for any given call. The selected trunk group should have enough outbound and total capacity to handle the call. As each trunk group is associated with a particular rate center, calls routed through a particular trunk group will appear local if the destination number is also within that rate center (local calling area). If not, long distance charges will apply. Note that in either case, the originating number as provided by the CPE/PBX is not altered by the trunk group selection process. If cost optimization is the goal, selection of the outbound trunk group should be based on the destination number. Outbound trunk groups can be selected through the following mechanisms (in order of precedence): TGRP Bell s SIP Trunking service supports RFC-4904 [8]. Trunk group labels are determined at service provisioning time. Example: Version 1.0 Page 20

21 Contact: OTG Bell supports the otg header parameter in the From, P-Asserted-Identity or Diversion header. Trunk group labels are determined at service provisioning time. Examples: From: P-Asserted-Identity: Diversion: Implicit If the outbound trunk group is not explicitly selected through one of the above methods, the trunk group that will implicitly be selected will be the one with which the originating number is associated. The originating number is specified either through the From, P-Asserted-Identity or P-Preferred-Identity header (please refer to the Addressing and Privacy sections for more details). 14. Call Routing 14.1 Inbound Routing Inbound calls are routed towards the CPE/PBX according to the logic specified in the Trunk Groups, DNS, Inbound Failover and Exceeding Inbound Capacity sections. Here s an example INVITE request for a call terminating at the customer: INVITE SIP/2.0 Via: SIP/2.0/UDP [sbc-ip-address]:5060;received=[sbc-ipaddress];branch=z9hg4bk From: "[caller-display-name]" To: "[callee-provisioned-display-name]" CSeq: 101 INVITE Contact: <sip:[sbc-ip-address]:5060;transport=udp> Supported: 100rel Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,PRACK,UPDATE Accept: application/sdp Max-Forwards: 19 Call-ID: [call-id] Content-Type: application/sdp Content-Length: [SDP offer] Please refer to the Addressing section for more details on addressing-related headers. Depending on the CPE/PBX support for RFC-3262, standard RFC-3261 or RFC-3262 Version 1.0 Page 21

Service Guide Learn More: Call us at 877.634.2728. www.megapath.com What is MegaPath SIP Trunking? SIP Trunking enables your business to reduce costs and simplify IT management by combining voice and Internet

SIP Trunking Manual 05.15 Technical Support Web Site: http://ws1.necii.com (registration is required) This manual has been developed by NEC Unified Solutions, Inc. It is intended for the use of its customers

How To Guide SIP Trunking Configuration Using the SIP Trunk Page For the Ingate SIParators and Firewalls using software release 4.9.2 or later. Updated to show features available from release 4.10.x May

Voice over IP Fundamentals Duration: 5 Days Course Code: GK3277 Overview: The aim of this course is for delegates to gain essential data networking and Voice over IP (VoIP) knowledge in a single, week-long

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

MITEL SIP CoE Technical Configuration Notes Configure MCD 6.X for use with babytel SIP trunks SIP CoE 13-4940-00266 NOTICE The information contained in this document is believed to be accurate in all respects

VoIP Trunking with Session Border Controllers By Chris Mackall Submitted to the Faculty of the Information Technology Program in Partial Fulfillment of the Requirements for the Degree of Bachelor of Science

MITEL SIP CoE Technical Configuration Notes Configure MCD 6.X for use with VoiceHost SIP trunks SIP CoE 13-4940-00284 NOTICE The information contained in this document is believed to be accurate in all

SIP Messages 100 Trying This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database

This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into

SIP Trunking and Voice over IP Agenda What is SIP Trunking? SIP Signaling How is Voice encoded and transported? What are the Voice over IP Impairments? How is Voice Quality measured? VoIP Technology Confidential

Vega 100G and Vega 200G Gamma Config Guide This document aims to go through the steps necessary to configure the Vega SBC to be used with a Gamma SIP Trunk. When a SIP trunk is provisioned by Gamma a list

October 14 Time Warner ITSP Setup Guide Author: Zultys Technical Support This configuration guide was created to assist knowledgeable vendors with configuring the Zultys MX Phone System with Time Warner

nexvortex Setup Guide CISCO UC500 March 2012 Introduction This document is intended only for nexvortex customers and resellers as an aid to setting up the Cisco PBX software to connect to the nexvortex

Network Connection Considerations for Microsoft Response Point 1.0 Service Pack 2 Updated: February 2009 Microsoft Response Point is a small-business phone solution that is designed to be easy to use and

SJ Labs, Inc. 2005 All rights reserved SJphone is a registered trademark. No part of this document may be copied, altered, or transferred to, any other media without written, explicit consent from SJ Labs

61200796L1-29.4E July 2011 Configuration Guide Configuring for the NetVanta 7000 Series This configuration guide describes the configuration and implementation of Session Initiation Protocol (SIP) trunking

Technical Manual 3CX Phone System for Windows This technical manual is intended for those who wish to troubleshoot issues encountered with implementing 3CX Phone System. It is not intended to replace the

MITEL SIP CoE Technical Configuration Notes Configure the Mitel 3300 MCD 4.1 for use with Broadworks Softswitch SIP CoE 08-4940-00035 NOTICE The information contained in this document is believed to be

OfficeMaster Gate (Virtual) Enterprise Session Border Controller for Microsoft Lync Server Quick Start Guide October 2013 Copyright and Legal Notice. All rights reserved. No part of this document may be

SV9100 SIP Trunking Service Configuration Guide for Time Warner Cable Business Class NDA-31660 Issue 1.0 NEC Corporation of America reserves the right to change the specifications, functions, or features

The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

Optimum Business SIP Trunk Set-up Guide For use with IP PBX only. SIPSetup 07.13 FOR USE WITH IP PBX ONLY Important: If your PBX is configured to use a PRI connection, do not use this guide. If you need

1 SIP Carriers 1.1.1 Warnings Check the SIP 3 rd Party SIP Carrier Matrix for certification status, and supported features. More info about the SIP 3 rd Party SIP Carrier Matrix can be found in the SIP

SIP Trunking Service Configuration Guide for Skype NDA-31154 Issue 1.0 NEC Corporation of America reserves the right to change the specifications, functions, or features at any time without notice. NEC

MITEL SIP CoE Technical Configuration Notes Configure MCD 4.1 for use with SKYPE SIP Trunking SIP CoE 10-4940-00120 NOTICE The information contained in this document is believed to be accurate in all respects