Technical User Guide. Baseband IP Voice handover interface specification

Transcription

1 Technical User Guide Baseband IP Voice handover interface specification Document version July 2013

2 Copyright Copyright 2011 Chorus New Zealand Ltd All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without the prior written permission of Chorus New Zealand Limited. This document is the property of Chorus New Zealand Limited and may not be disclosed to a third party, other than to any wholly owned subsidiary of Chorus New Zealand Limited, or copied without consent. Document Version 2.0 Confidential Page 2

3 Table of Contents INTRODUCTION PURPOSE CONTRACTUAL REFERENCE USE OF THE NAME CHORUS... ERROR! BOOKMARK NOT DEFINED LIMITATIONS SOLUTION BACKGROUND OVERVIEW / EXECUTIVE SUMMARY SCOPE HANDOVER INTERFACE PHYSICAL / LOGICAL INTERFACE VOICE HANDOVER POINT TOPOLOGIES MEDIA CHARACTERISTICS SIP SIGNALLING INTERFACE APPENDIX A: DEFINITIONS, ACRONYMS AND ABBREVIATIONS APPENDIX B: SIGNAL FLOWS B1 OVERVIEW OF SIGNALLING FLOWS B2 SIP SIGNALLING FLOWS B3 SIMPLE ENDPOINT SIGNALLING FLOWS APPENDIX C ETHERNET FRAME STRUCTURE APPENDIX D - BBIP VOICE DIAL PLAN Document Version 2.0 Confidential Page 3

4 Introduction 1.1. Purpose The purpose of this document is to describe the IP Voice Handover interface for the Baseband IP voice service. This is the interface between the Chorus network and the service providers network, as necessary for interworking of Baseband IP voice services Contractual reference This document is intended for use by Chorus and Alcatel-Lucent staff to describe the Handover interface to service providers. It will provide input to a Chorus-produced technical user guide that would be distributed to service providers Limitations This document does not, in any way, vary the terms of the main contract between Chorus and the service provider. If there is any conflict between the relevant contract and statements made in this document, the terms of the relevant contract shall prevail. Document Version 2.0 Confidential Page 4

5 2. Solution background 2.1. Overview The Baseband IP voice service allows service providers to use our ISAM-V access nodes and copper lines to deliver voice services to their customers. The ISAM-V is derived from the ISAM broadband access node by the addition of 48-port Voice cards. (up to five domain names per HOP) Premise wiring ISAM Chorus Regional Ethernet Network ISAM Map RSP.domain.name to/ from Session Agent/ Proxy Address Session Agent/ Proxy address Retail Service Provider ETP Analogue ports ISAM Access REN SBC HA EASs VLAN Session Agent/SIP proxy RSP network ISAM ISAM SBC VIP address (Plus Primary Secondary addresses) 802.1ad or Q-in-Q tags Figure 1 depicts the context for the end-to-end design (for a non-routed HOP). The ISAM equipment can be either located in street cabinets or in buildings. PhoneNumber@RSP.domain.name (up to five domain names per HOP) Premise wiring ISAM Chorus Regional Ethernet Network ISAM Map RSP.domain.name to/ from Session Agent/ Proxy Address Session Agent/ Proxy address Retail Service Provider ETP Analogue ports ISAM Access REN SBC HA EASs VLAN Session Agent/SIP proxy RSP network ISAM ISAM SBC VIP address (Plus Primary Secondary addresses) 802.1ad or Q-in-Q tags Figure 1: E2E Design Context Diagram (non-routed HOP) The Handover interface is the connection point for telephony service between the Chorus and a service provider s network, as shown by the BBIP-V cloud in figure 1. A separate specification describes the analogue electrical interface (Baseband IP voice analogue voice specification). Document Version 2.0 Confidential Page 5

6 2.2. Scope General This document describes the handover interface between the Chorus Baseband IP - Voice service and a connected service provider. It includes details of the SIP messaging required for successful interoperability across this interface. The ISAM-V (version ) has been tested and verified to operate with a Broadsoft VoIP Soft-Switch (AS version Rel_17.sp2_1.88), using Broadsoft non-intelligent signalling mode. This Handover specification is based in part upon the results of this testing Telephony features Baseband IP voice service supports the following telephony features: 2-wire analogue lines G.711 A-law Codec with 10ms packetisation preferred for voice and voice band data (fax/modem) calls SIP simple mode configuration NZ PSTN tones & cadences Fax and low-speed modem support Hook-switch flash support (for 3-way calling, call waiting, call transfer, call hold, etc.) CLIP / CLIR Message waiting indicator ( stuttered dial tone and visual MWI) DTMF inband or RFC 2833 Fixed destination call immediate (hotline) Other features such as voic diversion and call forwarding are dependent on the service provider soft-switch and do not rely on the Baseband IP SIP User Agent (UA) (other than for basic call handling capability). Answer line reversal is not supported by BBIP. Document Version 2.0 Confidential Page 6

7 3. Handover interface 3.1. Physical / Logical Interface General The Baseband IP Voice hand-over can be non-routed or service provider-routed as is shown in the following summary diagrams. Figure 2: Non-routed hand-over Figure 3: Routed hand-over Handover Point The Handover Point to the service provider is a port on a Regional Ethernet Network (REN) Ethernet Aggregation Switch (EAS). This may be the same port that is used by the service provider for Shared handovers (HSNS/EUBA) or EUBA handovers. The service provider will need at least one HOP per REN for BBIP. When a REN has Multiple SBCs (for capacity), the HOP is shared by all SBCs in that REN. Each SBC can have a separate HOP VLAN, or a single VLAN for multiple SBCs within the REN can be used with an appropriately sized subnet. Note that, looking toward the service provider s network, the service provider s next-hop (Gateway or Session Agent) must have a unique public IP address for each VLAN. Document Version 2.0 Confidential Page 7

8 A service provider can have multiple HOPs within a REN but each HOP requires a unique group of up to 5 SIP host domain names. Each SBC within a REN will be configured with the same host domain name to HOP mapping. Each domain name to HOP mapping is REN specific. Different mappings can be configured in each REN and a domain name can be used in multiple RENs. Domain name and HOP constraints within a REN are: A domain name maps to only one HOP Up to five domain names per service provider can map to a single HOP Voice Handover Point attributes The voice HOP has the following attributes and constraints: Shared network Subnet address and size is allocated by the service provider (minimum of /28), recognising that Chorus will increase the number of SBCs as the number of BBIP connections increases over time, and Service providersmay increase the number of HOPs within each REN. Chorus side Subnet shall be a IPV4 public routable address range Subnets are statically configured. DHCP is not supported Can be routed (service provider provided) or non-routed Signalling and media can be on separate VLANs within the same HOP (single preferred) DNS resolution is not supported One SIP URI host is required, up to 5 supported, per HOP SIP over UDP only If a REN contains multiple SBCs then within that REN: o o o o All SBCs have the same Domain name to HOP mappings Each SBC may have a separate HOP VLAN using a different next-hop address per VLAN All SBCs use the same Session Agent address for a given VLAN Multiple SBC can share a HOP VLAN The Interface is provided by a High-Availability pair of Acme Packet SBCs (SBC HA). Each HOP has a separate, and isolated, SBC virtual interface. Three IP addresses are required for each BBIP HOP VLAN. Two for SBCs High Availability (HA) operation (physical Ethernet interfaces) and a virtual one for BBIP traffic. Only the Virtual IP address and its associated virtual MAC address are used by the service provider. If the service provider is using separate VLAN for signalling (SIP traffic) and media (RTP traffic), a second set of (3) SBC addresses is required for each SBC HA in that VLAN. Access Control List(s) (ACL) block packets sent from addresses outside of the hand-over subnet or the Session Agent/Media Proxy. For clarity in a routed handover packets from all devices beyond the router except the single Session Agent/Media Proxy (destination point) are blocked. Document Version 2.0 Confidential Page 8

9 service provider Side The service supports a single source/destination IP address (service provider Session Agent) per HOP VLAN. The Session Agent is common to all: o o BBIP-V SBCs using the same VLAN on a HOP Domains served by that HOP. Each service provider Session Agent has a (unique) service provider allocated public routable IPv4 address for each VLAN VLANs tagging at the handover point can be IEEE 802.1ad single S-tagged, or double S- and C-tagged, or Cisco compliant Q-in-Q double tagged with agreed values. The S-VLAN tag numbering will conform to the existing Chorus Wholesale business rules. The C-VLAN tag numbering has a default value of 10. Please refer to Appendix C for an explanation of the VLAN options available at the Handover interface Voice Handover Traffic Control To prevent the traffic of any service provider exceeding agreed limits or impacting other service providers, Session based limiting for the Session Agent is used within the Chorus SBCs: Traffic within a REN will be limited to an agreed number of sessions. A session is a call leg either from the service provider to the ISAM connected enduser, or from the ISAM connected end-user to the service provider. Typically a session equates to a call, but note that when one ISAM connected end-user calls another ISAM connected end-user of the same service provider, this call will use two sessions (one to the service provider plus one from the service provider). If a REN contains more than one SBC, an agreed session limit will be applied to each SBC in the REN. The session limit is set symmetrically, ie the limit can be reached as all outbound traffic, all inbound traffic, or as the sum of a combination of inbound and outbound traffic. Registrations are not counted as sessions. Registrations are limited separately to 100/sec to control registration storms. Document Version 2.0 Confidential Page 9

10 3.2. Voice Handover Point Topologies This section outlines the different HOP topologies that may be used by the service provider Single Subnet per HOC The diagram below shows the key points of a non-routed HOC using a single subnet across all SBC s in the REN. One Subnet for all SBC for a HOC Chorus REN RSP Session Agent Address SBC address x 3 VIP Primary Secondary SBC address x 3 VIP Primary Secondary SBC HA SBC HA 802.1ad or Q-in-Q tagged HOP EASs VLAN1/Subnet1 proxy Multiple Subnets per HOC The diagram below shows the key points of a non-routed HOC using separate subnets for each SBC in the REN. Each subnet requires a unique public SIP proxy address on the service provider s SIP proxy device. Document Version 2.0 Confidential Page 10

11 Chorus REN One Subnet per SBC for a HOC RSP Session Agent Address VLAN1 SBC address x 3 VIP Primary Secondary SBC address x 3 VIP Primary Secondary SBC HA SBC HA 802.1ad or Q-in-Q tagged HOP EASs VLAN1/Subnet1 VLAN2/Subnet2 proxy(s) Session Agent Address VLAN Routed Connections The diagram below shows the key points of using a routed network with a single Gateway. Each VLAN requires a unique public address on the service provider s Gateway as well as a unique public address for the proxy. One Subnet per SBC for a HOC via a Gateway Chorus REN RSP VLAN1 Session Agent Address Each HOC SBC address x 3 VIP Primary Secondary Each HOC SBC address x 3 VIP Primary Secondary SBC HA SBC HA 802.1ad or Q-in-Q tagged HOP EASs 802.1ad or q-in-q tagged HOP VLAN1/Subnet1 VLAN2/Subnet2 Gateway Address for HOC1 Gateway(s) Gateway Address for HOC2 proxy(s) VLAN2 Session Agent Address Document Version 2.0 Confidential Page 11

12 Multiple HOPs in a REN If the service provider wishes to have multiple HOPs within a REN, then a topology described above can be repeated for each HOP. The diagram below shows a high level view for a routed network with two HOPs. Each HOC SBC address x 3 VIP Primary Secondary Multiple HOPs within a REN (Routed Network example) Chorus REN SBC HA Each HOC SBC address x 3 VIP Primary Secondary EAS (Site 1) EAS (Site 2) HOP1 VLAN1 VLAN2 RSP Gateway Address for HOC1 Gateway(s) Gateway Address for HOC2 HOC1 Session Agent Address proxy(s) SBC HA HOP2 HOC2 Session Agent Address Document Version 2.0 Confidential Page 12

13 3.3. Media Characteristics CODEC Voice samples will be transported using the Real-time Transport Protocol (RTP), as described in RFC 3550 Service providersusing the BBIP service shall support ITU-T G.711 A-law codec with a preferred packetisation rate of 10ms, and may optionally support ITU-T G.711 µ-law codec. For calls originated by the BBIP end user the INVITE SDP will include in order of preference (pay-load value in brackets): o A-law (8) o µ-law (0) o Telephone events (101) Media Capability Negotiation (SDP Characteristics) The service provider shall utilize the Session Description Protocol (SDP) as described in RFC 2327, in conjunction with the offer/answer model described in RFC 3264, to exchange session information with BBIP. The SDP offers/answers from the service provider shall include the following: The IP address ( c= field) of the service provider s signalling entity or media endpoint (depending on the connection model within the service provider s network). G.711 A-law as the codec, and ptime (packetisation rate) set to a preferred value of 10 (for Voice). If it is supported, RFC 2833 DTMF relay as the DTMF mode (The Chorus network only supports events 0-15, 32-36). The Baseband IP Voice service supports G.711 A-law (preferred) and G.711 µ- law. Example SDP content in BBIP-V offer: v=0 o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv Jitter Buffer BBIP-V provides an Adaptive jitter buffer of 20 60ms When a voice band data fax or modem call is detected, it changes from adaptive to fixed jitter buffer of 100ms Echo Cancellation Document Version 2.0 Confidential Page 13

14 ITU-T G.168 compliant near-end echo cancellation is provided in the Baseband IP Voice service. It is expected that Service providersshall also provide G.168 echo cancellers in their networks to eliminate any hybrid imbalance and handset conduction. The echo cancellers shall normally be enabled, except when disabled by the stimuli outlined in reference [3] VAD and CNG Voice Activity Detection (VAD) and Comfort Noise Generation (CNG) are disabled on the ISAM. However receipt of CNG media packets from the remote device is supported RTCP The service supports RTCP with SR and RR records being produced Transport of DTMF Tones Any device that exchanges RTP traffic with the Baseband IP Voice service shall support at least one of the following two methods: Handling of DTMF tones using the RTP telephone-event format as described in RFC 2833 (preferred method). When RFC 2833 is used, DTMF tones are removed from media stream. Transport of DTMF tones in-band (if not supported by the far end). RFC 2833 is enabled on the ISAM, but if not supported by the far end in-band DTMF will be used Fax / Modem Support The Baseband IP Voice service supports only G.711 transparent pass-through mode for fax (ie T.38 fax relay is not supported). Following detection of VBD stimuli a (RE)INVITE will be sent to initiate a change to VBD mode. For further details of Fax/Modem support and Voice Band Data (VBD) stimuli see example in Appendix B2(12). Document Version 2.0 Confidential Page 14

15 3.4. SIP Signalling Interface Standards Support The protocols used at the handover interface shall conform to the specifications listed in Table 1. Standard RFC 791 RFC 2327 RFC 2833 Description Internet Protocol (IPv4) Note: IPv6 support is not currently supported. SDP: Session Description Protocol RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 RFC 3261 RFC 3262 RFC 3264 RFC 3311 RFC 3323 RFC 3325 RFC 3550 RFC 3842 RFC 4028 RFC 5009 SIP INFO Method The SIP INFO method defined by RFC 2976 with the Broadsoft proprietary content-headers is supported for Simple end point operation (flash hook and Call Waiting Tone play and stop) SIP: Session Initiation Protocol The transport method supported for SIP signalling is UDP (RFC 768). The use of TCP (RFC 793) is not supported. Reliability of Provisional Responses in the Session Initiation Protocol (SIP) An Offer/Answer Model with Session Description Protocol (SDP) The Session Initiation Protocol (SIP) UPDATE Method A Privacy Mechanism for the Session Initiation Protocol (SIP) Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks RTP: A Transport Protocol for Real-Time Applications A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) Session Timers in the Session Initiation Protocol (SIP) Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media Table 1: Standards Support SIP Methods Support The minimum set of SIP methods that require service provider support include those shown in Table 2. Method REGISTER INVITE ACK Use The SIP REGISTER method is used by the BBIP-V to establish and maintain registration with the service provider s softswitch. The SIP INVITE method is used to invite another party to participate in a call session. The INVITE method can also be used within an existing dialog to change SDP characteristics once a call session has been established (in which case the INVITE is commonly called a REINVITE). The SIP ACK method confirms that a client has received a final response (2xx, 3xx, 4xx, 5xx or 6xx response) to an INVITE request. The service provider shall be able to send and receive SIP ACK requests. If the INVITE (or Document Version 2.0 Confidential Page 15

16 REINVITE) request sent to the service provider did not contain a SDP offer, then the SDP offer shall be included in the 200 OK (INVITE), and the SDP answer shall be included in the ACK. The service provider shall be able to receive SDP answers within the ACK requests. BYE The SIP BYE method terminates a call. The service provider shall be able to send and receive a SIP BYE request. The service provider shall only send a BYE if an INVITE dialog is confirmed (ie a 200 OK INVITE and ACK have been successfully exchanged between the service provider and the ISAM-V). If the dialog has not reached the confirmed state, a SIP CANCEL shall be used instead. CANCEL NOTIFY PRACK OPTIONS INFO The SIP CANCEL method terminates a pending INVITE before a 200 OK (INVITE) has been received. The service provider shall be able to send and receive a CANCEL request. The service provider shall only send (or receive) a CANCEL if an INVITE dialog is not confirmed (that is, a 200 OK INVITE and ACK have not been successfully exchanged between the service provider and the ISAM-V). If the dialog is confirmed, a SIP BYE shall be used instead. The SIP NOTIFY method is only required if a service provider intends to support the Message Waiting Indication supplementary service. The PRACK (Provisional Response Acknowledgement) method provides provisional responses to certain SIP messages. The SIP OPTIONS method allows a UA to query another UA or a proxy server as to its capabilities. The SIP method INFO is supported. Table 2: SIP Methods SIP Signalling General The service provider shall utilize the Session Initiation Protocol (SIP) as the call control protocol, as described in RFC 3261 and related RFCs (refer section 3.3). The Baseband IP Voice service will perform SIP registration with the service provider s network by means of SIP REGISTER messages. Service providersmay optionally use Authentication Implementation-Specific Items (1) SIP OPTIONS Pings. (a) Each SBC that the service provider is connected to in the Baseband IP Voice service will send a SIP OPTIONS ping message to the service provider once every 60 seconds. The service provider network must respond to this message or the service provider handover point will be set to an out-of-service state. It is strongly recommended that the response be a 200:OK message. If a 200:OK cannot be used and an alternate response will be sent, the specific response must be specified by the service provider as it will need custom configuration within the Baseband IP voice network. (b) If the service provider network does fail to respond correctly to an OPTIONS Ping and is set to an out-of-service state, the customer lines of the service provider will experience the following: 1) While the line s registration period is still active, lines will hear dial tone but any call attempts will received a 403:Forbidden response to the INVITE and the caller will hear Disconnect Tone (DSCT). Document Version 2.0 Confidential Page 16

17 2) When the line attempts to re-register it will receive a 503:Service unavailable response to the REGISTER. The line will attempt to reregister once every 600 seconds until the service provider is back in service and the registration succeeds. 3) Once the line has made a failed attempt to register and received a 503 message, if the user goes off hook there will be no dial tone. The user will hear silence and there will be no response to attempts to make calls until registration succeeds. (c) The service provider network may optionally send OPTIONS ping messages to the network. If it does, the Baseband IP voice network will respond with a 200:OK message. Note this response indicates that the Baseband IP Voice SBC is functioning, but gives no information about the state of any access equipment or lines. (2) Originating Calls. (a) It is possible for the service provider network to send 180 Ringing, followed by a final INVITE response other than 200 OK (ie a 4xx, 5xx, or 6xx response). In this case, the Baseband IP Voice service will apply ringback tone when 180 Ringing is received, and then stop it and provide an appropriate call progress tone (eg busy tone if 486 is received) based on the specific received response. (b) The Baseband IP Voice service will provide audible tones to analogue lines upon receipt of SIP response codes from Service providersfor unsuccessful calls, as shown in Table 3. For details of Supervisory Tones, see reference [3]: SIP Response 4xx/5xx/6xx 486 Busy Here 600 Busy Everywhere 404 Not Found 604 Does Not Exist Anywhere 410 Gone All others Tone Busy Tone (BT) Number Unobtainable Tone (NUT) (Note) Disconnect Tone (DSCT) Note: Even though some service providers Call Servers may provide their own announcements for invalid numbers, this is intended to cover the case where a Call Server may not provide such announcements and instead returns SIP Responses 404, 604 or 410 to the ISAM-V. Table 3: SIP Response Mapping to Tones (3) Terminating Calls (a) If the called Baseband IP voice service customer line has been assigned the Calling Line Identity Presentation (CLIP) supplementary service, the service provider network shall populate the From header with the calling party number, either in National Number format (with or without the leading 0, eg or ) for NZ origin, or in International format for foreign origin. The calling party number format to be implemented for NZ origin calls shall be determined by the service provider (in order to best interact with the CPE options outlined in reference [2], ie PTC ). For the avoidance of doubt, the Baseband IP Voice service will pass the service provider s calling party number format (as received in the SIP INVITE From header) transparently to the CPE. (b) Where the Ringing cadence required differs from the default DA1 cadence, the cadence will be signalled by using the Alert-info header in the INVITE message. When needed, this will be one of the following three values: Document Version 2.0 Confidential Page 17

18 Alert-Info: < DA2 cadence Alert-Info: < DA3 cadence Alert-Info: < DA4 cadence (where DA1 to DA4 are as shown in reference [3].) (c) The default DA1 cadence will be played where: There is no Alert-Info header When Alert-Info: < is sent When Alert-Info header contains a dr-value not 2, 3, or 4 (4) SIP INFO Support. The ISAM-V will operate in a Broadsoft non-intelligent signalling mode with a Hook-switch flash procedure being used to signal for supplementary services. The following SIP INFO messages are supported by the ISAM-V. These messages shall be viewed in the context of an existing ISAM-V to service provider dialogue. (a) Play Tone INFO Message The play tone CallWaitingTone1 message is generated when the service provider wants to instruct the ISAM-V to Play Call-Waiting Tone1 to the user within an existing dialogue. (b) Stop Tone INFO Message The stop CallWaitingTone1 message is generated when the service provider wants to instruct the ISAM-V to Stop the Call-Waiting Tone being played to the user within an existing dialogue. (c) Flash Hook INFO message The event flashhook message is generated by the ISAM-V to instruct the service provider that the User pressed flash hook within an existing dialogue. (5) Timers The following SIP Timers are implemented and/or recommended for the BBIP-V service: (a) Registration timer. This is set to 3600 seconds for the ISAM-V. It is the interval of refreshing the Registration, and the actual value used is determined by the 200 OK expires value as set by the service provider s SIP server. It is recommended that values less than 600 seconds (10 minutes) not be used. (b) Register Retry Timer. This is set to 300 seconds. It is the interval for the ISAM-V to wait before re-trying Registration, if the previous Registration attempt fails. (c) Session timer. It is recommended that values less than 1800 seconds (30 minutes) not be used. (d) SIP Options SBC sends a SIP Options message every 60 seconds to determine Session Agent (SA) availability Typical Call Flows For typical call flows of Registration, Originating and Terminating Calls, etc, refer to Appendix B.1. For typical Simple endpoint call flows for Call Waiting, Call Transfer, Call Hold and 3-Way Calling supplementary services, refer to Appendix B.2. Document Version 2.0 Confidential Page 18

19 Appendix A: Definitions, Acronyms and Abbreviations Term Definition AMS APC AS ATA BBIP-V CCIL CFH CLIP CLIR E2E E-NNI FAIMS FDS FSS-P FTTX G.711a GigE GPON HOP ICMS IP ISAM ITU-T LAG ms MWI NT NSP NGA OLT ONT OO&T POTS PSTN RBI REN RFC service provider SA Access Management System Access Provisioning Centre Application Server Analogue Telephone Adapter Baseband IP - Voice Chorus Co-Innovation Laboratory Crown Fibre Holdings Calling Line Identity Presentation Calling Line Identity Restriction End to End Ethernet Network to Network Interface Facility and Inventory Management System First Data Switch Fulfil Support System - Provisioning Fibre To The X (Home or Premises) Codec to ITU-T G.711 Recommendation, with A-law variant Gigabit Ethernet Gigabit Passive Optical Network Handover Point Integrated Customer Management System Internet Protocol Integrated Services Access Multiplexor International Telecommunications Union - Telecommunications Link Aggregation Group milli-second Message Waiting Indicator Network Termination Network Service Provider Next Generation Access Optical Line Terminator Optical Network Terminator Online Order & Tracking Plain Old Telephone Service Public Switched Telephone Network Rural Broadband Initiative Regional Ethernet Network Request For Comments Service provider Session Agent Document Version 2.0 Confidential Page 19

20 Term Definition SBC SIP TCF TNZ TUG UA UFB VBD VoIP Session Border Controller Session Initiation Protocol Telecommunications Carriers Forum Telecom New Zealand Technical User Guide User Agent Ultra Fast Broadband Voice Band Data Voice over Internet Protocol Document Version 2.0 Confidential Page 20

21 Appendix B: Signal Flows B1 Overview of Signalling Flows The following signalling flows identify the relationship between the SIP/SDP messaging and the customer provisioned fields, the SBC, and the service provider session agent. SIP variables are identified in accordance with the following table: Sip variable Derived from Comment sbc-vip sbc-rtp-port session agent session agent-rtpport uri-user HOC SBC VIP specified by service provider Port number supplied by the SBC that it will receive RTP on HOC Session Agent IP address specified by service provider Port number supplied by the Session Agent that it will receive RTP on User part of provisioned uri uri-host Host part of provisioned uri Domain name for service provider display name username For BBIP-V originated calls the SIP Display Name field will contain <directory-number> if populated or <uriuser> if not populated. Sample messages assume <display-name> is populated. For BBIP- V terminated calls, the service provider chooses the content of Display Name field. Provisioned user-name password Provisioned md5-password Only visible in encrypted form in SIP direct uri Provisioned direct-uri direct-uri includes SIP heading, ie. sip:<number to call>@hostname contact uri Register Contact header Request URI of service provider originated dialogues (e.g. terminating Invites) must contain this May include cookies between uri-user called number calling number calling display name digits entered by the end user when making a call the number or name of the caller as forwarded by the service provider the display name received from the service provider for the caller May be another BBIP number or a caller on another network including the PSTN Examples given are: (1) Registration (2) Registration with authentication (state authentication is optional) (3) BBIP-V originated call Document Version 2.0 Confidential Page 21

22 (4) BBIP-V originated call with authentication (note - authentication is optional) (5) BBIP-V originated call via service provider with 183 and PRACK (6) BBIP-V incoming call (call terminating on BBIP-V line) (7) CLIR call to BBIP-V line (call terminating on BBIP-V line) (8) Hot line (showing use of <direct-uri> parameter) (9) Distinctive ringing (10) Message Waiting NOTIFY message (11) SIP Option Ping (BBIP-V SBC to service provider heartbeat) (12) BBIP-V VBD originated call Document Version 2.0 Confidential Page 22

23 B2 SIP Signalling Flows (1) Registration Figure 4: Registration Signalling Flow REGISTER sip:<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkr8s96b105ovh2hk2i4e1.1 From: <display name> To: <display name> <sip: Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 1 REGISTER Max-Forwards: 29 Contact: <display name> <sip:<contact uri >:5060;transport=udp> Expires: 3600 Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-message- Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE Supported: path User-Agent: Alcatel-Lucent ISAM Content-Length: 0 Route: <sip:<session agent>:5060;lr> SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkso2b8k107gm0dh0pr311.1 From: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag=sd2e4v701-b72e12n26589e89-d15 To: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag= Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 2 REGISTER Expires: 3600 Contact: <sip:<uri-user>@<uri-host>;5060>;expires=3600 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Content-Length: 0 Document Version 2.0 Confidential Page 23

24 (2) Registration with authentication (note - use of authentication is optional) Figure 5: Registration with Authentication Signalling Flow REGISTER sip:<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkr8s96b105ovh2hk2i4e1.1 From: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag=sd2e4v701-b72e12n26589e89-192c To: <display name> <sip: <uri-user>@<uri-host>;user=phone> Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 1 REGISTER Max-Forwards: 29 Contact: <display name> <sip:<contact uri >:5060;transport=udp> Expires: 3600 Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+x Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE Supported: path User-Agent: Alcatel-Lucent ISAM Content-Length: 0 Route: <sip:<session agent>:5060;lr> SIP/ Unauthorized Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkr8s96b105ovh2hk2i4e1.1 From: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag=sd2e4v701-b72e12n26589e89-192c To: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag= Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 1 REGISTER WWW-Authenticate: Digest realm= <uri-host>,nonce= fbd73abe748d95612e56ffc d ,stale=false,algorithm=md 5 Document Version 2.0 Confidential Page 24

25 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Content-Length: 0 REGISTER sip:<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkso2b8k107gm0dh0pr311.1 From: : <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag=sd2e4v701-b72e12n26589e89-d15 To: : <display name> <sip:<uri-user>@<uri-host>;user=phone> Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 2 REGISTER Max-Forwards: 29 Contact: <display name> <sip:< contact uri >:5060;transport=udp> Expires: 3600 Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+x Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE Authorization: Digest username= <username>,realm= <uri-host>,nonce= fbd73abe748d95612e56ffc d ,u ri= sip: a.b.c.d,response= b7c348fb1e879b1437a3a285dd75ed28,algorithm=md5,opaque= Supported: path User-Agent: Alcatel-Lucent ISAM Content-Length: 0 Route: <sip:<session agent>:5060;lr> SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkso2b8k107gm0dh0pr311.1 From: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag=sd2e4v701-b72e12n26589e89-d15 To: <display name> <sip:<uri-user>@<uri-host>;user=phone>;tag= Call-ID: SD2e4v701-3d d11766d53dd16aabab663c-06a3050 CSeq: 2 REGISTER Expires: 3600 Contact: <sip:<uri-user>@<uri-host>;5060>;expires=3600 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Content-Length: 0 Document Version 2.0 Confidential Page 25

26 (3) BBIP-V Originating Call Figure 6: BBIP-V Originated Call Signalling Flow INVITE sip:<called SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkdl2v19106g60oh8bv3d0.1 From: <display name> To: <called number> <sip:<called Call-ID: SDlvuga e8e0b dec131c4-a084g20 CSeq: 1 INVITE Max-Forwards: 29 Contact: <sip:<contact uri>:5060;transport=udp> Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+xml,application/x-session-info Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Date: Thu, 17 May :17:27 GMT Supported: 100rel,timer User-Agent: Alcatel-Lucent ISAM Allow-Events: refer P-Preferred-Identity: sip:<uri-user>@<uri-host> Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 240 P-Early-Media: supported Route: <sip:<called number>@<session agent>:5060;lr> v=0 o=icf 1 0 IN IP4 <sbc-vip> Document Version 2.0 Confidential Page 26

27 s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv SIP/ Trying Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkdl2v19106g60oh8bv3d0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@ufb.labnetwork> Call-ID:SDlvuga e8e0b dec131c4-a084g20 CSeq:1 INVITE Content-Length:0 SIP/ Ringing Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkdl2v19106g60oh8bv3d0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID:SDlvuga e8e0b dec131c4-a084g20 CSeq:1 INVITE Supported:timer Contact:<sip:<session agent>:5060> P-Asserted-Identity: <display name> <sip:<uri-user>@<session agent>;user=phone> Privacy:none Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Content-Length:0 SIP/ OK Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkdl2v19106g60oh8bv3d0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID:SDlvuga e8e0b dec131c4-a084g20 CSeq:1 INVITE Require:timer Session-Expires:480;refresher=uas Supported:timer Contact:<sip:<session agent>:5060> P-Asserted-Identity: <display name> <sip:<uri-user>@<session agent>;user=phone> Privacy:none Document Version 2.0 Confidential Page 27

28 Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp Content-Type:application/sdp Content-Length:219 v=0 o=broadworks IN IP4 <session agent> s=c=in IP4 <session agent> t=0 0 m=audio <session agent-rtp-port>rtp/avp a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv ACK sip:<session agent>:5060 SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkelf36t1088s1hh0bl7h1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID: SDlvuga e8e0b dec131c4-a084g20 CSeq: 1 ACK Max-Forwards: 29 Contact: <display name> <sip:<contact uri>:5060;transport=udp> Content-Length: 0 BYE sip:<session agent>:5060 SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkelf36t1088s1hh0bl7h1cd From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID: SDlvuga e8e0b dec131c4-a084g20 CSeq: 2 BYE Max-Forwards: 29 Content-Length: 0 SIP/ OK Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkelf36t1088s1hh0bl7h1cd From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdlvuga fc To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID:SDlvuga e8e0b dec131c4-a084g20 CSeq:2 BYE Content-Length:0 Document Version 2.0 Confidential Page 28

29 (4) BBIP-V originated call with authentication (note - authentication is optional) Figure 7: BBIP-V Originated Call with Authentication Signalling Flow Only the initial Invite-Challenge-Invite example messages are shown below INVITE sip:<called number>@<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkag5fsa00fo3gnh02g180.1 Max-Forwards: 69 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdqh7pd01-as0b97e2a3 To: <called number> <sip:<called number>@<uri-host> Contact: <sip:<contact uri>:5060;transport=udp> Call-ID: SDqh7pd01-236dbadc4ec418df4ec8b65ef7a30ddb-a CSeq: 102 INVITE User-Agent: Alcatel-Lucent ISAM Date: Thu, 14 Jun :58:40 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 260 Route: <sip:<called number>@<session agent>:5060;lr> v=0 Document Version 2.0 Confidential Page 29

30 o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv SIP/ Unauthorized Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkag5fsa00fo3gnh02g180.1;received=a.b.c.d;rport=5060 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdqh7pd01-as0b97e2a3 To: <called number> <sip:<called number>@<uri-host>;tag=as4c Call-ID: SDqh7pd01-236dbadc4ec418df4ec8b65ef7a30ddb-a CSeq: 102 INVITE Server: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer WWW-Authenticate: Digest algorithm=md5, realm= asterisk, nonce= 5ac3de08 Content-Length: 0 INVITE sip:<called number>@<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkb0cguj00fo800hkur3s0.1 Max-Forwards: 69 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdqh7pd01-as0b97e2a3 To: <sip: <called number>@<uri-host>> Contact: <sip:contact uri>:5060;transport=udp> Call-ID: SDqh7pd01-236dbadc4ec418df4ec8b65ef7a30ddb-a CSeq: 103 INVITE User-Agent: Alcatel-Lucent ISAM Authorization: Digest username= , realm= asterisk, algorithm=md5, uri= sip: @ , nonce= 5ac3de08, response= 44606f4821ef82c69e4a0f5086b4eb85 Date: Thu, 14 Jun :58:40 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 260 Route: <sip:<called number>@<session agent>:5060;lr> v=0 o=icf 1 0 IN IP4 <sbc-vip> Document Version 2.0 Confidential Page 30

31 s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv (5) BBIP-V originated call via service provider with 183 and PRACK Figure 8: BBIP-V Originated Call via service provider with 183 & PRACK Signalling Flow INVITE sip:<called number>@<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkihef3d103ohgthc7t0f0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>> Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 1 INVITE Max-Forwards: 29 Document Version 2.0 Confidential Page 31

32 Contact: <sip:<contact uri>:5060;transport=udp> Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+xml,application/x-session-info Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Date: Tue, 22 May :10:07 GMT Supported: 100rel,timer User-Agent: Alcatel-Lucent ISAM Allow-Events: refer P-Preferred-Identity: Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 240 P-Early-Media: supported Route: <sip:<called agent>:5060;lr> v=0 o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv SIP/ Trying Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkihef3d103ohgthc7t0f0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>> Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 1 INVITE SIP/ Session Progress Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkihef3d103ohgthc7t0f0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>>;tag=sdicec099-4efa lucentpcsf Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 1 INVITE Contact: <sip:<called number>@<session agent>:5060;transport=udp> Document Version 2.0 Confidential Page 32

33 Require: 100rel Content-Type: application/sdp Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE,P UBLISH Date: Mon, 21 May :10:09 GMT Organization: Alcatel RSeq: 1 Content-Length: 191 Server: Lucent-HPSS/3.0.3 v=0 o=lucentfs IN IP4 <session agent> s=c=in IP4 <session agent> t=0 0 m=audio <session agent-rtp-port> RTP/AVP a=rtpmap:101 telephone-event/8000 a=sendrecv a=ptime:10 PRACK sip:<called number>@<session agent>:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkj1lglm10fgdgohkr23m0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>>;tag=sdicec099-4efa lucentpcsf Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 2 PRACK Max-Forwards: 29 Date: Tue, 22 May :10:09 GMT RAck: 1 1 INVITE Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkj1lglm10fgdgohkr23m0.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>>;tag=sdicec099-4efa lucentpcsf Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 2 PRACK Contact: <sip:<called number>@<session agent>:5060;transport=udp> Server: Lucent-HPSS/3.0.3 Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkihef3d103ohgthc7t0f0.1 Document Version 2.0 Confidential Page 33

34 From: <display name> To: <called number> <sip:<called Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 1 INVITE Contact: <sip:<called number>@<session agent>:5060;transport=udp> Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE,PUBLISH Supported: timer Session-Expires: 1800;refresher=uas Server: Lucent-HPSS/3.0.3 Content-Length: 0 Require: timer ACK sip:<called number>@<session agent>:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkjhrj nh4bu7u0.1 From: <display name> <sip:<uri-user>@<uri-host>;tag=sdicec d-0669 To: <called number> <sip:<called number>@<uri-host>;tag=sdicec099-4efa lucentpcsf Call-ID: SDicec001-6cd da2609d9d79ae374e94-a084g20 CSeq: 1 ACK Max-Forwards: 29 Contact: <display name> <sip:<contact uri>:5060;transport=udp> Content-Length: 0 Document Version 2.0 Confidential Page 34

35 (6) BBIP-V incoming call (call terminating on BBIP-V line) Figure 9: BBIP-V Incoming Call Signalling Flow INVITE sip:<contact uri >:5060;transport=udp SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>;user=phone>;tag= To: <display name> CSeq: INVITE Contact:<sip:<session agent>:5060> Supported:100rel,timer Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Min-SE:60 Session-Expires:480;refresher=uac Max-Forwards:10 Content-Type:application/sdp Content-Length:245 v=0 o=broadworks IN IP4 <session agent> s=c=in IP4 <session agent> t=0 0 Document Version 2.0 Confidential Page 35

36 m=audio <session agent-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv SIP/ Trying Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling number>@<session agent>;user=phone>;tag= To: <display name> <sip:<uri-user>@<uri-host>:5060> Call-ID: BW @a.b.c.d CSeq: INVITE SIP/ Ringing Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling number>@<session agent>;user=phone>;tag= To: <display name><sip:<uri-user>@<uri-host>:5060>;tag=sdqkcje fdi0 Call-ID: BW @a.b.c.d CSeq: INVITE Contact: <display name> <sip:<contact uri>@<sbc-vip>:5060;transport=udp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Supported: 100rel Allow-Events: refer Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling number>@<session agent>;user=phone>;tag= To: <display name> <sip:<uri-user>@<uri-host>:5060>;tag=sdqkcje fdi0 Call-ID: BW @a.b.c.d CSeq: INVITE Contact: <display name> <sip:<contact uri>@<sbc-vip>:5060;transport=udp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Require: timer Supported: timer Allow-Events: refer Session-Expires: 480;refresher=uac Content-Type: application/sdp Content-Length: 214 v=0 o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP Document Version 2.0 Confidential Page 36

37 a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv ACK sip:<contact uri >:5060;transport=udp SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv a From: <calling display name> <sip:<calling agent>;user=phone>;tag= To: <display name> CSeq: ACK Contact:<sip:<session agent>:5060> Max-Forwards:10 Content-Length:0 BYE sip:<contact uri >:5060;transport=udp SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>;user=phone>;tag= To: <display name> CSeq: BYE Max-Forwards:10 Content-Length:0 SIP/ OK Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>;user=phone>;tag= To: <display name> Call-ID: CSeq: BYE Content-Length: 0 Document Version 2.0 Confidential Page 37

38 (7) CLIR call to BBIP-V line Figure 10: CLIR Call to BBIP-V line Signalling Flow INVITE sip:<contact uri >5060;rci=1.1 SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: Anonymous <sip: <session agent>>;tag= To: <display name> CSeq: INVITE Contact:<sip:<session agent>:5060> Supported:100rel,timer Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Min-SE:60 Session-Expires:480;refresher=uac Max-Forwards:10 Content-Type:application/sdp Content-Length:262 v=0 o=broadworks IN IP4 <session agent> s=c=in IP4 <session agent> t=0 0 Document Version 2.0 Confidential Page 38

39 m=audio <session agent-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv a=ptime:10 Document Version 2.0 Confidential Page 39

40 (8) Hot line Call flow is identical to normal BBIP-V originated call. INVITE only is shown below to show how the provisioned directuri parameter is used to originate the hotline call. Note the provisioned direct-uri parameter includes the SIP heading. For example if the destination to call is and the service provider Host URI is rsp.co.nz, the direct-uri parameter would be: The constructed Request URI line would be: INVITE SIP/2.0 INVITE <direct uri> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bk02fc5ad0c e2973bca16494c74ee6b1bf Route: <sip: <session agent>:5060;lr> From: <display name> <sip: To: Call-ID: CSeq: 1 INVITE Max-Forwards: 29 Contact: <display name> <sip:<contact uri >:5060;transport=udp> Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+xml,application/x-session-info Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE Supported: 100rel User-Agent: Alcatel-Lucent ISAM Allow-Events: refer Content-Type: application/sdp Content-Length: 274 P-Early-Media: supported Route: <sip:<uri-user>@<session agent>:5060;lr> v=0 o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv Document Version 2.0 Confidential Page 40

41 (9) Distinctive ringing Call flow is identical to normal BBIP-V terminated call. INVITE only is shown below to show the Alert-Info header specifying the ring tone as dr2 in this example. INVITE sip:<contact uri >:5060 SIP/2.0 Via:SIP/2.0/UDP <sbc-vip>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>;user=phone>;tag= To: <display name> CSeq: INVITE Contact:<sip:<session agent>:5060> Alert-Info:< Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Supported:timer Min-SE:60 Session-Expires:900;refresher=uac Max-Forwards:10 Content-Type:application/sdp Content-Length:215 v=0 o=broadworks IN IP4 <session agent> s=c=in IP4 <session agent> t=0 0 m=audio <session agent-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:97 telephone-event/8000 a=ptime:10 a=sendrecv Document Version 2.0 Confidential Page 41

42 (10) Message Waiting NOTIFY message The following shows the Message Waiting NOTIFY message and 200OK response. Note that the optional urgent message counts can be present but urgent message presentation to the end user is not supported. NOTIFY sip: <contact uri >:5060;rci= SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From:<sip:<session agent>>;tag= To:<sip: CSeq: NOTIFY Contact:<sip: <session agent>:5060> Event:message-summary Subscription-State:terminated Max-Forwards:10 Content-Type:application/simple-message-summary Content-Length:43 Messages-Waiting: <yes or no> voice-message: <unheard message count>/<heard message count> SIP/ OK Via: SIP/2.0/UDP <session agent>;received=a.b.c.d;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <sip: <session agent>>;tag= To: <sip: Call-ID: CSeq: NOTIFY Contact: sip: <sbc-vip>:5060 Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE Content-Length: 0 Server: Alcatel-Lucent-HPSS/3.0.3 Document Version 2.0 Confidential Page 42

43 (11) SIP Options Ping (BBIP-V SBC to service provider heartbeat) BBIP-V SBC RSP SA T=60 seconds OPTIONS 200 OK OPTIONS 200 OK NOTE: If a 200 OK or alternate agreed response is not received, the RSP SA will be marked as out-of-service. Figure 11: SIP Options Ping Signalling Flow OPTIONS sip: <session agent>:5060 SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkqie9tt308g30oh4gq270 Call-ID: 6c43b32e608b0c3467b df @a.b.c.d To: sip:ping@<session agent> From: <sip:ping@<sbc-vip>>;tag=543a637c8d42c70ed16cc21ad85baf1e Max-Forwards: 70 CSeq: 2 OPTIONS SIP/ OK Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkqie9tt308g30oh4gq270 From:<sip:ping@<sbc-vip>>;tag=543a637c8d42c70ed16cc21ad85baf1e To:<sip:ping@<session agent>>;tag= Call-ID:6c43b32e608b0c3467b df @a.b.c.d CSeq:2 OPTIONS Allow-Events:call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-callcenter-status Content-Length:0 Document Version 2.0 Confidential Page 43

44 (12) BBIP-V Originating VBD Call A BBIP-V SBC RSP SA B Dialling B INVITE (SDP) Trying 183 Session Progress (SDP) PRACK 200 OK (for PRACK) (Ring-back) Tone Ring 200 OK (for INVITE) Stop (Ring-back) Tone ACK Off-hook Speech path A B established (RTP at 10 ms Packetisation rate) Path A B after VBD stimulus detected (RTP at 20 ms Packetisation rate) On-Hook BYE 200 OK Disconnect tone Figure 12: Originating VBD Call Signalling Flow INVITE sip:<called number>@<uri-host> SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkojdqtn0048oghhomk2f1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>> Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 1 INVITE Max-Forwards: 29 Contact: <sip:<contact uri>:5060;transport=udp> Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-messagesummary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/si mservs+xml,application/vnd.etsi.aoc+xml,application/x-session-info Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Date: Wed, 12 Sep :56:34 GMT Supported: 100rel,timer User-Agent: Alcatel-Lucent ISAM Allow-Events: refer P-Preferred-Identity: sip:<uri-user>@<uri-host> Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Document Version 2.0 Confidential Page 44

45 Content-Length: 240 P-Early-Media: supported Route: <sip:<called agent>:5060;lr> o=icf 1 0 IN IP4 <sbc-vip> s=session c=in IP4 <sbc-vip> t=0 0 m=audio <sbc-rtp-port> RTP/AVP a=rtpmap:8 PCMA/8000/1 a=ptime:10 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp: ,32-36 a=sendrecv SIP/ Trying Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkojdqtn0048oghhomk2f1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>> Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 1 INVITE SIP/ Session Progress Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkojdqtn0048oghhomk2f1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag= tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>>;tag=sdauaa499-4ef943a lucentpcsf To: <sip: @ims.plvint.co.nz>;tag= Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 1 INVITE Contact: <sip:<called number>@<session agent>:5060;transport=udp> Require: 100rel Content-Type: application/sdp Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE,P UBLISH Date: Wed, 12 Sep :57:07 GMT Organization: Alcatel RSeq: 1 Content-Length: 191 Server: Lucent-HPSS/3.0.3 v=0 o=lucentfs IN IP4 <session agent> s=- Document Version 2.0 Confidential Page 45

46 c=in IP4 <session agent> t=0 0 m=audio <session agent-rtp-port> RTP/AVP a=rtpmap:101 telephone-event/8000 a=sendrecv a=ptime:10 PRACK sip:<called number>@<session agent>:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bko3ktf110eougghsmn5b1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>>;tag=sdauaa499-4ef943a lucentpcsf Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 2 PRACK Max-Forwards: 29 Date: Wed, 12 Sep :56:36 GMT RAck: 1 1 INVITE Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bko3ktf110eougghsmn5b1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>>;tag=sdauaa499-4ef943a lucentpcsf Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 2 PRACK Contact: <sip:<called number>@<session agent>:5060;transport=udp> Server: Lucent-HPSS/3.0.3 Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkojdqtn0048oghhomk2f1.1 From: <display name> <sip:<uri-user>@<uri-host>>;tag=sdauaa bc-07a8 To: <called number> <sip:<called number>@<uri-host>>;tag=sdauaa499-4ef943a lucentpcsf Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 1 INVITE Contact: <sip:<called number>@<session agent>:5060;transport=udp> Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE,PUBLISH Supported: timer Session-Expires: 1800;refresher=uas Server: Lucent-HPSS/3.0.3 Content-Length: 0 Require: timer ACK sip:<called number>@<session agent>:5060;transport=udp SIP/2.0 Document Version 2.0 Confidential Page 46

47 Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hg4bkprquha101g6hihoml6h0.1 From: <display name> To: <called number> <sip:<called Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20 CSeq: 1 ACK Max-Forwards: 29 Contact: <display name> <sip:<contact uri>:5060;transport=udp> Content-Length: 0 B3 Simple Endpoint Signalling Flows Call Waiting service provider Informs BBIP-V to Play Call-Waiting Tone within an existing dialogue Figure 12: Call Waiting Play Tone Signalling Flow INFO: service provider to BBIP-V INFO sip:<contact uri >:5060 SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling number>@<session agent>>;tag= To:<sip:<uri-user>@<uri-host>>;tag= c Call-ID:000001a0-2b17ffff-00002dcb5-4b c@sipua CSeq: INFO Contact:<sip:<session agent>:5060> Max-Forwards:10 Content-Type:application/broadsoft Content-Length:84 play tone CallWaitingTone1 Document Version 2.0 Confidential Page 47

48 Calling-Name: <calling display name> Calling-Number:<calling number> 200OK BBIP-V to service provider SIP/ OK Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>>;tag= To: Call-ID: CSeq: INFO Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Supported: timer Allow-Events: refer Content-Length: 0 Cancel Call Waiting service provider Informs BBIP-V to Cancel Call-Waiting Tone Figure 13: Cancel Call Waiting Tone Signalling Flow INFO: service provider to BBIP-V INFO sip:<contact uri >:5060 SIP/2.0 Via:SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling number>@<session agent>>;tag= To:<sip:<uri-user>@<uri-host>>;tag= c Call-ID:000001a0-2b17ffff-00002dcb5-4b c@sipua CSeq: INFO Contact:<sip:<session agent>:5060> Max-Forwards:10 Document Version 2.0 Confidential Page 48

49 Content-Type:application/broadsoft Content-Length:22 stop CallWaitingTone 200OK BBIP-V to service provider SIP/ OK Via: SIP/2.0/UDP <session agent>;branch=z9hg4bkbroadworks.1jtjvnl-a.b.c.dv From: <calling display name> <sip:<calling agent>>;tag= To: Call-ID: CSeq: INFO Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, NOTIFY, OPTIONS, REFER, SUBSCRIBE Supported: timer Allow-Events: refer Content-Length: 0 Call Hold BBIP-V Informs service provider that User pressed flash hook Figure 14: Call Hold Signalling Flow INFO: BBIP-V to service provider INFO sip:<session agent>:5060 SIP/2.0 Via: SIP/2.0/UDP <sbc-vip>;branch=z9hg4bk*002e f8-0b85 From: <sip:<uri-user>@<uri-host>>;tag= To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID: d-2194ffff-00002dc63-55a @sipua Document Version 2.0 Confidential Page 49

50 CSeq: 3 INFO Max-Forwards: 30 Contact: <sip:<contact uri>:5060> Authorization: DIGEST username= ,realm= ufb.labnetwork,nonce= BroadWorksXgz7r321xThifgujBW,uri= sip:;user=pho ne,cnonce= 2dc6f-48a6-36b2444,nc= ,qop=auth,response= e190dca98f0d001d27f03ae69,algorithm=MD5,opaqu e= Date: Wed, 29 Feb :32:54 GMT Content-Type: application/broadsoft Content-Length: 17 event flashhook 200 OK: service provider to BBIP-V SIP/ OK Via:SIP/2.0/UDP <sbc-vip>;branch=z9hg4bk*002e f8-0b85 From:<sip:<uri-user>@<uri-host>;tag= To: <called number> <sip:<called number>@<uri-host>>;tag= Call-ID: d-2194ffff-00002dc63-55a @sipua CSeq:3 INFO Content-Length:0 Document Version 2.0 Confidential Page 50

51 Call Waiting end-to-end signalling flows: For call waiting there are four transactions to show 1. Invoke Call wait (play call wait tone) 2. Answer call wait (first hookflash and stop call wait tone) Figure 15: Call Waiting End-to-End (Transactions 1 & 2) Signalling Flow Document Version 2.0 Confidential Page 51

52 3. Subsequent flash hooks Figure 16: Call Waiting End-to-End (Transaction 3 ) Signalling Flow 4. Abandon call waiting before answer Figure 17: Call Waiting End-to-End (Transaction 4 ) Signalling Flow Document Version 2.0 Confidential Page 52

53 Call Hold: End to end signalling flow For call Hold there are two transactions to show 1. Invoke Call Hold (First hookflash) Figure 18: Call Hold End-to-End (Transaction 1) Signalling Flow 2. Recall Held party (Second hookflash) Figure 19: Call Hold End-to-End (Transaction 2) Signalling Flow Document Version 2.0 Confidential Page 53

54 Call Transfer: End to end signalling flow Figure 20: Call Transfer Signalling Flow Note: C number will be sent as either RFC2833 or Clear Channel G.711 depending upon negotiation between Softswitch and BBIP-V Document Version 2.0 Confidential Page 54

55 Three-Way Call: End to end signalling flow Figure 20: Three Way Call Signalling Flow Note: C number will be sent as either RFC2833 or Clear Channel G.711 depending upon negotiation between Softswitch and BBIP-V Document Version 2.0 Confidential Page 55

56 Technical User Guide Appendix C Ethernet Frame Structure The Chorus BBIP handover interface uses logical VLAN separation to provide a mechanism to control and direct the BBIP traffic sent to and received from the service provider. Based on the international IEEE standard (802.1ad), there are three possible options for this VLAN encapsulation. Note that the encapsulation only has local significance between the service provider device and the Chorus 7450 EAS interface providing the handover. In line with the IEEE 802.1ad standard, a specific code (TPID) is inserted in to the VLAN header tag to align the single tag to being a Service- or S-Tag. The following diagram shows a schematic for the resultant frame: In this scenario, any traffic that arrives at the handover from the Chorus network direction will have a single S-VLAN tag pushed on to it and forwarded towards the service provider. The S-VLAN ID will have been previously agreed with the customer as part of the onboarding process, thus allowing the service provider to identify a frame as belonging to their BBIP service as opposed to any other service available on their handover. In the reverse direction, the expectation is that the service provider would similarly take an un-tagged frame, push the appropriate 802.1ad S-tag and forward towards the Chorus network.

57 The Chorus handover can be alternatively set up to provide double-tagged frames, as shown in the following diagram: In this mode the frame has two tags appended to it, an S-tag (as previously described), and an inner or C-tag. This inner tag will have a default identifier value of 10. If a different value is required then this should be agreed during on-boarding. Note the C-VLAN ID has no significance for Chorus so can be any value within the standard limits for VLAN numbers (1 4093). Note for the above frame the outer (S) tag is configured with a TPID of 0x88a8. The implication of this is that the frame is fully compliant to the IEEE 802.1ad standard for double tagged frames. However, many vendors equipment defaults to the pre-standard position for double-tagging, defined by Cisco and known as q-in-q. The primary difference between this and full 802.1ad is that the outer (S) tag has a TPID value equal to that of the inner tag (TPID for both tags = 0x8100) as shown in the following diagram. The Chorus handover can support this configuration also, subject to the same rules as for 802.1ad configuration (e.g. agree SVID value, default CVID = 10, CVID can be changed on agreement). Document Version 2.0 Confidential Page 57