Beruflich Dokumente
Kultur Dokumente
NCS Protocol
IAD
NCS msgs
Local IP
Network
NCS msgs
V5.2
LE
ORCA RDT
PSTN
NCS
ORCA RDT gateway serves as the interface between the public switched telephone network, PSTN, and the
IP network.
V5.2 is the signaling protocol used for call setup and tear-down between the LE and the ORCA RDT gateway.
Network-based Call Signaling Protocol, NCS, is signaling protocol used between the ORCA RDT gateway
and IADs in the process of call setup and tear-down.
Endpoint Names
NCS:
For analog access lines endpoint names are:
Local_endpoint_name@domain_name
aaln/0@domain_name
aaln/1@domain_name
aaln/2@domain_name
Endpoint names on the gateway side:
MGCP:
<Slot#>/<port#>/<channel#>@gateway_name
port = span number
NCS
The NCS protocol assumes a connection model where the basic constructs are endpoints and connections.
Endpoint names are case sensitive.
For the most part the NCS protocol follows the MGCP model for endpoints. The major difference being in the
endpoint naming.
Endpoint names have two components.
The host name of the gateway managing the endpoint and a local endpoint name within that gateway, i.e.,
IAD name.
A host name may also be an IPv4 address in dotted decimal surrounded by a left and a right square
bracket. E.g. : [128.96.41.1]
With a DNS, DHCP and TFTP server in the network, the use of Fully Qualified Domain Names (FQDNs)
in place of numeric IP addresses to identify devices is supported.
The RDT-8 DNS shall support a maximum endpoint length of up to 128 characters.
<slot#>/<port#>/<channel#>@gateway_name
Slot03/d1/10@orca100.net
Residential
Area
IAD1
aaln/1@IAD1.tesla.net
IP Network
Et h e
r n e t
IAD2
7 x
8 x
9 x
1 0 x
1 1 x
1 2 x
7 x
8 x
9 x
1 0
x
1 1 x
1 2 x
1 x
2 x
3 x A
4 x
5 x
6 x
1 x
2 x
3 x B
4 x
5 x
6 x
C
7 8 9 1 0 1 1 2
1 2 3
4 5 6
aaln/1@IAD2.tesla.net
Domain
Name Server
aaln/2@IAD2. tesla.net
Local Exchange
IAD3
UPM4
.
.
.
V 5.2
Interface Bundle (2-16
DS1)
aaln/1@IAD3. tesla.net
LE
ORCA RDT
IAD4
PSTN
aaln/1@IAD4. tesla.net
NCS
Connections
3
When there is an incoming call, the RDT Control Module, CM3 card, instructs the endpoint on the RDT side
(channels on UPM4 cards) and IAD side to create a connection between endpoints and to detect certain
events, e.g., off-hook, fax tone etc, and generate certain signals, e.g., ringing. When the call is over, the
Control Module instructs the endpoints to delete connections. These instructions are sent to endpoints on the
IAD side through NCS messages and through MGCP messages to endpoints on the UPM4 side.
NCS
Endpoints
NCS assumes a connection model where the basic constructs are end points and connections. End
points which are sources of data can be either physical or virtual.
Physical - A physical end point is a hardware port that can receive or send data.
Virtual - A Virtual end point is software generated data.
Connections
Connections can be either point to point or point to multi point. A connection exists where there is the
ability to transmit data from one point to another within the same gateway or to another gateway.
Command messages:
Audit Endpoint, AUEP Sent to find out the status of a given endpoint.
Create Connection, CRCX - Instructs the gateway to create a connection from the specified end point to another
end point.
Modify connection, MDCX - to modify an existing connection parameter to the specified changes.
Delete Connection, DLCX - to delete a specified connection.
Notification Request, RQNT to request notification of specified events.
Notify, NTFY to notify that an event was observed. When a requested event is observed, a NTFY containing
this observed event is sent.
Restart in Progress, RSIP to indicate that an endpoint is either being taken out-of-service or being brought back
in-service.
MGCP Command:
CRCX 028061389 slot3/d1/10@orca100.net MGCP 1.0
NCS
NCS
Endpoint_name is the identifier for the endpoint(s) in the gateway where NotificationRequest executes. The
Endpoint_name must follow the rules for endpoints names explained earlier.
RequestIdentifier is used to correlate this request with the notification it may trigger. It will be repeated in the
corresponding Notify command.
RequestedEvents is a list of events that the gateway is requested to detect on the endpoint. Examples of
events are:
fax tones,
modem tones,
on-hook transition (occurring in classic telephone sets when the user hangs up the handset), off-hook
transition (occurring in classic telephone sets when the user lifts the handset),
flash hook (occurring in classic telephone sets when the user briefly presses the hook that holds the
handset),
SignalRequests is a parameter that contains the set of signals that the gateway is asked to apply. Unless
otherwise specified, signals are applied to the endpoint, however some signals can be applied to a
connection. The following are examples of signals:
Ringing,
Busy tone,
Notify Command
NTFY Transaction_ID Endpoint_name MGCP# NCS#
[X: Request Identifier]
[O: Observed Events]
NCS
Notifications are sent via the Notify command by the gateway when an observed event is to be notified.
RequestIdentifier is a parameter that repeats the RequestIdentifier parameter of the NotificationRequest that
triggered this notification. It is used to correlate this notification with the notification request that triggered it.
Persistent events will be viewed here as if they had been included in the last NotificationRequest. When no
NotificationRequest has been received, the RequestIdentifier used will be zero (0).
ObservedEvents is a list of events that the gateway detected. A single notification can report a list of events
that will be reported in the order in which they were detected. The list can only contain persistent events and
events that were requested in the RequestedEvents parameter of the triggering NotificationRequest.
Create Connection
CRCX Transaction_ID Endpoint_name MGCP# NCS#
[C: Call Id]
[L: Local Connection Options]
Packetization Period, Vocoder, Silence suppression, Echo cancellation
CallId is a parameter that identifies the call (or session) to which this connection belongs. This parameter is,
at a minimum, unique within the collection of Call Agents that control the same gateways; connections that
belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and
accounting purposes.
LocalConnectionOptions is a structure that describes the characteristics of the media data connection
Vocoder rate - compression algorithm used to send and receive media on the connection.
Echo Cancellation - can have the value on (when the echo cancellation is requested) or off (when it is
turned off).
v= protocol version
o= owner/creator and session identifier
s= session name
c= connection information
a= zero or more session attribute lines
Time description
t= time the session is active
Media description
m= media name and transport address
a= zero or more media attribute lines
NCS
An SDP session description consists of a number of lines of text of the form <type>=<value>. <type> is
always exactly one character and is case-significant. <value> is a structured text string whose format depends
on <type>.
Time fields specify the start and stop times for a session.
NCS
10
10
NCS
11
Attributes
11
Modify Connection
MDCX Transaction_ID Endpoint_name MGCP# NCS#
[C: Call Id]
[L: Local Connection Options]
Packetization Period, Vocoder, Silence suppression, Echo cancellation
12
CallId is a parameter that identifies the call (or session) to which this connection belongs. This parameter is,
at a minimum, unique within the collection of Call Agents that control the same gateways; connections that
belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and
accounting purposes.
LocalConnectionOptions is a structure that describes the characteristics of the media data connection
Vocoder rate - compression algorithm used to send and receive media on the connection.
Echo Cancellation - can have the value on (when the echo cancellation is requested) or off (when it is
turned off).
12
Restart in Progress
RSIP Transaction_ID Endpoint_name MGCP# NCS#
[RM: Restart Method]
[RD: Restart Delay]
NCS
13
This command is used by the gateway to signal that an endpoint is taken in or out of service.
RestartDelay is expressed in seconds. If the number is not present the delay value is null.
The RestartMethod parameter specifies the type of restart. The following restart methods are supported:
Forced indicates that the specified endpoints are taken abruptly out of service and the established
connections are lost.
Restart indicates that service will be restored on the endpoints after the specified restart delay. A
restart delay of null for the restart method indicates that service has been already restored. This will
typically occur after gateway startup/reboot.
Disconnected
indicates that the endpoint has become disconnected and is now trying to establish
connectivity.
13
NCS
14
This command is used to terminate a connection and it collects statistics on the execution of the connection.
The NotifiedEntity, RequestedEvents, RequestIdentifier, SignalRequests, QuarantineHandling, and
DetectEvents parameters are optional. They can be used by the MGC to transmit a notification request that is
tied to and executed simultaneously with the deletion of the connection. However, if one or more of these
parameters are present, RequestIdentifier MUST be one of them.
14
NCS
15
This command is used to terminate a connection and it collects statistics on the execution of the connection.
The Reason-code is a text string starting with a numeric reason-code and optionally followed by a descriptive
text string. Reason-codes are used by the gateway when deleting a connection to inform the MGC about the
reason for deleting the connection. The reason code is an integer number, and the following values have been
defined:
000 Endpoint state is nominal. (This code is used only in response to audit requests.)
902 Loss of lower layer connectivity (e.g., downstream sync) i.e., T1 or E1 is down or is experiencing red
alarms. Usually 902 is seen in the RSIP message when there is no connection associated with the
endpoint reporting RSIP. If the endpoints have existing connections, and are experiencing a RED alarm,
then DLCX will be used, and followed by RSIP.
15
Audit Endpoint
AUEP Transaction_ID Endpoint_name MGCP# NCS#
[F:RequestedInfo]
NCS
16
The AuditEndPoint, AUEP, command can be used by the Call Agent to find out the status of a given endpoint.
RequestedInfo describes the information that is requested for the specified endpoint. Several endpointspecific information can then be audited with this command. Nuera RDT uses it to audit ConnectionIdentifiers.
ConnectionIdentifiers - A comma-separated list of ConnectionIdentifiers for all connections that currently
exist for the specified endpoint.
AUEP (F:I)
A problem has been identified interoperating with certain IADs. The issue arises if the RDT loses
communication with the endpoint while a call is active. This can happen either through an IP fault or through a
power-cycle of the RDT.
The problem is that the IAD has a connection that the RDT does not know about. When a new connection is
attempted we need to remove the old one. Most IADs will reject a second connection to an endpoint, in which
case the RDT will send a DLCX to remove the first connection and then retry with the new connection.
However, some IADs will not reject a second connection, they will actually add it to the existing connection. In
this case the result is multiple RTP streams, causing distortion on the audio path.
The solution is to send an AUEP to each endpoint when bringing it online asking about active connections. If
there are any, then a DLCX is sent to clear out the existing connection before bringing the endpoint into
service.
16
Response Messages
NCS
17
401 Already off hook - Sent in response to a CRCX command. Indicates that the SSC and gateway are
not synchronized for this endpoint.
402 Already on hook Sent in response to a DLCX command. Indicates that the SSC and gateway are
not synchronized for this endpoint.
500 Unknown endpoint The transaction could not be executed because the endpoint is unknown.
501 Endpoint not ready - The transaction could not be executed because the endpoint is not ready.
510 Protocol error - The transaction could not be executed because a protocol error was detected.
512 Not equipped to detect - The transaction could not be executed because the gateway is not equipped
to detect one of the requested events.
513 Not equipped to signal - The transaction could not be executed because the gateway is not equipped
to generate one of the requested signals.
520 Endpoint restricting - The transaction could not be executed because the endpoint is in the process of
restarting.
17
200 040100009 OK
250 021440047 OK
NCS
18
18
v=0
o= = - 14 0 IN IP4 192.168.125.3
s=b=
t=
a=sendrecv
IN IP4 192.168.59.22
m=audio 7002 RTP/AVP 0
a=ptime:10
NCS
19
200 OK response is used to acknowledge any command other than Delete connections. If 200 OK acknowledges Create
connection it contains Local Connection Descriptor information specified in RFC2327:
Origin (o=)
s= <session-name>
Bandwidth - specifies the proposed bandwidth to be used by the session or media, and is optional
b=<modifier>:<bandwidth-value>
modifier> is a single alphanumeric word giving the meaning of the bandwidth figure.
Times, Repeat Times and Time Zones - specify the start and stop times for a conference session.
t=<start time> <stop time>
If the stop-time is set to zero, then the session is not bounded, though it will not become active until after the
start-time. If the start-time is also zero, the session is regarded as permanent.
Attributes (a=) - one or more of the a attribute lines may be included. They describe the media stream.
a= <attribute> : <value>
a= ptime:10
gives the length of time in milliseconds represented by the media in a packet.
19
Piggybacking
200 2005 OK
.
DLCX 1244 ds/ds1-2/2@tgw.whatever.net MGCP 1.0 TGCP
1.0
C: A3C47F21456789F0
I: FDE234C8
NCS
20
There are cases when an MGC will want to send several messages at the same time to one or more
endpoints in a gateway and vice versa. When several messages have to be sent in the same UDP packets,
they are separated by a line of text that contain a single dot, as in the following example:
200 2005 OK
.
DLCX 1244 ds/ds1-2/2@tgw.whatever.net MGCP 1.0 TGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
20
250 OK
250 Transaction_ID OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
PS, Packets sent - number of packets that were sent on the
connection.
OS, Octets sent - number of octets that were sent on the connection.
PR, Packets received - number of packets that were received on the
connection.
OR, Octets received - number of octets that were received on the
connection.
PL, Packets lost - number of packets that were not received on the
connection, as deduced from gaps in the sequence number.
JI, Jitter - average inter-packet arrival jitter, in milliseconds, expressed
as an integer number.
LA, Latency - average latency, in milliseconds, expressed as an
integer number.
NCS
21
Response to the Delete connection command is 250 OK and it contains statistics for the connection.
21
IAD
RDT UPM
LE
Remote SDP1
200 OK
BCC: Allocation Complete (V 5.2)
NCS
22
IAD goes off hook towards the cable modem. The cable modem generates an NCS Notify message towards the RDT containing the
observed event and on which endpoint the event occurred.
RDT CM sends the PSTN: Establish message indicating an originating path request. RDT informs LE of off-hook condition.
The RDT responds with a 200 OK to the previous NTFY.
RDT CM requests IAD to notify it when either an on-hook or hook-flash is detected.
IAD acknowledges the RQNT.
The LE responds with a PSTN: Establish Ack message to the previous Establish message, indicating that the requested action was
performed.
The LE sends a BCC: Allocation message. The Allocation message is sent by the LE to request the RDT to allocate a bearer (voice)
channels ( V5.2 timeslots or E1 channels within theV5.2 interface) to a user port for a call. The LE always controls allocation and deallocation of bearer channels. The LE is responsible for correlating between the subscriber DN used by the outside world and the V5.2
user port ID used within the access network.
The RDT CM instructs the IAD to create connection, Mode: sendreceive. IP addresses are statically allocated to E1 channels at the RDT.
Therefore, the host implicitly knows the IP address associated with E1 channel allocated by the LE and may provide this IP address in the
CRCX to the IAD. This obviates the need for a subsequent MDCX.
The IAD acknowledges the CRCX command.
An internal Create connection message is sent to the UPM to set up the appropriate V 5.2 parameters.
The UPM acknowledges the CRCX command.
A V 5.2 BCC: Allocation Complete message will be generated back towards the LE once the 200 OK messages from the UPM have
been received at the CM module. This message serves as an acknowledgement that the allocation of requested bearer channels was
successful.
At this time the LE sends the in band dial tone to the IAD.
At this time, the audio path is open to receive dialed digits from the end user.
Dialed digits will be passed in-band from the IAD to the LE.
Ring back will be passed in-band from the LE to the end user. Ringback tone is generated by terminating office and will be stopped when
call is answered. No indication of answer is necessary since the LE handles billing. No more signaling required until call clearing. Note:
Receipt of ringback tone may be delayed if LE waits for inter-digit time-out before continuing call setup.
At this point a full duplex voice path exists from end to end.
22
IAD
RDT UPM
LE
On Hook
Notify: O:hu (NCS)
PSTN: Signal; (V 5.2)
200 OK (NCS)
DLCX (NCS)
DLCX (NCS)
250 OK (NCS)
250 OK
NCS
23
23
IAD
RDT UPM
LE
NCS
24
24
O: L/hd
[16:25:50.631]<---200 57 OK
[16:25:50.631]<---RQNT 81921029 aaln/1@[192.168.25.191] MGCP 1.0 NCS 1.0
X: 81921029
R: hu,hf
[16:25:50.661]<---200 81921029
OK
OK
I: 17
v=0
o=InnoMedia_MGCP 3002 100 IN IP4 192.168.25.191
s= c=IN IP4 192.168.25.191
b=AS:107
t=0 0
m=audio 6024 RTP/AVP 8
a=ptime:10
25
X: 81921030
O: L/hu
[16:26:04.371]<---200 58 OK
[16:26:04.371]<---RQNT 81921032 aaln/1@[192.168.25.191] MGCP 1.0 NCS 1.0
X: 81921032
R: hd
[16:26:04.401]<---200 81921032
OK
26
Conn Deleted
OK
27
IAD1
(sdp1)
RDT CM
RDT UPM
(sdp3)
RDT UPM
(sdp4)
LE
200 OK (NCS)
CRCX: sdp2
200 OK
BCC: Allocation complete (V5.2)
Dial Tone (in band)
Dialed Digits (in band)
28
IAD1
(sdp1)
On Hook
RDT CM
RDT UPM
(sdp3)
RDT UPM
(sdp4)
LE
DLCX (NCS)
250 OK (NCS)
250 OK
200 OK (NCS)
29
RDT CM
RDT UPM
LE
RQNT(r:hd)
200 OK
NTFY (O:hd)
ESTABLISH
200 OK
RQNT: R:hu,hf
200 OK
ESTABLISH ACK
ALLOCATE(DS0)
CRCX PCMA
200 OK (remote SDP)
ALLOC ACK
200 OK
200 OK
200 OK
Full duplex modem call established
NTFY(O:hu)
200 OK
DLCX
Signal (ss:hu)
DLCX
DISCONNECT
250 OK
250 OK
DISCONNECT COMPLETE
NCS
30
Messages exchanged between the RDT CM card, UPM, Class 5 switch, and IAD, when there is an incoming
call, are the same as in the first call flow diagram in this chapter for a voice call until the moment a modem
tone is detected.
After the UPM has detected a modem tone, it sends a NTFY message to the CM card indicating that the
observed event is mt, modem tone.
The CM card acknowledges it and instructs the UPM card and the IAD to modify connection and to turn
silence suppression and echo cancellation off, MDCX: s:off, e:off.
30
O: L/hd
[16:29:23.667]<---200 61 OK
[16:29:23.667]<---RQNT 81921043 aaln/1@[192.168.25.191] MGCP 1.0 NCS 1.0
X: 81921043
R: hu,hf
[16:29:23.697]<---200 81921043
OK
OK
I: 19
v=0
o=InnoMedia_MGCP 3002 100 IN IP4 192.168.25.191
s= c=IN IP4 192.168.25.191
b=AS:107
t=0 0
m=audio 6024 RTP/AVP 8
a=ptime:10
31
32
OK
33
RDT CM
RDT UPM
LE
Remote SDP1
200 OK
BCC: Allocation Complete (V 5.2)
200 OK
MDCX:s:off,e:off, PCMa
200 OK
200 OK
NCS
34
IAD goes off hook towards the cable modem. The cable modem generates an NCS Notify message towards the RDT containing the
observed event and on which endpoint the event occurred.
RDT CM sends the PSTN: Establish message indicating an originating path request. RDT informs LE of off-hook condition.
The RDT responds with a 200 OK to the previous NTFY.
RDT CM requests IAD to notify it when either an on-hook or hook-flash is detected.
IAD acknowledges the RQNT.
The LE responds with a PSTN: Establich Ack message to the previous Establish message, indicating that the requested action was
performed.
The LE sends a BCC: Allocation message. The Allocation message is sent by the LE to request the RDT to allocate a bearer (voice)
channels ( V5.2 timeslots or E1 channels within theV5.2 interface) to a user port for a call. The LE always controls allocation and deallocation of bearer channels. The LE is responsible for correlating between the subscriber DN used by the outside world and the V5.2
user port ID used within the access network.
The RDT CM instructs the IAD to create connection, Mode: sendreceive, vocoder rate for voice is set to G.726, 32kbps. IP addresses are
statically allocated to E1 channels at the RDT. Therefore, the host implicitly knows the IP address associated with E1 channel allocated by
the LE and may provide this IP address in the CRCX to the IAD. Since we want to upspeed modem rate to 64 kbs, a MDCX command is
needed.
The IAD acknowledges the CRCX command.
An internal Create connection message is sent to the UPM.
The UPM acknowledges the CRCX command.
A V 5.2 BCC: Allocation Complete message will be generated back towards the LE once the 200 OK messages from the UPM have
been received at the CM module. This message serves as an acknowledgement that the allocation of requested bearer channels was
successful.
At this time the LE sends the in band dial tone to the IAD.
At this time, the audio path is open to receive dialed digits from the end user.
Dialed digits will be passed in-band from the IAD to the LE.
Modem tone sent by both sides.
When Modem tones are detected a MDCX is sent from the RDT CM to IAD and to UPM to turn off echo canceller and VAD and to change
data rate to PCMa.
At this point a full duplex call is established from end to end.
34
RDT CM
RDT UPM
LE
RQNT(r:hd)
200 OK
NTFY (O:hd)
ESTABLISH
200 OK
RQNT: R:hu,hf
200 OK
ESTABLISH ACK
CRCX G726
200 OK (remote SDP)
ALLOCATE(DS0)
CRCX(remote SDP, R:mt,ft)
200 OK
ALLOC ACK
200 OK
200 OK
DSA RES
DSA ACK
5xx Response
MDCX(G726,s:off,e:off)
200 OK
MDCX
200 OK
NCS
35
Messages exchanged between the RDT CM card, UPM, Class 5 switch, and IAD when there is an incoming
call are the same as in the previous call flow diagram until the moment the MDCX command is sent.
The CM card instructs the UPM card and the IAD to modify connection and to turn silence suppression and
echo cancellation off and to change the bandwidth to PCM, MDCX: PCMA, s:off, e:off.
If the IAD, for some reason, is not able to do the requested upspeed, it may respond with a 5xx message, or it
may respond with the 200 OK, and only later send a 5xx response. The response depends on the IAD.
Various IADs behave differently.
When the RDT CM card receives the 5xx response it sends a new MDCX command to the IAD and UPM
instructing them to use G.726 vocoder and turn silence suppression and echo cancellation off, MDCX: G726,
s:off, e:off.
35
IAD
RDT UPM
LE
ALLOCATE(DS0)
CRCX PCMA
DSA REQ
DSA RES
DSA ACK
200 OK (remote SDP)
RQNT(R:hd,oc; S:rs)
Establish ACK
200 OK
Initial Ring timer
expires
Signal (Pulse Notif.)
Caller ID inband
RQNT(R:hd; S:r0)
Signal(cadence ring)
200 OK
Signal Ack
NTFY (o:hd)
200 OK
Signal (loop closed)
Signal Ack
RQNT (R:hu,hf)
200 OK
Voice Conversation
NCS
36
The Class 5 switch sends an Allocate message with the channel number for the incoming call .
RDT CM sends Create connection to the IAD and it responds with 200 OK which contains sdp information about the IAD endpoint.
The RDT CM sends Create connection to its voice card which corresponds to the voice channel allocated by the LE. The UPM card
acknowledges the Create connection command with 200 OK.
RDT CM acknowledges the BCC Allocation message with Allocation Ack.
The Class 5 switch sends the PSTN Establish message for a pulsed signal of type initial ring and a request to inform the switch when the
pulse has finished. This initial ring is a wake up signal to any attached caller ID equipment. The RDT CM acknowledges this message
with Establish Ack.
The RDT CM card sends Request notification requesting IAD to notify event hang down and to send the initial ringing signal to the user.
The IAD acknowledges the previous RQNT command.
Under standard NCS there is no provision for notification from IAD of when the initial ring has completed. To overcome this, the RDT
starts a configurable timer when it receives the pulse signal request and sends the acknowledgement back to the switch when the timer
expires, i.e., it sends PSTN Signal message with Pulse Notification information element.
The Class 5 switch sends Caller ID in-band, i.e., from the RTD UPM card to IAD the caller ID information is sent through RTP packets.
The Class 5 switch sends the PSTN Signal command which contains the ringing cadence.
The RDT CM card sends Request notification requesting IAD to notify hang down and to send the ringing cadence to the user.
The IAD acknowledges the previous RQNT command.
The RDT CM acknowledges the previous Signal message with Signal Ack.
The IAD notifies the RDT CM that it observed hang-down event (the user went off-hook), and the RDT CM acknowledges it.
The RDT CM card sends PSTN Signal message to the LE with the Line-Information information element indicating that the loop is closed.
The LE acknowledges it with Signal Ack.
The RDT CM card sends Request notification requesting IAD to notify hang up or hook flash. The IAD acknowledges it with 200 OK and
the conversation starts.
36
RDT CM
RDT UPM
LE
ALLOCATE(DS0)
CRCX PCMA
RQNT(R:hd,oc; S:ir)
200 OK
NTFY(O:oc)
Pulse Notif.
Signal(cadence ring)
200 OK
NCS
37
Some IADs (e.g. Motorola CG4500) will support the NTFY(O:oc) message when the initial ring has
completed. In this situation the RDT will cancel the timer and send the pulse notification back to the LE.
O:oc means Observed event is operation complete.
37
IAD
RDT UPM
LE
ALLOCATE(DS0)
CRCX PCMA
RQNT(R:hd,oc; S:rs)
Establish ACK
200 OK
Initial Ring timer
expires
Signal (Pulse Notif.)
Caller ID inband
MDCX(G729A R:hd; S:r0)
Signal(cadence ring)
200 OK
Signal Ack
NTFY (o:hd)
200 OK
Signal (loop closed)
Signal Ack
RQNT (R:hu,hf)
200 OK
NCS
38
The call flow diagram in the slide shows the call flow for an incoming call with caller ID downspeed enabled.
The call is initially created at G711. When the cadence ring has been received from the LE the RDT knows
that the caller ID sequence has finished and changes the call to G729A. An MDCX is sent to the IAD
requesting a vocoder change. When the UPM senses that the incoming packet stream from the IAD has
changed it will change its vocoder for transmission accordingly.
There is no need to modify the connection parameters on the UPM as it will switch to a vocoder depending on
the incoming packet type.
38
Call Waiting
Call Originated by IAD
I
A
D
1. RQNT:
R:hd (NCS)
R
D
T
U
P
M
R
D
T
C
M
2. 200 OK
Off
Hook
3. Notify:
O:hd (NCS)
5. 200
OK
6. RQNT:
(NCS)
R:hu, hf (NCS)
7. 200
OK
(NCS)
L
E
12. CRCX:
Remote SDP1
1
3
.
14. BCC:
2 Allocation complete
(V5.2)0
0
15. Dial Tone (in band)
O
K
16. Dialed Digits (in band)
17. Ring back (in band)
20. Notify:
O:hf (NCS)
23. 200
OK
(NCS)
39
For call waiting feature doesnt matter whether the call is originated by the IAD or switch.
The call flow up to step 19 is the same as in the call originated by IAD in the first call flow diagram.
19. After the two-way media path is established the switch detects another call for IAD user and since the
user has call waiting, the switch injects the call waiting PIP tone in the existing media path to alert the IAD
user.
20. The IAD user presses FLASH to accept the new call and the IAD sends NTFY O: hf (observed event is
hook flash) to the RDT CM. The RDT CM acknowledges the NTFY command with 23. 200 OK.
21. The RDT CM sends V5.2 command Establish (Pulsed Signal Register recall) indicating to the LE side
that a hook flash tone was observed on the IAD side.
22. The LE acknowledges the previous Establish command.
24. LE puts the the first connection on hold, answers the new call and connects it to the IAD using the existing
media path.
25. The IAD user presses FLASH button to return to the first call and the IAD sends NTFY O: hf (observed
event is hook flash) to the RDT CM. The RDT CM acknowledges the NTFY command with 28. 200 OK and
sends the Establish (Pulsed Signal Register recall) to the LE, and the user is connected to the first call. The
LE puts the second connection on hold.
If the first called party hangs up, the LE detects it and does nothing the media path is still up but silent. The
IAD user presses FLASH to go back to the other party and scenario in step 20 and 25 will be repeated.
If the second called party (the party on hold) hangs up first (after step 28), the media path is unaffected by the
LE. It is used by the first call which is connected. If the IAD user flashes later, there will be no party left to reconnect and the IAD user shall receive dial tone form the switch.
40
IAD
RDT UPM
LE
5. PSTN: Establish(V5.2)
6. PSTN: Establish (V5.2)
Glare detected by RDT CM. The incoming call proceeds normally, the outgoing Establish msg is discarded.
7. PSTN: Establish Ack (V5.2)
8. BCC: Allocation (channel #, link ID)
9. CRCX: SDP2 (NCS), mode=sendrecv
10. 200 OK SDP1 (NCS)
NCS
41
5. After sending 200 OK as a response to the NTFY coming from the IAD, the RDT CM sends the V5.2 PSTN:
Establish message, requesting service.
6. The switch sends its own PSTN: Establish message to the RDT CM which causes glare.
When glare is detected by the RDT CM, the PSTN: Establish message coming from the LE has priority and
the PSTN: Establish message from the RDT CM is discarded.
The call setup proceeds with the LE allocating resources for the call.
41
IAD
RDT
CM
RDT
UPM
LE
LE allocates a
conference
bridge and ties
all parties
together in a
three-way call
42
IAD
RDT UPM
LE
On Hook
18. Notify: O:hu (NCS)
20. 200 OK (NCS)
43
Subscriber Added
IAD
RDT CM
DNS
LE
DNS Query
RDT
CM
IAD
AUEP (F:I)
200 OK (I:xxx,yyy)
DLCX
250 OK (I:xxx,yyy)
200 OK (NCS)
200 OK (NCS)
.
NCS
44
First time when we add a subscriber to the RDT list of subscribers, or we turn the RDT on, or for some reason the
communication between the subscriber and RDT fails, the following three alarms will exist:
DNS alarm
Communication failure
Blocked by switch
The alarms are ordered from the highest severity to the lowest. Initially all three alarms are present but the highest severity
alarm is displayed only for a short time in the Alarm dialog, and as the conditions for the alarms existence are not present,
the alarm will clear and the next alarm will be displayed. As the conditions for this alarm are not there, it will clear from the
Alarm dialog, and the third alarm in the list above will be displayed, and if everything functions properly, it will clear.
When a subscriber is added, the RDT CM sends a DNS query to the DNS server. If the query fails, DNS Error alarm is
displayed in the Alarm dialog.
If the query is successful, the previous alarm clears very quickly and the RDT CM sends an AUEP command to the IAD. If
for any reason the command times out Communication Failure alarm is displayed.
If the IAD acknowledges the AUEP command (either there are existing connections or not) with 200 OK or 250 OK, the
previous alarm clears quickly and the RDT sends an Unblock subscriber command to the switch, LE. If the Unblock
command times out, Blocked by switch alarm is displayed.
If everything is OK in the communication between the RDT and LE, the LE responds with the Unblock Ack command.
The LE then sends an Unblock command to the RDT and RDT responds with Unblock Ack.
The RDT CM sends an RQNT (R:hd) command requesting the IAD to report when the endpoint observes that the user went
off-hook. The rest of the diagram is like previously explained call flow diagrams and depends on which side is placing the
call, IAD or LE.
* If there are connections on the endpoint, the endpoint responds to the AEUP (F:I) command with 200 OK and the list of
connections IDs. The RDT sends a DLCX command to the IAD instructing it to delete all active connections, and the IAD
responds with 250 OK. The subscriber is now in an operational, but blocked by switch, state.
44
RDT CM
Unblock
No response
RDT CM
Unblock
Unblock Ack
Block
Block Ack
NCS
...
45
If the subscriber is not added to the LE list, the Unblock command coming from the RDT CM is ignored, there
is no response and the Subscriber blocked by switch alarm is displayed in the Alarm dialog.
If the subscriber is added to the LE list, but not enabled in the switch, the Unblock command from RDT CM is
responded to, but later the switch sends a Block message to the RDT.
45
Polling
IAD10
IAD3
IAD2
IAD1
...
1a. RQNT
5 minutes
IAD11
2a. RQNT
1b. OK
2b. OK
...
5 minutes
mi
15
tes
nu
E1
LE
IAD20
IAD21
...
IAD30
NCS
46
The RDT polls the IADs by sending RQNT messages to which the IADs respond with 200 OK, if they are up
and running. The IADs are grouped into groups of up to 10 IADs for polling . Each group is polled every 15
minutes.
The groups are spread evenly over the 15 minute period. E.g. 5 IADs will be polled as a group of 5 each 15
minutes. 30 IADs will be grouped into 3 groups of 10 IADs and polled, with a group being polled every 5
minutes. This ensures that the polling NCS load is evenly spread and we don't get any peaks.
46
Polling No Response
1. RQNT
E1
LE
IAD1
500 ms
DNS
2. RQNT
E1
LE
IAD1
...
DNS
IAD1
10. RQNT
E1
LE
NCS
47
Lets assume that the IAD is operational. It is polled every 15 minutes by the RDT. If, for some reason, the
RQNT polling message sent to the IAD is not responded to, the RDT keeps sending the RQNT to IADs every
500ms for 10 resends. After the 10th attempt the IAD is determined to be in a fault state and a Subscriber
communication failure" alarm is raised.
When the IAD is considered unreachable the RDT sends a BLOCK message to the switch to block that port.
In the next step the RDT does a DNS lookup in case the IP address has changed. When the response comes
back the RDT tries the poll again. If the RDT still receives no response, 2 minutes later it will try the DNS/poll
sequence again. If the RDT receives an RSIP in the meantime, then the fault state will be cleared.
If the RDT doesn't get a DNS response, it raises a " Subscriber DNS Error" alarm and keeps sending a
DNS/poll to the IAD every 2 minutes until it recovers.
Note the same procedure of retransmitting the NCS messages is applied if any of the NCS messages from
the RDT are not responded to by the IADs.
47
2. 200 OK
IP
4. 200 OK (I:xx)
3. AUEP (F:I)
RDT
2. IAD is in a call
2. 200 OK (I:yy)
IP
1. AEUP (F:I)
IAD
RDT
RQNT
3. IAD is idle
2. 200 OK
IP
IAD
NCS
RDT
48
RQNT
The IADs are polled by the RDT gateway with the RQNT command when the IADs are idle, as illustrated
in the previous slide.
AUEP
The first time when the IADs are connected to the network, the RDT will send to them the AUEP
command requesting the information on the existing connections.
The AUEP command is used to poll IADs when they are busy in a call.
48