Baseband IP Voice handover interface specification - … IP voice... · Baseband IP Voice handover...

Technical User Guide

Baseband IP

Voice handover interface specification

Document version July 2013

Baseband IP Voice Handover Interface Specification

Document Version 2.0 Confidential Page 2

© Copyright Chorus 2011

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.




Table of Contents

INTRODUCTION ....................................................................................................................... 4 1.1. PURPOSE ...................................................................................................................... 4 1.2. CONTRACTUAL REFERENCE .................................................................................................. 4 1.3. USE OF THE NAME CHORUS ........................................................ ERROR! BOOKMARK NOT DEFINED. 1.4. LIMITATIONS.................................................................................................................. 4

2. SOLUTION BACKGROUND ............................................................................................. 5 2.1. OVERVIEW / EXECUTIVE SUMMARY ......................................................................................... 5 2.2. SCOPE......................................................................................................................... 6

3. HANDOVER INTERFACE ................................................................................................ 7 3.1. PHYSICAL / LOGICAL INTERFACE ............................................................................................ 7 3.2. VOICE HANDOVER POINT TOPOLOGIES ................................................................................... 10 3.3. MEDIA CHARACTERISTICS ................................................................................................. 13 3.4. SIP SIGNALLING INTERFACE .............................................................................................. 15

APPENDIX A: DEFINITIONS, ACRONYMS AND ABBREVIATIONS ...................................................... 19

APPENDIX B: SIGNAL FLOWS ................................................................................................... 21 B1 OVERVIEW OF SIGNALLING FLOWS........................................................................................ 21 B2 SIP SIGNALLING FLOWS................................................................................................... 23 B3 SIMPLE ENDPOINT SIGNALLING FLOWS ................................................................................... 47

APPENDIX C – ETHERNET FRAME STRUCTURE ............................................................................. 56

APPENDIX D - BBIP VOICE DIAL PLAN ....................................................................................... 59




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.

1.2. 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.

1.3. 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.




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.

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.

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).

Premise wiring

Access RENSBC

HA

[email protected](up to five domain names per HOP) Session Agent/

Proxy address

ISA

MIS

AM

ISA

MIS

AM

Session

Agent/SIP

proxy

RSP network

ISA

MAnalogue

ports

Chorus Regional Ethernet Network

EASs

802.1ad or Q-in-Q tagsSBC VIP

address(Plus Primary

Secondary

addresses)

Map

RSP.domain.name to/

from Session Agent/

Proxy Address

ETP

Retail Service Provider

VLAN

Premise wiring

Access RENSBC

HA

[email protected](up to five domain names per HOP) Session Agent/

Proxy address

ISA

MIS

AM

ISA

MIS

AM

Session

Agent/SIP

proxy

RSP network

ISA

MAnalogue

ports

Chorus Regional Ethernet Network

EASs

802.1ad or Q-in-Q tagsSBC VIP

address(Plus Primary

Secondary

addresses)

Map

RSP.domain.name to/

from Session Agent/

Proxy Address

ETP

Retail Service Provider

VLAN




2.2. Scope

2.2.1. 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 4.3.02) 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.

2.2.2. 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 voicemail 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.




3. Handover interface

3.1. Physical / Logical Interface

3.1.1. 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

3.1.2. 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.




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

3.1.3. 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.

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 All SBCs have the same Domain name to HOP mappings

o Each SBC may have a separate HOP VLAN using a different next-hop address per VLAN

o All SBCs use the same Session Agent address for a given VLAN o Multiple SBC can share a HOP VLAN

Chorus side

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.




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 BBIP-V SBCs using the same VLAN on a HOP

o 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.

3.1.4. 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 end-

user, 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.




3.2. Voice Handover Point Topologies

This section outlines the different HOP topologies that may be used by the service provider.

3.2.1. 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.

3.2.2. 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.

SBC

HA

Session Agent Address

One Subnet for all SBC for a HOC

802.1ad or Q-in-Q

tagged HOP

Chorus REN RSP

SBC

HA

SBC address x 3

VIP

Primary

Secondary

SBC address x 3

VIP

Primary

Secondary

VLAN1/Subnet1

EASs

proxy




3.2.3. 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

Chorus REN RSP

SBC

HA

SBC address x 3

VIP

Primary

Secondary

VLAN1/Subnet1

VLAN2/Subnet2

802.1ad or Q-in-Q

tagged HOP

EASs

SBC

HASBC address x 3

VIP

Primary

Secondary

proxy(s)

Session Agent Address VLAN2

Session Agent Address VLAN1

SBC

HA

VLAN1 Session Agent Address

One Subnet per SBC for a HOC via a Gateway

Chorus REN RSP

SBC

HA

Each HOCSBC address x 3

VIP

Primary

Secondary


VIP

Primary

Secondary

VLAN1/Subnet1

VLAN2/Subnet2

802.1ad or Q-in-Q

tagged HOP

EASsGateway(s)

proxy(s)

VLAN2 Session Agent Address

Gateway Addressfor HOC1

802.1ad or q-in-Q

tagged HOP





3.2.4. 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 .

SBC

HA

HOC1 Session Agent Address

Multiple HOPs within a REN (Routed Network example)

Chorus REN RSP

SBC

HA


VIP

Primary

Secondary


VIP

Primary

Secondary

VLAN2

EAS

(Site 1)

VLAN1

Gateway(s)

HOC2 Session Agent Address



EAS

(Site 2)

HOP1

HOP2

proxy(s)




3.3. Media Characteristics

3.3.1. 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)

3.3.2. 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 8 0 101

a=rtpmap:8 PCMA/8000/1

a=ptime:10

a=rtpmap:0 PCMU/8000/1

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15,32-36

a=sendrecv

3.3.3. 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

3.3.4. Echo Cancellation




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]

3.3.5. 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

3.3.6. RTCP

The service supports RTCP with SR and RR records being produced.

3.3.7. 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.

3.3.8. 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).




3.4. SIP Signalling Interface

3.4.1. Standards Support

The protocols used at the handover interface shall conform to the specifications listed in Table 1.

Standard Description

RFC 791 Internet Protocol (IPv4)

Note: IPv6 support is not currently supported.

RFC 2327 SDP: Session Description Protocol

RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

RFC 2976

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)

RFC 3261

SIP: Session Initiation Protocol

The transport method supported for SIP signalling is UDP (RFC 768).

The use of TCP (RFC 793) is not supported.

RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)

RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)

RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method

RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)

RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity

within Trusted Networks

RFC 3550 RTP: A Transport Protocol for Real-Time Applications

RFC 3842 A Message Summary and Message Waiting Indication Event Package for

the Session Initiation Protocol (SIP)

RFC 4028 Session Timers in the Session Initiation Protocol (SIP)

RFC 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for

Authorization of Early Media

Table 1: Standards Support

3.4.2. SIP Methods Support

The minimum set of SIP methods that require service provider support include those shown in Table 2.

Method Use

REGISTER The SIP REGISTER method is used by the BBIP-V to establish and maintain

registration with the service provider’s softswitch.

INVITE

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).

ACK 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




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

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.

NOTIFY The SIP NOTIFY method is only required if a service provider intends to support the

Message Waiting Indication supplementary service.

PRACK The PRACK (Provisional Response Acknowledgement) method provides provisional

responses to certain SIP messages.

OPTIONS The SIP OPTIONS method allows a UA to query another UA or a proxy server as to

its capabilities.

INFO The SIP method INFO is supported.

Table 2: SIP Methods

3.4.3. 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.

3.4.4. 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).




2) When the line attempts to re-register it will receive a 503:Service unavailable response to the REGISTER. The line will attempt to re-register 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 ring-back 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 Tone

486 Busy Here Busy Tone (BT)

600 Busy Everywhere

404 Not Found

Number Unobtainable Tone (NUT)

(Note) 604 Does Not Exist Anywhere

410 Gone

All others 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 042292003 or 42292003) 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 200 §5.5.2). 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:




Alert-Info: <http://127.0.0.1/Bellcore-dr2> DA2 cadence Alert-Info: <http://127.0.0.1/Bellcore-dr3> DA3 cadence

Alert-Info: <http://127.0.0.1/Bellcore-dr4> 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: <http://127.0.0.1/Bellcore-dr1> 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.

3.4.5. 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.




Appendix A: Definitions, Acronyms and Abbreviations

Term Definition

AMS Access Management System

APC Access Provisioning Centre

AS Application Server

ATA Analogue Telephone Adapter

BBIP-V Baseband IP - Voice

CCIL Chorus Co-Innovation Laboratory

CFH Crown Fibre Holdings

CLIP Calling Line Identity Presentation

CLIR Calling Line Identity Restriction

E2E End to End

E-NNI Ethernet Network to Network Interface

FAIMS Facility and Inventory Management System

FDS First Data Switch

FSS-P Fulfil Support System - Provisioning

FTTX Fibre To The X (Home or Premises)

G.711a Codec to ITU-T G.711 Recommendation, with A-law variant

GigE Gigabit Ethernet

GPON Gigabit Passive Optical Network

HOP Handover Point

ICMS Integrated Customer Management System

IP Internet Protocol

ISAM Integrated Services Access Multiplexor

ITU-T International Telecommunications Union - Telecommunications

LAG Link Aggregation Group

ms milli-second

MWI Message Waiting Indicator

NT Network Termination

NSP Network Service Provider

NGA Next Generation Access

OLT Optical Line Terminator

ONT Optical Network Terminator

OO&T Online Order & Tracking

POTS Plain Old Telephone Service

PSTN Public Switched Telephone Network

RBI Rural Broadband Initiative

REN Regional Ethernet Network

RFC Request For Comments

service provider Service provider

SA Session Agent




Term Definition

SBC Session Border Controller

SIP Session Initiation Protocol

TCF Telecommunications Carriers Forum

TNZ Telecom New Zealand

TUG Technical User Guide

UA User Agent

UFB Ultra Fast Broadband

VBD Voice Band Data

VoIP Voice over Internet Protocol




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 HOC SBC VIP specified by service provider

sbc-rtp-port Port number supplied by the SBC that it will receive RTP on

session agent HOC Session Agent IP address specified by service provider

session agent-rtp-

port

Port number supplied by the Session Agent that it will

receive RTP on

uri-user User part of provisioned uri

uri-host Host part of provisioned uri Domain name for service provider

display name For BBIP-V originated calls the SIP Display Name field will contain <directory-number> if populated or <uri-

user> 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.

username 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’ and ‘@’

called number digits entered by the end user when making a call

calling number the number or name of the caller as forwarded by the service provider

May be another BBIP number or a caller on another

network including the PSTN

calling display name

the display name received from the service provider for the caller

Examples given are:

(1) Registration

(2) Registration with authentication (state authentication is optional)

(3) BBIP-V originated call




(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




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>‘ <sip:<uri-user>@<uri-host>;user=phone>;tag=SD2e4v701-b72e12N26589e89-192c

To: ‘<display name>‘ <sip: <uri-user>@<uri-host>;user=phone>

Call-ID: SD2e4v701-3d75479559d11766d53dd16aabab663c-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/2.0 200 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=1436052875


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




(2) Registration with authentication (note - use of authentication is optional)

Figure 5: Registration with Authentication Signalling Flow




To: ‘<display name>‘ <sip: <uri-user>@<uri-host>;user=phone>


CSeq: 1 REGISTER

Max-Forwards: 29


Expires: 3600

Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-message-summary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/simservs+xml,application/vnd.etsi.aoc+x


Supported: path


Content-Length: 0


SIP/2.0 401 Unauthorized





CSeq: 1 REGISTER

WWW-Authenticate: Digest realm=‘<uri-host>‘,nonce=‘fbd73abe748d95612e56ffc6450854d5.1337658823’,stale=FALSE,algorithm=MD

5





Content-Length: 0



From: : ‘<display name>‘ <sip:<uri-user>@<uri-host>;user=phone>;tag=SD2e4v701-b72e12N26589e89-d15

To: : ‘<display name>‘ <sip:<uri-user>@<uri-host>;user=phone>


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-message-summary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/simservs+xml,application/vnd.etsi.aoc+x


Authorization: Digest username=‘<username>‘,realm=‘<uri-host>‘,nonce=‘fbd73abe748d95612e56ffc6450854d5.1337658823’,u

ri=‘sip: a.b.c.d’,response=‘b7c348fb1e879b1437a3a285dd75ed28’,algorithm=MD5,opaque=‘‘

Supported: path


Content-Length: 0


SIP/2.0 200 OK


From: ‘<display name>‘ <sip:<uri-user>@<uri-host>;user=phone>;tag=SD2e4v701-b72e12N26589e89-d15



CSeq: 2 REGISTER

Expires: 3600

Contact: <sip:<uri-user>@<uri-host>;5060>;expires=3600


Content-Length: 0




(3) BBIP-V Originating Call

Figure 6: BBIP-V Originated Call Signalling Flow

INVITE sip:<called number>@<uri-host> SIP/2.0

Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKdl2v19106g60oh8bv3d0.1

From: ‘<display name>‘ <sip:<uri-user>@<uri-host>>;tag=SDlvuga01-0082-00000010-05fc

To: ‘<called number>‘ <sip:<called number>@<uri-host>>

Call-ID: SDlvuga01-09889041e8e0b68714681253dec131c4-a084g20

CSeq: 1 INVITE

Max-Forwards: 29

Contact: <sip:<contact uri>:5060;transport=udp>

Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-message-summary,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 2012 01:17:27 GMT

Supported: 100rel,timer


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





s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv

SIP/2.0 100 Trying

Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKdl2v19106g60oh8bv3d0.1

From:’<display name>‘<sip:<uri-user>@<uri-host>>;tag=SDlvuga01-0082-00000010-05fc

To:’<called number>‘<sip:<called number>@ufb.labnetwork>

Call-ID:SDlvuga01-09889041e8e0b68714681253dec131c4-a084g20

CSeq:1 INVITE

Content-Length:0

SIP/2.0 180 Ringing



To:’<called number>‘<sip:<called number>@<uri-host>>;tag=823108389-1337217447619


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/2.0 200 OK





CSeq:1 INVITE

Require:timer

Session-Expires:480;refresher=uas

Supported:timer


P-Asserted-Identity:’’<display name>‘<sip:<uri-user>@<session agent>;user=phone>

Privacy:none





Accept:application/media_control+xml,application/sdp

Content-Type:application/sdp

Content-Length:219

v=0

o=BroadWorks 22853 1 IN IP4 <session agent>

s=-

c=IN IP4 <session agent>

t=0 0

m=audio <session agent-rtp-port>RTP/AVP 8 101


a=ptime:10


a=fmtp:101 0-15,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=SDlvuga01-0082-00000010-05fc

To: ‘<called number>‘<sip:<called number>@<uri-host>>;tag=823108389-1337217447619


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=z9hG4bKelf36t1088s1hh0bl7h1cd0000010.1

From: ‘<display name>‘<sip:<uri-user>@<uri-host>>;tag=SDlvuga01-0082-00000010-05fc

To: ‘<called number>‘<sip:<called number>@<uri-host>>;tag=823108389-1337217447619


CSeq: 2 BYE

Max-Forwards: 29

Content-Length: 0

SIP/2.0 200 OK

Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKelf36t1088s1hh0bl7h1cd0000010.1




CSeq:2 BYE

Content-Length:0




(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


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>


Call-ID: SDqh7pd01-236dbadc4ec418df4ec8b65ef7a30ddb-a080050

CSeq: 102 INVITE


Date: Thu, 14 Jun 2012 23:58:40 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH

Supported: replaces, timer


Content-Length: 260


v=0





s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKag5fsa00fo3gnh02g180.1;received=a.b.c.d;rport=5060


To: ‘<called number>‘ <sip:<called number>@<uri-host>;tag=as4c771203


CSeq: 102 INVITE

Server: Asterisk PBX 1.8.12.0



WWW-Authenticate: Digest algorithm=MD5, realm=‘asterisk’, nonce=‘5ac3de08’

Content-Length: 0


Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKb0cguj00fo800hkur3s0.1

Max-Forwards: 69


To: <sip: <called number>@<uri-host>>

Contact: <sip:contact uri>:5060;transport=udp>


CSeq: 103 INVITE


Authorization: Digest username=‘094400999’, realm=‘asterisk’, algorithm=MD5, uri=‘sip:[email protected]’, nonce=‘5ac3de08’,

response=‘44606f4821ef82c69e4a0f5086b4eb85’

Date: Thu, 14 Jun 2012 23:58:40 GMT




Content-Length: 260


v=0





s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,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


Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKihef3d103ohgthc7t0f0.1

From: ‘<display name>‘ <sip:<uri-user>@<uri-host>>;tag=SDicec001-0082-0000007d-0669


Call-ID: SDicec001-6cd3456782424da2609d9d79ae374e94-a084g20

CSeq: 1 INVITE

Max-Forwards: 29








Date: Tue, 22 May 2012 00:10:07 GMT



Allow-Events: refer



Min-SE: 90


Content-Length: 240



v=0


s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv

SIP/2.0 100 Trying





CSeq: 1 INVITE

SIP/2.0 183 Session Progress



To: ‘<called number>‘ <sip:<called number>@<uri-host>>;tag=SDicec099-4efa7421-1337457892235098lucentPCSF-000525


CSeq: 1 INVITE

Contact: <sip:<called number>@<session agent>:5060;transport=udp>




Require: 100rel


Allow:

INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE,P

UBLISH

Date: Mon, 21 May 2012 23:10:09 GMT

Organization: Alcatel

RSeq: 1

Content-Length: 191

Server: Lucent-HPSS/3.0.3

v=0

o=LucentFS5000 21375400730 1337645407 IN IP4 <session agent>

s=-


t=0 0

m=audio <session agent-rtp-port> RTP/AVP 8 101


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




CSeq: 2 PRACK

Max-Forwards: 29

Date: Tue, 22 May 2012 00:10:09 GMT

RAck: 1 1 INVITE

Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKj1lglm10fgdgohkr23m0.1




CSeq: 2 PRACK



Content-Length: 0

SIP/2.0 200 OK








CSeq: 1 INVITE


Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE,PUBLISH

Supported: timer

Session-Expires: 1800;refresher=uas


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=z9hG4bKjhrj70202021nh4bu7u0.1

From: ‘<display name>‘ <sip:<uri-user>@<uri-host>;tag=SDicec001-0082-0000007d-0669

To: ‘<called number>‘ <sip:<called number>@<uri-host>;tag=SDicec099-4efa7421-1337457892235098lucentPCSF-000525


CSeq: 1 ACK

Max-Forwards: 29


Content-Length: 0




(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.dV5060-0-741309136-1020290170-1337217447327-

From:’<calling display name>‘<sip:<calling number>@<session agent>;user=phone>;tag=1020290170-1337217447327-

To:’<display name>‘<sip:<uri-user>@<uri-host>:5060>

Call-ID:[email protected]

CSeq:741309136 INVITE


Supported:100rel,timer


Accept:application/media_control+xml,application/sdp,multipart/mixed

Min-SE:60

Session-Expires:480;refresher=uac

Max-Forwards:10


Content-Length:245

v=0


s=-


t=0 0




m=audio <session agent-rtp-port> RTP/AVP 8 0 101


a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv

SIP/2.0 100 Trying

Via: SIP/2.0/UDP <session agent>;branch=z9hG4bKBroadWorks.1jtjvnl-a.b.c.dV5060-0-741309136-1020290170-1337217447327-

From: ‘<calling display name>‘<sip:<calling number>@<session agent>;user=phone>;tag=1020290170-1337217447327-

To: ‘<display name>‘<sip:<uri-user>@<uri-host>:5060>

Call-ID: [email protected]

CSeq: 741309136 INVITE

SIP/2.0 180 Ringing



To: ‘<display name><sip:<uri-user>@<uri-host>:5060>;tag=SDqkcje99-0082-00000011-05fdi0



Contact: ‘<display name>‘ <sip:<contact uri>@<sbc-vip>:5060;transport=udp>


Supported: 100rel

Allow-Events: refer

Content-Length: 0

SIP/2.0 200 OK



To: ‘<display name>‘<sip:<uri-user>@<uri-host>:5060>;tag=SDqkcje99-0082-00000011-05fdi0



Contact: ‘<display name>‘ <sip:<contact uri>@<sbc-vip>:5060;transport=udp>


Require: timer

Supported: timer

Allow-Events: refer

Session-Expires: 480;refresher=uac


Content-Length: 214

v=0


s=Session

c=IN IP4 <sbc-vip>

t=0 0

m=audio <sbc-rtp-port> RTP/AVP 8 101





a=ptime:10


a=fmtp:101 0-15,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.dV5060-0-741309136A1020290170-1337217447327-


To:’<display name>‘<sip:<uri-user>@<uri-host>:5060>;tag=SDqkcje99-0082-00000011-05fdi0


CSeq:741309136 ACK


Max-Forwards:10

Content-Length:0

BYE sip:<contact uri >:5060;transport=udp SIP/2.0



To:’<display name>‘<sip:<uri-user>@<uri-host>:5060>;tag=SDqkcje99-0082-00000011-05fdi0


CSeq:741309151 BYE

Max-Forwards:10

Content-Length:0

SIP/2.0 200 OK



To: ‘<display name>‘<sip:<uri-user>@<uri-host>:5060>;tag=SDqkcje99-0082-00000011-05fdi0


CSeq: 741309151 BYE

Content-Length: 0




(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


From:’Anonymous’<sip: <session agent>>;tag=145211360-1327719916032-

To:’<display name>‘<sip:<uri-user>@<uri-host>;rci=1.1>




Supported:100rel,timer



Min-SE:60


Max-Forwards:10


Content-Length:262

v=0


s=-


t=0 0








a=fmtp:101 0-15,32-36

a=sendrecv

a=ptime:10




(8) Hot line

Call flow is identical to normal BBIP-V originated call. INVITE only is shown below to show how the provisioned direct-

uri 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 04 6060842 and the service provider Host URI is rsp.co.nz, the direct-uri parameter would be:

sip:[email protected]

The constructed Request URI line would be:

INVITE sip:[email protected] SIP/2.0

INVITE <direct uri> SIP/2.0

Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bK02fc5ad0c47498182e2973bca16494c74ee6b1bf-

1327541637471210

Route: <sip: <session agent>:5060;lr>

From: ‘<display name>‘ <sip: <uri-user>@<uri-host>>;tag=4ee6b1bf-1327541637470936-mw-po-lucentPCSF-006653

To: <sip:hotline-user@hotline-host>


CSeq: 1 INVITE

Max-Forwards: 29





Supported: 100rel


Allow-Events: refer


Content-Length: 274


Route: <sip:<uri-user>@<session agent>:5060;lr>

v=0


s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv




(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.dV5060-0-800415242-1261046817-1315860823058-


To:’<display name>‘<sip:<uri-user>@<uri-host>:5060>




Alert-Info:<http://127.0.0.1/Bellcore-dr2>



Supported:timer

Min-SE:60


Max-Forwards:10


Content-Length:215

v=0


s=-


t=0 0


a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000


a=ptime:10

a=sendrecv




(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=2.10333 SIP/2.0


From:<sip:<session agent>>;tag=2119342799-1326926135233-

To:<sip: <uri-user>@<uri-host>>


CSeq:964362208 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/2.0 200 OK

Via: SIP/2.0/UDP <session agent>;received=a.b.c.d;branch=z9hG4bKBroadWorks.1jtjvnl-a.b.c.dV5060-0-964362208-2119342799-1326926135233-

From: <sip: <session agent>>;tag=2119342799-1326926135233-

To: <sip: <uri-user>@<uri-host>>


CSeq: 964362208 NOTIFY

Contact: sip: <sbc-vip>:5060


Content-Length: 0

Server: Alcatel-Lucent-HPSS/3.0.3




(11) SIP Options Ping (BBIP-V SBC to service provider heartbeat)

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


To: sip:ping@<session agent>

From: <sip:ping@<sbc-vip>>;tag=543a637c8d42c70ed16cc21ad85baf1e0000010

Max-Forwards: 70

CSeq: 2 OPTIONS

SIP/2.0 200 OK

Via:SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKqie9tt308g30oh4gq270

From:<sip:ping@<sbc-vip>>;tag=543a637c8d42c70ed16cc21ad85baf1e0000010

To:<sip:ping@<session agent>>;tag=336039703-1340054043609


CSeq:2 OPTIONS

Allow-Events:call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status

Content-Length:0

BBIP-V

SBC

RSP

SA

200 OK

OPTIONS

200 OK

OPTIONS

T=60 seconds

NOTE: If a 200 OK or alternate agreed

response is not received, the RSP SA

will be marked as out-of-service.




(12) BBIP-V Originating VBD Call

Figure 12: Originating VBD Call Signalling Flow


Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKojdqtn0048oghhomk2f1.1

From: ‘<display name>‘ <sip:<uri-user>@<uri-host>>;tag=SDauaa401-0082-000001bc-07a8


Call-ID: SDauaa401-d9edd46fff183a74a6db5368b8df2b95-a084g20

CSeq: 1 INVITE

Max-Forwards: 29


Accept: application/sdp,multipart/mixed,application/broadsoft,application/simple-message-summary,application/vnd.etsi.aoc+xml;schemaversion=2,application/vnd.etsi.aoc+xml;sv=2,application/simservs+xml,application/vnd.etsi.aoc+xml,application/x-session-info


Date: Wed, 12 Sep 2012 03:56:34 GMT



Allow-Events: refer



Min-SE: 90


A BBBIP-V

SBC

RSP

SA

Dialling B

INVITE (SDP)

Ring

Off-hook

183 Session Progress

(SDP)

(Ring-back) Tone

200 OK

(for PRACK)

PRACK

Speech path A – B established (RTP at 10 mS Packetisation rate)

On-HookBYE

200 OK Disconnect tone

Trying

ACK

200 OK

(for INVITE)

Stop (Ring-back) Tone

Path A – B after VBD stimulus detected (RTP at 20 mS Packetisation rate)




Content-Length: 240




s=Session

c=IN IP4 <sbc-vip>

t=0 0



a=ptime:10



a=fmtp:101 0-15,32-36

a=sendrecv

SIP/2.0 100 Trying





CSeq: 1 INVITE

SIP/2.0 183 Session Progress


From: ‘<display name>‘ <sip:<uri-user>@<uri-host>>;tag= tag=SDauaa401-0082-000001bc-07a8

To: ‘<called number>‘ <sip:<called number>@<uri-host>>;tag=SDauaa499-4ef943a1-1347156668210761lucentPCSF-002051

To: ‘01908797’ <sip:[email protected]>;tag=


CSeq: 1 INVITE


Require: 100rel


Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE,PUBLISH

Date: Wed, 12 Sep 2012 02:57:07 GMT

Organization: Alcatel

RSeq: 1

Content-Length: 191


v=0

o=LucentFS5000 21253600872 1347422225 IN IP4 <session agent>

s=-





t=0 0

m=audio <session agent-rtp-port> RTP/AVP 8 101


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




CSeq: 2 PRACK

Max-Forwards: 29

Date: Wed, 12 Sep 2012 03:56:36 GMT

RAck: 1 1 INVITE

Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/UDP <sbc-vip>:5060;branch=z9hG4bKo3ktf110eougghsmn5b1.1




CSeq: 2 PRACK



Content-Length: 0

SIP/2.0 200 OK





CSeq: 1 INVITE


Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,MESSAGE,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE,PUBLISH

Supported: timer

Session-Expires: 1800;refresher=uas


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=z9hG4bKprquha101g6hihoml6h0.1

From: ‘<display name>‘ <sip:<uri-user>@<uri-host>;tag=SDauaa401-0082-000001bc-07a8

To: ‘<called number>‘ <sip:<called number>@<uri-host>;tag=SDauaa499-4ef943a1-

1347156668210761lucentPCSF-002051


CSeq: 1 ACK

Max-Forwards: 29


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.dV5060-0-595233815-801490759-1330482846154

From:’<calling display name>‘<sip:<calling number>@<session agent>>;tag=801490759-1330482846154

To:<sip:<uri-user>@<uri-host>>;tag=0082-00000206-027c

Call-ID:000001a0-2b17ffff-00002dcb5-4b76-658489c@sipua

CSeq:595233815 INFO


Max-Forwards:10

Content-Type:application/broadsoft

Content-Length:84

play tone CallWaitingTone1




Calling-Name: <calling display name>

Calling-Number:<calling number>

200OK BBIP-V to service provider

SIP/2.0 200 OK

Via: SIP/2.0/UDP <session agent>;branch=z9hG4bKBroadWorks.1jtjvnl-a.b.c.dV5060-0-595233815-801490759-1330482846154

From: ‘<calling display name>‘<sip:<calling number>@<session agent>>;tag=801490759-1330482846154

To: <sip:<uri-user>@<uri-host>>;tag=0082-00000206-027c

Call-ID: 000001a0-2b17ffff-00002dcb5-4b76-658489c@sipua

CSeq: 595233815 INFO


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.dV5060-0-595233816-801490759-1330482846154

From:’<calling display name>‘<sip:<calling number>@<session agent>>;tag=801490759-1330482846154

To:<sip:<uri-user>@<uri-host>>;tag=0082-00000206-027c

Call-ID:000001a0-2b17ffff-00002dcb5-4b76-658489c@sipua

CSeq:595233816 INFO


Max-Forwards:10




Content-Type:application/broadsoft

Content-Length:22

stop CallWaitingTone

200OK BBIP-V to service provider

SIP/2.0 200 OK

Via: SIP/2.0/UDP <session agent>;branch=z9hG4bKBroadWorks.1jtjvnl-a.b.c.dV5060-0-595233816-801490759-1330482846154

From: ‘<calling display name>‘<sip:<calling number>@<session agent>>;tag=801490759-1330482846154

To: <sip:<uri-user>@<uri-host>>;tag=0082-00000206-027c

Call-ID: 000001a0-2b17ffff-00002dcb5-4b76-658489c@sipua

CSeq: 595233816 INFO


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-000000f8-0b85

From: <sip:<uri-user>@<uri-host>>;tag=0082-00000201-0277

To: ‘<called number>‘ <sip:<called number>@<uri-host>>;tag=2049889577-1330482763403

Call-ID: 0000019d-2194ffff-00002dc63-55a1-6569464@sipua




CSeq: 3 INFO

Max-Forwards: 30

Contact: <sip:<contact uri>:5060>

Authorization: DIGEST username=‘42292101’,realm=‘ufb.labnetwork’,nonce=‘BroadWorksXgz7r321xThifgujBW’,uri=‘sip:;user=phone’,cnonce=‘2dc6f-48a6-

36b2444’,nc=00000003,qop=auth,response=‘2545839e190dca98f0d001d27f03ae69’,algorithm=MD5,opaque=‘‘

Date: Wed, 29 Feb 2012 14:32:54 GMT

Content-Type: application/broadsoft

Content-Length: 17

event flashhook

200 OK: service provider to BBIP-V

SIP/2.0 200 OK

Via:SIP/2.0/UDP <sbc-vip>;branch=z9hG4bK*002e-000000f8-0b85

From:<sip:<uri-user>@<uri-host>;tag=0082-00000201-0277

To:’<called number>‘ <sip:<called number>@<uri-host>>;tag=2049889577-1330482763403

Call-ID:0000019d-2194ffff-00002dc63-55a1-6569464@sipua

CSeq:3 INFO

Content-Length:0




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




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




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




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




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


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 on-boarding 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.




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).




In summary, there are three options available to Service providersfor the handover service for BBIP:

Description SVID CVID

802.1ad Single Tagged Value agreed during ordering and on-boarding.

TPID must be configured as 0x88a8

No C-tag

802.1ad Double Tagged Value agreed during ordering and on-boarding.

TPID must be configured as 0x88a8

C-Tag value = 10

Q-in-Q Double Tagged Value agreed during ordering and on-boarding.

TPID must be configured as 0x8100 (default on most equipment)

C-Tag value = 10


Appendix D - BBIP Voice Dial Plan

The ISAM-V per shelf dial plan is documented below.

This dial plan has been optimized to support closed numbering for all local, national, and emergency service number ranges, most of the mobile number ranges and for the majority of the regularly dialled short codes, special services codes, e.g. 12x, 018, 0800, 0900 etc

Closed numbering is applied to International number ranges that have fixed number lengths, e.g. North American, most of Australia etc. All other International numbers have open number and require timeout after a minimum number of digits have been dialled.

Open numbering is applied to all other codes.

111 Emergency services fixed length 3 digits

911 Emergency services fixed length 3 digits

999 Emergency services (PSTN announcement) fixed length 3 digits

00[02-57-9]xxxx.T International variable length, timeout after 6 or more digits received (i.e. ‘catch-all’ for other 00 codes not shown below)

001xx{9} North America fixed length 13 digits

0061[^1]x{8} Australia fixed length codes 13 digits

00611xx.T Australia variable length, timeout after 6 or more digits received

006[^1]xxx.T International 006 variable length (except Australia), timeout after 6 or more digits received

01[2-4]x.T Special service codes variable length, timeout after 3 or more digits received (i.e. ‘catch-all’ for other 01 codes not shown below)

01[08] NA/DA operator codes fixed length 3 digits

0110 Auto-collect code fixed length 4 digits

011[^0]x.T Special service codes variable length, timeout after 4 or more digits received

015[^2] TelstraClear service codes fixed length 4 digits

0152x.T Special service codes variable length, timeout after 4 or more digits received

01681800x{7} USA Freephone Access fixed length 15 digits



017[0239] Yabba and International operator codes fixed length 4 digits

017[14-8]x.T Special service codes variable length, timeout after 4 or more digits received

019[67]0[3469]x{7} CLIP/CLIR override codes plus National codes fixed length total 13 digits (note no second dial tone)




019[67]0[0-2578]x.T CLIP/CLIR override codes plus miscellaneous codes variable length, timeout after 6 or more digits received (note no second dial tone)

019[67][2-9]x{6} CLIP/CLIR override codes plus Local codes fixed length total 11 digits (note no second dial tone)

019[67]1x.T CLIP/CLIR override codes plus special service codes variable length, timeout after 5 or more digits received (note no second dial tone)

0198xx Call Plus card fixed length 6 digits


02[3-5]xxxxxxx.T Mobile codes variable length, timeout after 9 or more digits received (i.e. ‘catch-all’ for other 02 codes not shown below)

020[1278]x{6} Orcon mobile etc fixed length 10 digits

020[03-69]xxxxxx.T Mobile codes variable length, timeout after 9 or more digits received

0210[03-7]x{5} Vodafone fixed length 10 digits

0210[1289]xxxxx.T Mobile codes variable length, timeout after 9 or more digits received

021[12]x{6} Vodafone fixed length 10 digits

021[3-9]x{5} Vodafone fixed length 9 digits

022x{7} 2degrees mobile fixed length 10 digits

026[^1]x{6} Telepaging fixed length 10 digits

026[1]xxxxxx.T Mobile codes variable length, timeout after 9 or more digits received

027x{7} Telecom and WXC mobile fixed length 10 digits

028[037]x{6} Compass mobile etc fixed length 10 digits

028[124-689]xxxxxx.T Mobile codes variable length, timeout after 9 or more digits received

029x{7} TelstraClear mobile fixed length 10 digits

0[3469]x{7} National codes fixed length 9 digits

070[03]x{6} WXC PCS, etc fixed length 10 digits

070[124-9]xxxxxx.T National 07 codes variable length, timeout after 9 or more digits received

071xxxxxxx.T National 07 codes variable length, timeout after 9 or more digits received

07[2-9]x{6} National codes fixed length 9 digits

0508x{6} TelstraClear freephone fixed length 10 digits

050[^8]xxx.T Interconnect codes variable length, timeout after 6 or more digits received

05[^0]xxxx.T Interconnect codes variable length, timeout after 6 or more digits received

08[124-689]xxxx.T Misc 08 codes variable length, timeout after 6 or more digits received (i.e. ‘catch-all’ for other 08 codes not shown below

0800x{6} Freephone fixed length 10 digits

080[^0]xxx.T Misc 08 codes variable length, timeout after 6 or more digits received

0830xx Audio-conf fixed length 6 digits

083[13-9]xxx.T Misc 08 codes variable length, timeout after 6 or more digits received

08321x VSP fixed length 6 digits




0832[^1]xx.T Misc 08 codes variable length, timeout after 6 or more digits received

087[459]x EFTPOS/Packet dial-up fixed length 5 digits

087[0-36-8]xx.T Misc 08 codes variable length, timeout after 5 or more digits received

1[03-68]xx.T Special service codes variable length, timeout after 3 or more digits received (i.e. ‘catch-all’ for other 1 codes not shown below)


12[^9] Service codes fixed length 3 digits

129x Service codes fixed length 4 digits

17[459]x EFTPOS/Packet dial-up fixed length 4 digits

17[0-36-8]x.T Special service codes variable length, timeout after 3 or more digits received

19[34589]x Service codes fixed length 4 digits


[2-8]x{6} Local codes fixed length 7 digits

9[02-8]x{5} Local codes fixed length 7 digits

91[^1]x{4} Local codes fixed length 7 digits

99[^9]x{4} Local codes fixed length 7 digits

[*#]xx.T Feature activation codes variable length, timeout after 2 or more digits received (i.e. ‘catch-all’ for * and # codes)

Meaning of Symbols

0-9, * and # represent the respective dialled digits

The symbol ‘x’ is used as a wildcard, designating any event corresponding to symbols in the range 0-9, * and #

A set of ‘alternative’ digit symbols can be enclosed in brackets [ ], o represents one occurrence of any of the enclosed digit symbols o allows for ranging using hyphen symbol - o if a ^ appears immediately following the opening bracket, it means negation. Hence it

represents one occurrence of any NOT enclosed digit symbol

{ n } signifies n occurrences

. signifies zero or more occurrences

x.T defines an end of dialling timer, which is set to 5 seconds. The inter-digit timer is also set to 5 seconds.

Date post:	15-May-2018
Category:	Documents
Upload:	vuongxuyen
View:	243 times
Download:	4 times

Baseband IP Voice handover interface specification - … IP voice... · Baseband IP Voice handover...

Documents