Spartacus System Functional Specification

sentencedebonairΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 4 χρόνια και 21 μέρες)

415 εμφανίσεις

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

1

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


Document Number

EDCS
-
469363

Based on Template

EDCS
-
189226 Rev 2
4

Created By

Faisal Siyavudeen

(fsiyavud)



Spartacus

System Functional Specification

Call Preservation for H.323
VoIP
calls

Reviewers

Department

Name/Title

Devel
opment Engineering

Ivan V
arghis, Srinath Subbarayan, Girish Gangaiah, Toleti Danayya Naidu, Prasanna
Venkatraman
, Debra Ann
-
Sheridan, Man Loh, Rosa Lin
, Parameswaran
Kumaraswamy

DevTest Engineering

Mahesh Raghava, Himadri Choudhury
, Jennifer Vogel

Manufa
cturing


Product Marketing

Kathy Lewis

Customer Advocacy

Paul Giralt

Compliance


The departments and/or individuals listed above should be notified in advance and given a sufficient time period to review th
is document. The
Project Team determines requi
rements for approval according to the scope of the project.


Modification History

Revision

Date

Originator

Comments

1

25 Aug 2005

Faisal Siyavudeen

Initial draft

2

12 Sep 2005

Faisal Siyavudeen

Incorporated review comments.

3

18

Sep 2005

Faisal Siyavude
en

Added more call flow diagrams, added references, and took care of
some review comments.


Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

2

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

Table of Contents

1

Purpose

................................
................................
................................
................................
.....

4

1.1

Scope

................................
................................
................................
................................
.

4

2

Functional Overview

................................
................................
................................
................

4

2.1

System Overview

................................
................................
................................
...............

4

2.2

Feature List (Hardware)

................................
................................
................................
.....

7

2.3

Feature List (Software/Firmware)

................................
................................
.....................

7

2.3.1

Description

................................
................................
................................
..................

7

2.3.2

External Interfaces

................................
................................
................................
......

8

2.4

Features Not Addressed

................................
................................
................................
.....

8

2.5

Software Impact Assessment

................................
................................
.............................

8

2.6

Testability Considerations

................................
................................
................................
.

8

2.7

Manufacturing Considerations

................................
................................
..........................

9

2.8

Ne
twork Management Considerations

................................
................................
..............

9

2.9

Patentability Considerations

................................
................................
..............................

9

2.10

Brand (Counterfeit) Protection Considerations

................................
..............................

9

3

External Specifications

................................
................................
................................
.............

9

3.1

Overview

................................
................................
................................
...........................

9

3.2

Functional Requirements

................................
................................
................................
.

10

3.3

Performance Requirements
................................
................................
..............................

11

3.4

Usability Requirements

................................
................................
................................
...

12

3.5

External Interface Requirements

................................
................................
.....................

12

3.6

Architecture Baseline Requirements

................................
................................
...............

14

3.7

Constraint Requirements

................................
................................
................................
.

15

3.7.1

Compliance Requirements

................................
................................
........................

15

3.7.2

Product Evolution Program, PEP

................................
................................
..............

15

3.8

Qu
ality Requirements

................................
................................
................................
......

15

3.8.1

Security Requirements

................................
................................
..............................

15

3.9

Reliability/Availability Requirements

................................
................................
.............

15

3.9.1

Reliability/Availability Budget

................................
................................
.................

15

3.9.2

Reliability/Availability Model

................................
................................
..................

15

4

Internal Sp
ecifications

................................
................................
................................
............

15

4.1

Overview

................................
................................
................................
.........................

15

4.2

Major Components

................................
................................
................................
..........

16

4.3

Majo
r Data Structures

................................
................................
................................
......

16

4.4

Major External Interfaces

................................
................................
................................

16

4.5

Major Internal Interfaces

................................
................................
................................
.

16

4.6

Software Memory Estimates

................................
................................
...........................

16

4.7

Hardware Memory Options

................................
................................
.............................

16

4.8

Performance

................................
................................
................................
.....................

17

5

Issues, Risks and Dependencies

................................
................................
.............................

17

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

3

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

5.1

Platform Requirements

................................
................................
................................
....

17

5.2

Related Projects

................................
................................
................................
...............

17

5.3

Third Party Relationships

................................
................................
................................

17

5.4

Single Source Components

................................
................................
..............................

18

5.5

Technology Requirements

................................
................................
...............................

18

5.6

Technical Risks
................................
................................
................................
................

18

6

Appendix A
-

<Section title>

................................
................................
................................
..

18

7

Requirements Traceability Considerations

................................
................................
............

18

8

References

................................
................................
................................
..............................

19

9

Glossary

................................
................................
................................
................................
..

19

10

Attachments

................................
................................
................................
........................

19

10.1

Review Action Items

................................
................................
................................
....

19


List of Tables and/or List of Figures are optional and may be deleted.

L
ist of Tables

Table 3.1: Reliability/Availability Budget

................................
................................
................................
...................

15

Table 4.1: Software Memory Estimates

................................
................................
................................
......................

16

Table 4.2: Hardware Memory Options

................................
................................
................................
........................

16


List of Figures

Figure 3.1: Markov State or Reliability Block Diagram

Error! Bookmark not defined.

Figure 3.2: Sensitivity Analysis Diagram

Error! Bookmark not defined.


Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

4

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


1

Purpose

1.1

Scope

Spartacus project would implement preservation of active H.323 calls on an IOS VoIP gateway
when an error occurs on t
he TCP connection used for those calls. It is specifically meant to
address H.323 call preservation for calls between an endpoint controlled by Cisco Call Manager
(CCM) and an IOS voice gateway when the TCP connection between CCM and GW is lost. The
soluti
on would also
preserve the calls

for other scenarios where the signaling and media paths
are different, and the connection loss occurs on the signaling path.


Only the media will be preserved for the call


further signalling on the call may not be possib
le
depending on the socket on which the error occurs.

2

Functional Overview

A sample topology
for this solution is given below.


2.1

System Overview


CCM

IP Phone

IOS Gateway

POTS/IP
Phone


IP WAN

Signalling

Media

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

5

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

An illustrative
call flow

for the solution are given below:



POTS

GW
-

H.32
3
-

CCM

-

Skinny
-

IP Phone


|<
------------
Call Active
-------------
>|


| | | |


| | |<
-
TCP Connection Failure


| | |
(
2
Skinny keepalives lost)


| |

| |


(ignored)|<
--
TCP FIN
--
| (no Release Complete sent)


| | | |


|
--
RLC
--
>|(call torn down on GW)




POTS

GW
-

H.323


CCM
-

Skinny
-

IP Phone


|<
------------
Call Active
--------
-----
>|


| | | |


| | |<
-
TCP Connection failure


| | |
(2 Skinny keepalives lost)


| | | |


(ignored)|<
--
TCP FIN
--
| (no Re
lease Complete sent)


| | | |


| |<
--
RTP/RTCP timer fires
------
|


|<
-
RLC
---
|(call torn down on GW)


This corresponds to a connection loss between the
IP
phone and the CCM. The call will also be
preserved und
er the following conditions.


1.

the connection between CCM and GW is lost, and the FIN never reaches the GW
, but the
GW detects a keep
-
alive timeout.



POTS

GW
-

H.323
-

CCM

-

Skinny
-

IP Phone


|<
------------
Call Active
-------------
>|


|
| | |


| |

<n/w down>
|<
-
TCP Connection failure


| | |
(2 Skinny keepalives lost)


| | | |


(
dropped
)|

X<
-
TCP FIN
-
| (no Release Complete sent)


| |

| |



(ignored)|
(TCP keepalive timeout at GW)
|


2.

the connection between CCM and GW is lost temporarily, and a TCP keepalive from GW
reaches the CCM, causing CCM to send a TCP RST.



POTS

GW
-

H.323
-

CCM

-

Skinny
-

IP Phone



|<
------------
Call Active
-------------
>|


| | | |


| |

<
n/w down
>

|<
-
TCP Connection failure


| | |
(2 Skinny keepalives lost)


| | | |


(dropped)| X<
-
TCP FIN
-
| (no Release Complete sent)


| | | |


| |

<
n/w up>

| |


|
|

TCP KA
----
>
| |


(ignored)
| <
--
TCP RST | |


3.

CCM crashes.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

6

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

There are two kinds of k
eepalive messages in the system


TCP keepalives on the TCP
connection between CCM and the GW (turned on using the SO_KEEPALIVE

socket option) and
SCCP (Skinny) keepalives between the IP phone and CCM. A TCP keepalive timeout will cause
the TCP
socket to b
e closed at the sockets layer
, and the failure is bubbled up to the application
as a connection timeout. A Skinny keepalive timeout

will occur when CCM misses 2 Skinny
keepalives from the phone. The interval at which the Skinny keepalives are sent is confi
gurable
on the CCM.


To facilitate call preservation, the following changes would be required on the CCM.


1.

CallManager

will not send a Release Complete when it detects that the Skinny keep
-
alive
messages have timed out. It will just close the H.225.0 and H
.245 TCP connections, and
internally clear the call

(quiet clearing)
.


2.

This will be controlled by a new service parameter on the CCM.

3.

CCM will do a quiet
clear when it detects a socket error

on H.225.0 or H.245 socket.


The following behavior changes will
be needed on the GW.


1.

The gateway will not tear down the call when it detects a TCP socket closure or error
,

before it gets a Release Complete (this includes a release from either leg of the call). This
includes keep
-
alive timeout, message write errors, re
ad errors, socket closure notification
etc. The media will be preserved till an RTP/RTCP timer occurs or POTS side tears down
the call.

2.

A new cli will be introduced on the GW to turn on call preservation.

This cli will

be
configurable on a global and per
-
d
ial
-
peer basis

(under voice class h323 mode).

3.

A new
cli will be introduced on the GW to display the details of preserved calls.
(Note:
calling number, called number, remote sign and media ip, preserved duration, total
duration, h245 and h225 fd and fd sta
tus
)
.

4.

The existing ‘clear call’ cli can be used to clear long duration preserved calls. The call
identifie
r

obtained from the new ‘show’ cli can be used to identify calls to be cleared.


Call preservation will apply only to active calls



H.225.0 Connect h
as happened, H.245
procedures are completed (or not required),
and
there is a receive audio channel active on the
call
.


These are the types of calls that will be preserved:


1.

Active call between two
IP
phones at the same branch that are both registered to

the same
CallManager cluster (need not be registered to the same server in the cluster).

2.

Active call between a
n IP

phone and the local gateway at a branch

3.

Active call between multiple endpoints (
IP
phones and gateway) to a local conference
bridge resourc
e

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

7

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


These are the failure scenarios under which the above listed calls will be preserved:


1.

WAN Failure


includes WAN links flapping or degraded WAN links

2.

CallManager software crash (ccm.exe service crashes on a CallManager server)

3.

LAN connectivity failure
anywhere except at the local branch.


These are examples of types of calls that would not be preserved. This list is not meant to be
fully exhaustive.


1.

Transient call states, and not established calls (Any call that is not in a connected state)


Example:

O
ne of the parties on the call is on hold
.

2.

One of the parties are located across the WAN (e.g. Unity Voicemail)
.

3.

The call involves a media resource located across the WAN (e.g. Conference Resources)
.

4.

The two parties involved in the call are registered to
different

CallManager

clusters
.



2.2

F
eature List (Hardware)


No hardware changes are required for this project.

2.3

Feature List (Software/Firmware)

2.3.1

Description


CCM features:


1.

When call preservation service parameter is turned on, quiet clearing will be done
wi
thout sending a ReleaseComplete. H.225.0 and H.245 sockets will be closed.

2.

In certain conditions (GW put on hold with MoH), the
media will never time out if the
call is preserved, and this will result in a hung call. CCM will send a proprietary ‘do not
pre
serve’ indication to the GW in such cases so that the GW can tear down such calls
upon connection failure.

3.

CCM will send a ‘preserve’ indication if a call for which ‘do not preserve’ indication has
been sent earlier becomes active again.

4.

If the CCM is regi
stered to a GK, DRQ will be sent to GK.


GW features:


Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

8

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

1.

A new CLI to turn on call preservation.

2.

When the call preservation feature is turned on, the GW will ignore socket closure or
socket errors on H.225.0 or H.245 connections for active calls. The socket

will be
properly closed, but the calls using those connections will not be torn down.

3.

A list of preserved calls will be maintained and a new CLI will be introduced to show the
details of preserved calls.

4.

GW will handle the ‘do not preserve’ and ‘preserve’

indications from CCM and will tear
down the calls for which ‘do not preserve’ indication was received, when a connection
closure
or socket error occurs.

2.3.2

External Interfaces

The following new CLIs will be added by this project on the GW.


1.

‘show h323 calls
preserved’ in exec mode.

2.

‘call preserve’ under ‘voice service voip/h323’


The ‘do not preserve’ and ‘preserve’ indications will be transported
using
a new
non
-
standard
field
in
H.225.0 Notify messa
ge
.

2.4

Features Not Addressed

2.5

Software Impact Assessment

2.6

Testability Considerations


Test team should be able to reproduce different network errors that could occur dur
ing a network
flap. Some of these failures may not be easy to reproduce without some kind of TCP
instrumentation.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

9

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

2.7

Manufacturing Considerations

2.8

Network Management Considerations

2.9

Patentability Considerations

2.10

Brand (Counterfeit) Protection Considerations

3

Exte
rnal Specifications

3.1

Overview


A user who wants to use this solution will enable the new service parameter on the CCM.
He
does not need to turn off TCP keepalives on the CCM.


VAD has to be turned o
ff if RTP/RTCP inactivity detection is used for tearing down hung calls.
VAD can be left on with bi
-
directional silence detection.


By default, the silence/RTP inactivity detection will apply to all calls. To make them applicable
only for preserved calls,
‘limit media
-
inactive’ keyword can be used with the ‘call preserve’ cli.


On the GW, the following configurations will be applied:


voice serice voip


h323


call preserve

[
limit
-
media
-
detect
]



If RTP/RTCP inactivity detection is enabled:


#for all voip d
ial
-
peers

dial
-
peer voice 10 voip


no vad

gateway


timer receive
-
rtcp
<m>

ip rtcp report
-
interval <n>


If bi
-
directional silence detection is enabled:

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

10

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


gateway


timer media
-
inactive <m>

ip rtcp report interval <n>


<The display details for the “show” commands will be added here>


Call preservation
will

be reported through syslog (
which can be
optionally
caught
through an
SNMP trap) so that the administrator can observe the GW, issue the show co
mmands to check
the preserved calls and clear calls if required.


The connection id for the preserved calls and their duration
, preserved duration, remote media
and signaling addresses, calling and calling numbers, and H.225.0/H.245 fd status
can be
obtain
ed from the “show h323 calls preserved” output.


The user can issue ‘show call active voice <connection id>’ to get more details of the call.


The following
existing
command can be used to clear a preserved call by giving its connection
id.


clear call vo
ice causecode 1
-
127 id
<connection id>


A new syslog message will be printed when call preservation is applied. An SNMP trap can be
configured on this syslog message, so that the administrator can be notified when call
preservation occurs on a gateway. Th
e administrator can then start observing the preserved calls.

3.2

Functional Requirements

In addition
to
the requirements in 2.3, the following

points are to be taken care of on the GW:


1.

The following socket errors will be ignored for H.225.0 and H.245 sockets



TCP RST
received on the socket, cannot write to socket, cannot read from socket. For H.245
sockets, H.245 connection initiation failure will also be ignored if two
-
way media is
already established.

2.

Calls using H.225.0 Annex E (using UDP as transport) wi
ll not be affected by this
feature.

3.

The following types of calls would not be preserved


calls in pre
-
connect states, H.225.0
Connect without
a receive media channel
,
and calls receiving
MoH
.

4.

An IPIPGW receiving
a
Notify with the
‘do not preserve’ non
-
sta
ndard ASN indication
will transmit

it
on
the peer leg
.
The IPIPGW will also propagate an RST to the peer leg
(
CSCsa73842)
. However, if an IPIPGW on the path receives a FI
N, it will tear the calls
down.


Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

11

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

5.

Write errors on H.245 messages will
be
ignored as if

the message was sent successfully
,

if the call is ‘active’, with media active in
reverse

direction. If the H.245 procedure that
has this message expects a response, the timeout will cause the call to get torn down


eg:
-

a TCS/MSD message or a RequestMode
. If the H.245 procedure does not require a
response (eg:
-

UserInputIndication), the call will not be torn down
.

6.

Pre
-
Mugello or post
-
Mugello med
ia inactivity detection can be
configured for call
preservation. Pre
-
Mugello behavior is to detect inactivity based on incoming RTP and
RTCP packets
, and required VAD to be turned off. Post
-
Mugello behavior involves
silence detection on the DSP and is base
d on silence in both directions.

7.

An optimum value should be recommended for the inactivity timer. This value will be
decided upon after the dev
-
test stage, and also based on deployment experience at Merril
Lynch.

8.

Fax/Modem calls will not be preserved sinc
e RTP inactivity does not make sense in those
cases. However, Fax/Modem pass
-
through calls can be preserved as they use RTP.

9.

Call preservation will apply only to TDM
-
IP calls, and not for IP
-
IP calls.

10.

Signalling
-
only calls will not be preserved.

11.

When an
H.245 EndSession is received, the H.245 channels will be closed, but the call
will not be torn down. If a connection error occurs after receiving EndSession, the call
will not be preserved.

12.


When the ‘call preserve’ cli is turned on, a warning message will

be displayed stating
that VAD has to be turned off for all calls handled by this GW. If VAD is turned on for
any call, silence may be detected as media inactivity timeout, and the call would be torn
down by mistake.

13.

When ‘call preserve’ cli is configured,

‘no h225 timeout keepalive’ cli should not be
configured.
When ‘no h225 timeout keepalive’ cli is configured, the IEC and cause code
indicates that the call was torn down due to socket error even though the call is actually
torn down later due to media in
activity or pots side disconnect. With the new call
preservation solution, the disconnect cause code will not reflect the socket error. New
IEC diagnostic codes that reflect socket error and closure will be added, and this w
ill be
populated when the socket

error or closure occurs.

14.


New IEC diagnostic codes will be added to distinguish t
he event that caused
call
preservation


a TCP FIN or a socket error on H.225.0/H.
245 socket
.

15.

New debugs introduced
as part of this feature should lend themselves to call filtering.

16.

A syslog message will be generated when call preservation is applied. This

message will
be throttled to the rate of one message per minute.


17.

A configuratio
n option will be added that will make m
edia inactivity timer configuration
affect only the preserved calls.

3.3

Performance Requirements


GW:

1.

Average CPU usage should not increase after call preservation is applied during a
network flap.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

12

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

2.

CPU usage should not s
pike (more than the current value) when there are a large number
of calls and the network goes down with preservation turned on.

3.

Memory hold
-
up on TDM
-
IP gateways due to hung calls is an issue, but this is limited by
the number of voice ports. New calls wi
ll be rejected after all the voice ports are occupied
by hung calls, so memory hog is bounded by the number of voice ports on the gateway.

3.4

Usability Requirements


1.

Impact of VAD and possibility for hung calls should be clearly documented on CCO.

2.

When FW/N
AT is involved, RTP bindings may be lost when TCP is disconnected. The
preservation would not work in this case. This also has to be documented.

This is a major
problem, but the calls that need preservation in the Merril Lynch network do not traverse
a fir
ewall.

3.5

External Interface Requirements


The new ASN interface between CCM and GW to marks calls that do not need to be preserved is
given below
. This new field will be sent in an H.225.0 Notify

message.


Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

13

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

H323
-
UU
-
PDU ::= SEQUENCE

{



h323
-
message
-
body


CHOICE



{



setup


Setup
-
UUIE,




callProceeding


CallProceeding
-
UUIE,



connect


Connect
-
UUIE,



alerting



Alerting
-
UUIE,



information


Information
-
UUIE,



releaseComplete


ReleaseComplete
-
UUIE,




facility


Facility
-
UUIE,



...,



progress


Progress
-
UUIE,




empty


NULL
,




--

used when a FACILITY message is sent,




--

but the Facility
-
UUIE is not to be invoked





--

(possible when transportingsupplementary




--

services messages)





notify




Notify
-
UUIE



},



nonStandardData


NonStandardParameter OPTIONAL,




...,



h4501SupplementaryService


SEQUENCE OF OCTET STRING OPTIONAL,



--

each sequence of octet string is
defined as one




--

H4501SupplementaryService
APDU as defined in



--

Table 3/H.450.1




h245Tunneling


BOOLEAN,



--

if TRUE, tunneling of H.245
messages is enabled



h245Control





SEQUENCE OF OCTET STRING OPTIONAL,



--

each octet string may contain
exactly




--

one H.245 PDU



nonStandardControl


SEQUENCE OF NonStandardParameter OPTIONAL,



--

added for Annex M1



callLinkage


CallLinkage OP
TIONAL,



tunnelledSignallingMessage


TunnelledSignallingMessage OPTIONAL

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

14

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

}

Notify
-
UUIE :: SEQUENCE

{

protocolIdentifier ProtocolIdentifier,

callIdentifier

CallIdentifier,

tokens


SEQUENCE OF ClearToken OPTIONAL
,

cryptoTokens


SEQUENCE OF CryptoH323Token OPTIONAL,



}

H323
-
UU
-
NonStdInfo ::=


[6]SEQUENCE

{



version



INTEGER


OPTIONAL,



protoParam


ProtoParam


OPTIONAL,



commonParam



CommonParam


OPTIONAL,



...,



tieTrkParam


TieTrkParam


OPTIONAL,



progIndParam


ProgIndParam


OPTIONAL,



callMgrParam


CallMgrParam OPTIONAL,



c
allPreserveParam


CallPreserveParam OPTIONAL

}

CallPreserveParam ::= SEQUENCE

{



CallPreserveIE


BOOLEAN,



...

}

3.6

Architecture Baseline Requirements

The following architecture baselines are applicable
to the project de
scribed in the

PRD.


Baseline

Gap Analysis EDCS Number

QOS

NA

IPV6

NA

Multicast

NA

Manageability (CNEM)

NA

Voice Security

NA

H
igh Availability

NA

Security Functions

NA

802.1x

NA

MPLS

NA

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

15

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

3.7

Constraint Requirements

3.7.1

Compliance Requirements

3.7.2

Product Evo
lution Program, PEP

3.8

Quality Requirements

3.8.1

Security Requirements


3.9

Reliability/Availability Requirements

3.9.1

Reliability/Availability Budget


Table 3.1: Reliability/Availability Budget

Subsystem

MTBF (hr) /

Downtime (min/yr)

DPM

Availability (%)













Total




3.9.2

Reliability/Availability Model

4

Internal Specifications

Describe the product architectural design. Include:



Components (subsystems, modules etc.) of the product



Functions and performance of the components



Interfaces among the components



Major alg
orithms



Data structures



Project feasibility and implementation issues.

<body>

4.1

Overview

Provide a high level description of major hardware/software components and how the
product works.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

16

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

<body>

4.2

Major Components

Provide a description of the function and resp
onsibilities of each major
hardware/software component; required performance of the components; and overall
data and control flow

<body>

4.3

Major Data Structures

Describe External/internal databases, file formats, tables, and other data structures.
Also descr
ibes data links, important intermediate data storage, and implementation
considerations.

<body>

4.4

Major External Interfaces

Describe dependencies on other products, specific OS capabilities, configuration
dependencies, etc.

<body>

4.5

Major Internal Interfaces

D
escribe the data, control, and timing interfaces between the system components.

<body>

4.6

Software Memory Estimates

Estimate software memory requirements (code size, static data size, dynamic initialized
data, dynamic configured data, dynamic usage data, etc.
).

<body>

Table 4.1: Software Memory Estimates

S/W Feature

Baseline Estimate

Current Estimate










4.7

Hardware Memory Options

Describe base memory and options (flash, boot, DRAM, etc.).

<body>

Table 4.2: Hardware Memory Options

Memory

Min

Max




Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

17

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.







4.8

Performance

List performance characteristics of this feature. Note any performance limitations.

<body>

5

Issues, Risks and Dependencies

Mugello p
r
oject removed the pre
-
Mugello behavior
. An effort is under way to restore pre
-
Mugello behavioe.
This
featurette has a dependency on
that
effort
so that both the configuration
options can be
provided to the customer. The change is expected to be commited to 12.4
mainline


any delay on this can affect Spartacus.

5.1

Platform Requirements

Identify hardware/soft
ware requirements, third
-

party product dependencies,
environmental considerations, etc.


<<TL 9000: ADDITIONAL REQUIREMENT FOR TL 9000 COMPLIANCE>>


For products which run on proprietary operating systems (Unix, Windows etc) or which
use significant 3rd
party components (e.g. Oracle):



Identify versions supported (with specific version/release identifiers), to be
supported in future or for which support is planned to be withdrawn;



Provide details of utilities/tools required to support customers migrating f
rom
one version to another, including data migration;



For products which employ a client/server configuration, specify the above as
relevant for both client and server.


<body>

5.2

Related Projects

Identify projects on synchronous schedules which impact delive
ry of this product.

<body>

5.3

Third Party Relationships

Identify any issues related to third party disclosures, including marketing or press
releases, and any software licensing considerations for product incorporation and
distribution and product development
. Anticipate the expected form and use for the
third party software, as well as technical support needs.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

18

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.



For licensing guidelines and checklists, see
http://wwwin.cisco.com/legal/licensing/i
ndex.html


<body>

5.4

Single Source Components

Identify single source components/parts along with manufacturer.

<body>

5.5

Technology Requirements

Identify critical or new technology requirements such as board design methods, ASICs,
processors, software develop
ment tools, etc.

<body>

5.6

Technical Risks

Identify specific technical risks and unknowns which may impact product specification,
cost, implementation (e.g., integration with third
-
party software, performance of new
hardware, availability of target platforms,

etc.)

<body>

6

Appendix A
-

<Section title>

Cut and paste to add more appendices or delete if no appendices are required.

<body>

7

Requirements Traceability Considerations


<<TL 9000: ADDITIONAL REQUIREMENT FOR TL 9000 COMPLIANCE>>


Requirements traceabili
ty is required for TL 9000 registration. Traceability may be
performed manually, or with assistance of automated software tools. Provide unique
identifiers for all functional requirements and trace product requirements to functional
requirements consistent

with your organization’s strategy for requirements traceability.



If the project has a separate traceability matrix provide a link to that document.



If the requirements in the SFS are not of sufficient detail to support traceability to test
cases, you
may need to trace the product requirements to the more detailed functional
requirements specified in the HW or SW functional specifications. I
n
this
situation
,
describe the traceability approach.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

19

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


Refer to the Common
Requirements Traceability Handbook EDCS
-
400506

for a
thorough description of traceability and some examples of a manual implementation.

8

References



Spartacus PRD

-

EDCS
-
469839



Skate Merril Lync
h Midterm H323 Call Preservation




EDCS
-
472330




Bravo CCM Call Preservation Design Spec


EDCS
-
78053

9

Glossary

The following list
describes acronyms and definitions for terms used throughout this document:



<Term 1 in bold>
:
<
definition in plain text
>



<Term 2 in bold>
:
<
definition in plain text
>




10

Attachments

As appropriate, attach log sheets, diagrams, schematics, usability research,
examples of
forms, or other pieces of information used in or generated in the production of the
document.

<body>

10.1

Review Action Items


Attendees:

Debbie Sheridan

Kathy Lewis

Param

Rosa Lin

Man Loh

Jennifer Vogel

Paul Giralt


Comments:

1. CCM will also do a
quiet clear when it detects a socket error on the TCP connection with the
GW. This can be mentioned in the document.

2. References to 'phone' have to be clarified
-

use either "IP Phone' or 'pots phone'

3. ASN format for the new field to be added to the do
cument.

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

20

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.

4. Update the document with the results of discussions with Mugello team on media inactivity
detection.

5. Add the display details of the show commands in the document.

6. Add a mention of how the new ASN field is handled on IPIPGW.

7. An optimum r
ecommended value for media inactivity timer has to be arrived at.

8. Socket failure need not be reflected in disconnect cause code. New IECs can be added for
socket closure/error.

9. A configurable option is needed to make the media inactivity detection ap
plicable only to
preserved calls.

10. The solution will not work with FW/NAT on the path. But in ML network, call that are to be
preserved do not traverse the FW.


Email comments from Rosa Lin:


Hi, Faisal,


Attached is the preliminary draft of my CCM desi
gn spec, I am still working on it and
has not been reviewed by my group. However, it does contain some detail CCM
enhancement information (Section 1 and Section 6.1, 6.2); feel free to use it in your
SFS document where you think appropriate. As Man mention
ed in the conference call, we
are trying to make it as a stretch goal in CCM to preserve calls with TCP socket error
triggered from the H323 side. So your statement in the SFS regarding preserve calls
that encounter TCP failure connection between H323GW an
d CCM should be fine.





Besides that, I have some minor comments in the SFS:


1.

General comments: In the document we use phone a lot. But we do not distinguish IP
phone or POTS phone. Should we spell it out so that reader can better understand the
scena
rio that we are referring to? For example: in section 2.1, under the call flow:


Quote: This corresponds to a connection loss between the phone and the CCM. The call
will also be preserved…..


I think here you mean IP phone, not POTS/PSTN phone. But in th
e picture, the phone is
actually POTS phone I think.


2.

Section2, Functional Overview. Should we take out the IOS gateway between IP phone
and CCM? I think it will be easier for the reader to understand when you refer GW in
the document we mean H323 GW be
tween the PSTN phone and CCM, not IP phone and CCM.

3.

Section 3.1 Overview: ….He will also disable VAD, and turn off keepalives on
CCM…..


I think you would like to change it to H323 keepalives on CCM since there is also SCCP
keepalives in CCM that we don
’t want the user to turn off.


Thank you.





Rosa


Outstanding action items:


1.

Add the details of the show commands in the SFS


Faisal


Other offline review comments:

Date printed:
12/10/2013

Spartacus System Functional Specification: EDCS
-
469363

Copyright 2005 Cisco Systems

21

Company Confidential

A printed copy of this document is
considered uncontrolled. Refer to the online version for the controlled revision.


Rosa Lin:

Faisal,


During my implementation document review, one comment was raised ab
out turning off
H225TCPKA on CCM. Since we now have TCP failure detection to trigger quiet clear
implemented on CCM, we do not need the customer to turn off H225TCPKA to preserve the
call any more. The call will be preserved once the new service parameter,

H323 quiet
clear, is turn on in CCM and the corresponding configuration is turned on in IOS GW.


Can you modify section 3.1 in Spartacus SFS accordingly? Thank you.



Quote>


A user who wants to use this solution will enable the new service parameter on t
he
CCM. He will also turn off TCP keepalives for H.323 sockets on CCM.


End Quote>


Rosa


Kathy

Lewis
:

Kathy Lewis (12:11:49 PM): What happens when the WAN connection is restored (i.e.
flaps back "up" and the IOS GW TCP keep alive timer causes the the IOS

GW to send a
keep alive message to CCM for a call that CCM has already torn down through it's new
"quiet clearing"

process.

Faisal Siyavudeen (12:12:13 PM): CCM will send an RST on the connection....

Faisal Siyavudeen (12:12:49 PM): since the GW has no
t recvd a ReleaseComplete for the
call, it will tear down the socket, but will preserve the call.

Kathy Lewis (12:13:39 PM): ok
--

so the media portion of the call will continue . . .

Kathy Lewis (12:13:44 PM): that's good.

Faisal Siyavudeen (12:13:50 P
M): yes..

Kathy Lewis (12:14:12 PM): this specific scenario didn't seem clear to me in the SFS.

Faisal Siyavudeen (12:14:57 PM): I will add text that will clarify the message flow
for this...

Kathy Lewis (12:16:32 PM): It took me awhile to read / re
-
re
ad the e
-
mails + SFS to
figure out that the keep alive messages could come from the IP phone to CCM, as well
as from the IOS gateway to CCM. If there was a call flow diagram for this scenario
too, it would have helped me

:
-
)

Kathy Lewis (12:16:57 PM): Li
ke those on the top of page 5.

Faisal Siyavudeen (12:18:20 PM): did you mean a similar call flow for the RST case
too?

Faisal Siyavudeen (12:19:04 PM): keepalives from IP phone to CCM are application
level keepalives....

Faisal Siyavudeen (12:19:26 PM):

those GW to CCM are TCP keepalives...

Kathy Lewis (12:20:40 PM): I'm sure there are many different layers / dimensions to
these scenarios, but the Merrill Lynch document talks about specific keep alive
message processing that occurs during WAN flap condi
tions that causes calls to drop.

Kathy Lewis (12:21:27 PM): It makes sense to me to show call flow diagrams that
indicate how the new solution addresses each of these . .

.

Faisal Siyavudeen (12:22:50 PM): okay...i will create some call flow diagrams an
d add
them to SFS...though not this week..I am working on the design now...will next week be
fine?


End of Document