한국어

네트워킹

온누리070 플레이스토어 다운로드
    acrobits softphone
     온누리 070 카카오 프러스 친구추가온누리 070 카카오 프러스 친구추가친추
     카카오톡 채팅 상담 카카오톡 채팅 상담카톡
    
     라인상담
     라인으로 공유

     페북공유

   ◎위챗 : speedseoul


  
     PAYPAL
     
     PRICE
     

pixel.gif

    before pay call 0088 from app


http://www.protocols.com/pbook/ss7.htm

 

 

SS7 Protocol Suite

 
This page describes the following SS7 protocols:
   
BICC Bearer Independent Call Control protoco
BISUP B-ISDN User Part
DUP Data User Part
ISUP ISDN User Part
MAP Mobile Application Part
MTP-2 Message Transfer Part Level 2
MTP-3 Message Transfer Part Level 3
Q2140 Recommendation Q.2140
SCCP Signalling Connection Control Part
TCAP Transaction Capabilities Application Part
TUP Telephone User Part

For information on SS7 and other telecom protocol testing
 

View this file in pdf format.

CCITT developed the Signalling System 7 (SS7) specification. SS7 is a common channel signalling system. This means that one channel is used only for sending the signalling information, whether the system has one bearer channel or multiple bearer channels. The hardware and software functions of the SS7 protocol are divided into layers which loosely correspond to the OSI 7 layer model.

See the Performance Technologies SS7 Tutorial for more information on the SS7 standard.

 

The SS7 protocol suite is illustrated here in relation to the OSI model:
Click the protocols on the map to see more details.

 

BICC

ITU-T Q.1901

Bearer Independent Call Control protocol is a call control protocol used between serving nodes. This protocol is based on the ISUP protocol, and was adapted to support the ISDN services independent of the bearer technology and signalling message transport technology used.
The format of the BICC packet is shown in the following illustration:

8
7
6
5
4
3
2
1
Octet
CIC
LSB
1
CIC
2
CIC
3
MSB
CIC
4
Message Type
5
BICC packet structure
 

Routing Label
The label contained in a signalling message, and used by the relevant user part to identify particulars to which the message refers. It is also used by the Message Transfer Part to route the message towards its destination point.

Call Instance Code (CIC)
The allocation of call instance codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules.

Message Type Code
The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN User Part message. Each message consists of a number of parameters. Message types may be:

6
9
44
24
26
23
41
25
27
7
5
47
32
33
31
8
1
12
16
18
14
2
13
45
Address complete.
Answer.
Call progress.
Circuit group blocking.
Circuit group blocking acknowledgement.
Circuit group reset.
Circuit group reset acknowledgement.
Circuit group unblocking.
Circuit group unblocking acknowledgement.
Connect.
Continuity.
Confusion
Facility accepted.
Facility reject.
Facility request.
Forward transfer.
Initial address.
Release.
Release complete.
Reset circuit.
Resume.
Subsequent address.
Suspend.
User-to-user information.

Parameters
Each parameter has a name which is coded as a single octet. The length of a parameter may be fixed or variable, and a length indicator for each parameter may be included.

Interested in more details about testing this protocol?

 

BISUP

Recommendation Q.2763 (02/95).
http://www.itu.int/ITU-T/.

The B-ISDN User Part (B-ISUP) is applicable to international B-ISDN networks. In addition, the B-ISDN User Part is suitable for national applications. Most messages and parameters specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized operating agencies to introduce network specific signalling messages and parameters within the internationally standardized protocol structure.
B-ISDN user part messages are carried on the ATM signalling link by means of S-AAL service data units, the format of which is described in 6.2/Q.2110.
As a national option B-ISDN user part messages can be carried on the STM signalling link by means of signal units, the format of which is described in 2.2/Q.703.
The format of, and the codes used in the service information octet are described in 14.2/Q.704. The service indicator for the B-ISDN user part is coded 1001.
The signalling information field of each message signal unit containing an B-ISDN user part message consists of an integral number of octets and encompasses the following parts:

a)  routing label;
b)  message type code;
c)  message length;
d)  message compatibility information;
e)  message content.

The structure of the B-ISUP protocol is as follows:

8
7
6
5
4
3
2
1
Octets
Message Type
1
Length Indicator
2
3
Ext.
Broadband/narrow-
band interworking ind

Pass on
not possible
ind
Discard
message
ind
Send
notification
ind
Release
call ind
Transit at
intermed
exch. ind
4

Message Type
The different message types. The following message types are available:

0x01 INITIAL ADDRESS
0x02 SUBSEQUENT ADDRESS
0x05 CONSISTENCY CHECK REQUEST
0x06 ADDRESS COMPLETE
0x08 FORWARD TRANSFER
0x09 ANSWER
0x0A IAM ACKNOWLEDGE
0x0B IAM REJECT
0x0C RELEASE
0x0D SUSPEND
0x0E RESUME
0x0F RESET ACKNOWLEDGE
0x10 RELEASE COMPLETE
0x11 CONSISTENCY CHECK REQ ACK
0x12 RESET
0x13 BLOCKING
0x14 UNBLOCKING
0x15 BLOCKING ACKNOWLEDGE
0x16 UNBLOCKING ACKNOWLEDGE
0x17 CONSISTENCY CHECK END
0x18 CONSISTENCY CHECK END ACK
0x2C CALL PROGRESS
0x2D USER-TO-USER INFORMATION
0x2F CONFUSION
0x32 NET RESOURCE MANAGMENT
0x34 USER PART TEST
0x35 USER PART AVAILABLE
0x38 SEGMENTATION

Message Length
The message length in octets.

Broadband/narrow-band Iinterworking Ind:
0   Pass on
1   Discard message
2   Release call
3   Reserved

Pass on not Possible Indicator
The following indicators are available
0   Release call
1   Discard information

Discard Message Indicator
The following indicators are available
0   Do not discard message
1   Discard message

Send Notification Indicator
The following indicators are available
0   Do not send notification
1   Send notification

Release call indicator
The following indicators are available
0   Do not release call
1   Release call

Transit at intermed exch. Indicator
The following indicators are available
0   Transit interpretation
1   End node interpretation

Interested in more details about testing this protocol?

 

DUP

ITU-T recommendation X.61 (Q.741)
http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.html

The Data User Part (DUP) defines the necessary call control, and facility registration and cancellation related elements for international common channel signalling by use of Signalling System No. 7 for circuit-switched data transmission services. The data signalling messages are divided into two categories:

  • Call and circuit related messages: used to set up and clear a call or control and supervise the circuit state.
  • Facility registration and cancellation related messages: used to exchange information between originating and destination exchanges to register and cancel information related to user facilities.

The general format of the header of call and circuit related messages is shown as follows:

15 8 7 0

OPC

DPS
BIC OPC
TCS BIC
Message specific parameters Heading Code

The general format of the header of facility registration and cancellation messages is shown as follows:

15 8 7 0
OPC DPS
Spare bits OPC
Message specific parameters Heading code

Routing Label
The label contained in a signalling message and used by the relevant user part to identify particulars to which the message refers. This is also use by the message transfer part to route the message towards its destination point. It contains the DPS, OPC, BIC and TSC fields.

DPS
The destination point code (14 bits) is the code applicable to the data switching exchange to which the message is to be delivered.

OPC
The originating point code (14 bits) is the code applicable to the data switching exchange from which the message is sent.

BIC
Bearer identification code (12 bits). For bearers which form part of a 2.048 Mbit/s PCM system according to Recommendation G.734, the bearer identification code contains in the 5 least significant bits a binary representation of the actual number of the time slot which is assigned to the bearer. The remaining bits of the bearer identification code are used where necessary, to identify one among several systems, interconnecting the originating point and destination point. For bearers which form part of a 8.448 Mbit/s PCM system the bearer identification code is coded in accordance with the scheme specified for the circuit identification code for the corresponding case in Recommendation Q.723.

TSC
Time slot code (8 bits). If the data circuit is derived from the data multiplex carried by the bearer, identified by the bearer identification code:

Bits 1-4 contain, in pure binary representation, the channel number of the circuit within the 12.8 kbit/s or 12 kbit/s phase; the channel number being in the range:
0-15 for 600 bit/s circuits
0- 3 for 2400 bit/s circuits
0- 1 for 4800 bit/s circuits
0 for 9600 bit/s circuits

Bits 5-7 contain, in pure binary representation, the number of the 12.8 kbit/s or 12 kbit/s phase, the phase number being in the range 0-4;

Bit 8 is coded 0.

In the case where the data circuit uses the full 64 kbit/s bearer rate, the time slot code will be 01110000.

Heading code
The heading code (4 bits) contains the message type code which is mandatory for all messages. It uniquely defines the function and format of each DAP message.

Message specific parameters
Contains specific fields for each message.

Spare bits
Not used, should be set to "0000".

Interested in more details about testing this protocol?

 

ISUP

Q.763 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html

ISUP is the ISDN User Part of SS7. ISUP defines the protocol and procedures used to setup, manage and release trunk circuits that carry voice and data calls over the public switched telephone network. ISUP is used for both ISDN and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP signalling. ISDN User Part messages are carried on the signalling link by means of signal units. The signalling information field of each message signal unit contains an ISDN User Part message consisting of an integral number of octets.

The format of the ISUP packet is shown in the following illustration:

Routing label

Circuit identification code

Message type code

Mandatory fixed part - (Parameters)

Mandatory variable part - (Parameters)

Optional part - (Parameters)

ISUP packet structure

Routing label
The label contained in a signalling message, and used by the relevant user part to identify particulars to which the message refers. It is also used by the Message Transfer Part to route the message towards its destination point.

Circuit identification code
The allocation of circuit identification codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules.

Message type code
The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN User Part message. Each message consists of a number of parameters. Message types may be:
Address complete
Answer
Blocking
Blocking acknowledgement
Call progress
Circuit group blocking
Circuit group blocking acknowledgement
Circuit group query @
Circuit group query response @
Circuit group reset
Circuit group reset acknowledgement
Circuit group unblocking
Circuit group unblocking acknowledgement
Charge information @
Confusion
Connect
Continuity
Continuity check request
Facility @
Facility accepted
Facility reject
Forward transfer
Identification request
Identification response
Information @
Information request @
Initial address
Loop back acknowledgement
Network resource management
Overload @
Pass-along @
Release
Release complete
Reset circuit
Resume
Segmentation
Subsequent address
Suspend
Unblocking
Unblocking acknowledgement
Unequipped CIC @
User Part available
User Part test
User-to-user information

Parameters
Each parameter has a name which is coded as a single octet. The length of a parameter may be fixed or variable, and a length indicator for each parameter may be included.

ISUP decode

Interested in more details about testing this protocol?

 

MAP

EIA/TIA-41 http://www.tiaonline.org.com

Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming are carried by TCAP In mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber's home location register (HLR) using MAP (mobile application part) information carried within TCAP messages.

The packet consists of a header followed by up to four information elements. The general format of the header is shown here:

The format of the header is shown in the following illustration:

1 byte

1 byte

Operation specifier

Length

MAP Parameters
...

MAP header structure

Operation specifier
The type of packet. The following operations are defined:

  • AuthenticationDirective
  • AuthenticationDirectiveForward
  • AuthenticationFailureReport
  • AuthenticationRequest
  • AuthenticationStatusReport
  • BaseStationChallenge
  • Blocking
  • BulkDeregistration
  • CountRequest
  • FacilitiesDirective
  • FacilitiesDirective2
  • FacilitiesRelease
  • FeatureRequest
  • FlashRequest
  • HandoffBack
  • HandoffBack2
  • HandoffMeasurementRequest
  • HandoffMeasurementRequest2
  • HandoffToThird
  • HandoffToThird2
  • InformationDirective
  • InformationForward
  • InterSystemAnswer
  • InterSystemPage
  • InterSystemPage2
  • InterSystemSetup
  • LocationRequest
  • MobileOnChannel
  • MSInactive
  • OriginationRequest
  • QualificationDirective
  • QualificationRequest
  • RandomVariableRequest
  • RedirectionDirective
  • RedirectionRequest
  • RegistrationCancellation
  • RegistrationNotification
  • RemoteUserInteractionDirective
  • ResetCircuit
  • RoutingRequest
  • SMSDeliveryBackward
  • SMSDeliveryForward
  • SMSDeliveryPointToPoint
  • SMSNotification
  • SMSRequest
  • TransferToNumberRequest
  • TrunkTest
  • TrunkTestDisconnect
  • Unblocking
  • UnreliableRoamerDataDirective
  • UnsolicitedResponse

Length
The length of the packet.

MAP parameters
Various parameters dependent on the operation.

Interested in more details about testing this protocol?

 

MTP-2

Q.703 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q703_24110.html

Message Transfer Part - Level 2 (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points.
(Compliant with ITU Q.703 1994 and ANSI T1.111 199.)

The format of the header is shown in the following illustration:

7

8 bits

Flag

BSN (7 bits)

BIB

FSN (7 bits)

FIB

LI (6 + 2 bits)

SIO

SIF

Checksum
(16 bits)

Flag

MTP-2 header structure

BSN
Backward sequence number. Used to acknowledge message signal units which have been received from the remote end of the signalling link.

BIB
Backward indicator bit. The forward and backward indicator bit together with forward and backward sequence number are used in the basic error control method to perform the signal unit sequence control and acknowledgment functions.

FSN
Forward sequence number.

FIB
Forward indicator bit.

LI
Length indicator. This indicates the number of octets following the length indicator octet.

SIO
Service information octet.

SIF
Signalling information field.

Checksum
Every signal unit has 16 check bits for error detection.

Interested in more details about testing this protocol?

 

MTP-3

Q.704 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q704_27792.html

Message Transfer Part - Level 3 (MTP-3) connects Q.SAAL to the users. It transfers messages between the nodes of the signalling network. MTP-3 ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network.

The structure of the MTP-3 header is shown in the following illustration:

Service indicator

Subservice field

4 bits

4 bits

MTP-3 header structure

Service indicator
Used to perform message distribution and in some cases to perform message routing. The service indicator codes are used in international signalling networks for the following purposes:

  • Signalling network management messages
  • Signalling network testing and maintenance messages
  • SCCP
  • Telephone user part
  • ISDN user part
  • Data user part
  • Reserved for MTP testing user part.

Sub-service field
The sub-service field contains the network indicator and two spare bits to discriminate between national and international messages.

Interested in more details about testing this protocol?

 

Q2140

Recommendation Q.2140.
http://www.itu.int/ITU-T/

The SSCF for NNI Signaling standard consists of the Service Specific Coordination Function (SSCF) in conjunction with the Service Specific Connection Oriented Protocol (SSCOP) which defines the Service Specific Convergence Sublayer (SSCS). The purpose of the Service Specific Coordination Function is to enhance the services of SSCOP to meet the needs of the requirements of the NNI level 3 protocol. In addition the SSCF at the NNI provides communication with Layer Management for proper operation of signalling links.

The SSCF at the NNI is the uppermost sub-layer in the protocol stack for the SAAL at the NNI. By construction, it utilizes the services of the underlying SAAL sub-layers, in combination with its own functions, to provide an overall SAAL service to the SAAL user, as described below.

The SAAL at the NNI provides signalling link functions for the transfer of signalling messages over one individual signalling data link. The SAAL functions provide a signalling link for reliable transfer of signalling messages between two signalling points.

A signalling message delivered by the higher levels is transferred over the signalling link in variable length Protocol Data Units (PDUs). For proper operation of the signalling link, the PDU comprises transfer control information in addition to the information content of the signalling message.
The protocol header structure is as follows:

8
7
6
5
4
3
2
1
Octets
Reserved
1
2
3
SSCF Status
4

SSCF Type
The SSCF status:

1 Out of Service
2 Processor Outage
3 In Service
4 Normal
5 Emergency
7 Alignment Not Successful
8 Management Initiated
9 Protocol Error
10 Proving Not Successful


Interested in more details about testing this protocol?

 

 SCCP

Q.713 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q713_23786.html

The Signalling Connection Control Part (SCCP) offers enhancements to MTP level 3 to provide connectionless and connection-oriented network services, as well as to address translation capabilities. The SCCP enhancements to MTP provide a network service which is equivalent to the OSI Network layer 3.
(Compliant with the ITU specification Q.713, ITU-T: Signalling System No. 7 SCCP Formats And Codes 03-93 SS7 Basics/ Toni Beninger/ S038 1991 ANSI T1.112.)

The format of the header is shown in the following illustration:

Routing label

Message type code

Mandatory fixed part

Mandatory variable part

Optional part

SCCP header structure

Routing label
A standard routing label.

Message type code
A one octet code which is mandatory for all messages. The message type code uniquely defines the function and format of each SCCP message. Existing Message Type Codes are:

CR Connection Request.
CC Connection Confirm.
CREF Connection Refused.
RLSD Released.
RLC Release Complete.
DT1 Data Form 1.
DT2 Data Form 2.
AK Data Acknowledgment.
UDT Unidata.
UDTS Unidata Service.
ED Expedited Data.
EA Expedited Data Acknowledgment.
RSR Reset Request.
RSC Reset Confirm.
ERR Protocol Data Unit Error.
IT Inactivity Test.
XUDT Extended Unidata.
XUDTS Extended Unidata Service.

Mandatory fixed part
The parts that are mandatory and of fixed length for a particular message type will be contained in the mandatory fixed part.

Mandatory variable part
Mandatory parameters of variable length will be included in the mandatory variable part. The name of each parameter and the order in which the pointers are sent is implicit in the message type.

Optional part
The optional part consists of parameters that may or may not occur in any particular message type. Both fixed length and variable length parameters may be included. Optional parameters may be transmitted in any order. Each optional parameter will include the parameter name (one octet) and the length indicator (one octet) followed by the parameter contents.

Interested in more details about testing this protocol?

 

TCAP

Q.773 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q773_24880.html

TCAP (Transaction Capabilities Application Part) enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion.
(Compliant with ITU recommendation q.773.)

A TCAP message is structured as a single constructor information element consisting of the following: Transaction Portion, which contains information elements used by the Transaction sub-layer; a Component Portion, which contains information elements used by the Component sub-layer related to components; and, optionally, the Dialogue Portion, which contains the Application Context and user information, which are not components. Each Component is a constructor information element.

Tag

Length

Contents


TCAP packet structure

Information Element
An information element is first interpreted according to its position within the syntax of the message. Each information element within a TCAP message has the same structure. An information element consists of three fields, which always appear in the following order.

Tag
The Tag distinguishes one information element from another and governs the interpretation of the Contents. It may be one or more octets in length. The Tag is composed of Class, Form and Tag codes.

Length
Specifies the length of the Contents.

Contents
Contains the substance of the element, containing the primary information the element is intended to convey.

TCAP Packet Types

TCAP packet types are as follows:

  • Unidirectional
  • Query with permission
  • Query without permission
  • Response
  • Conversation with permission
  • Conversation without permission
  • Abort

Interested in more details about testing this protocol?

 

TUP

ITU-T Recommendation Q.723.
http://www.itu.int/ITU-T/.
Signalling System No.7 - Telephone User Part.

The Telephone User Part (TUP) carries the telephone user messages on the signalling data link by means of signal units.
The signalling information of each message constitutes the signalling information field of the corresponding signal unit and consists of an integral number of octets. It basically contains the label, the heading code and one or more signals and/or indications.
The service information octet comprises the service indicator and the subservice field.
The service indicator is used to associate signalling information with a particular User Part and is only used with message signal units (see Recommendation Q.704, § 12.2).
The information in the subservice field permits a distinction to be made between national and international signalling messages. In national applications when this discrimination is not required possibly for certain national User Parts only, the subservice field can be used independently for different User Parts.

The TUP header structure is as follows:

8
7
6
5
4
3
2
1
Octets
Message Type Code
1

Message Type Code
The message type code. The following message type codes are available:

0x11 Initial Address
0x21 Initial Address With Additional Information
0x31 Subsequent Address
0x41 Subsequent Address With One Signal
0x12 General Forward Setup Information
0x32 Continuity Signal
0x42 Continuity Failure Signal
0x13 General Request
0x14 Address Complete
0x24 Charging
0x15 Switching Equipment Congestion Signal
0x25 Circuit Group Congestion Signal
0x35 National Network Congestion Signal
0x45 Address Incomplete signal
0x55 Call Failure Signal
0x65 Subscriber Busy Signal (electrical)
0x75 Unallocated Number Signal
0x85 Line Out Of Service Signal
0x95 Send Special Information Tone Signal
0xA5 Access Barred Signal
0xB5 Digital Path Not Provided Signal
0xC5 Misdialled Trunk Prefix
0xF5 Extended Unsuccessful Backward Setup Information
0x06 Answer Signal, Unqualified
0x16 Answer Signal, Charge
0x26 Answer Signal, No Charge
0x36 Clear Back Signal
0x46 Clear Forward Signal
0x56 Reanswer Signal
0x66 Forward Transfer Signal
0x76 Calling Party Clear Signal
0x17 Release Guard Signal
0x27 Blocking Signal
0x37 Blocking Acknowledgement Signal
0x47 Unblocking Signal
0x57 Unblocking Acknowledgement Signal
0x67 Continuity Check Request Signal
0x77 Reset Circuit Signal
0x18 Maintenance Oriented Group Blocking
0x28 Maintenance Oriented Group Blocking Acknowledgement
0x38 Maintenance Oriented Group Unblocking
0x48 Maintenance Oriented Group Unblocking Acknowledgement
0x58 Hardware Failure Oriented Group Blocking
0x68 Hardware Failure Oriented Group Blocking Acknowledgement
0x78 Hardware Failure Oriented Group Unblocking
0x88 Hardware Failure Oriented Group Unblocking Acknowledgement
0x98 Circuit Group Reset
0xA8 Circuit Group Reset Acknowledgement
0xB8 Software Generated Group Blocking
0xC8 Software Generated Group Blocking Acknowledgement
0xD8 Software Generated Group Unblocking
0xE8 Software Generated Group Unblocking Acknowledgement
0x1A Automatic Congestion Control Information
0x2C Metering Pulse Message
0x1D Operator Signal
0x1E Subscriber Local - Busy Signal
0x2E Subscriber Toll - Busy Signal
0x1F Malicious Call Tracing Signal

Interested in more details about testing this protocol?

 

SS7 Family Protocol Information
BICC | BISUP | DUP | ISUP | MAP | MTP-2 | MTP-3 | Q2140 | SCCP | TCAP | TUP

 
Additional Information

 

 

조회 수 :
121570
등록일 :
2012.01.22
16:52:25 (*.160.42.233)
엮인글 :
http://webs.co.kr/index.php?document_srl=712&act=trackback&key=8de
게시글 주소 :
http://webs.co.kr/index.php?document_srl=712
List of Articles
번호 제목 글쓴이 날짜 조회 수
12 SIP h248 MECAGO MEDIA GATEWAY Control , SS7 admin 2012-03-03 31723
11 정부공공기관을 위한 인터넷전화 SIP 상호연동 서비스 시나리오 file admin 2012-02-07 28414
10 SS7 Protocol PPT file admin 2012-01-23 31983
9 SIP h248 MECAGO MEDIA GATEWAY Control , SS7 file admin 2012-01-22 30187
8 NGN file admin 2012-01-22 24813
7 Signalling System #7 (SS7) admin 2012-01-22 76353
» SS7 Protocol Book admin 2012-01-22 121570
5 Symmetrical RTP Support for MGCP-Based Calls admin 2011-12-16 94804
4 SIP 프로토콜 admin 2011-12-16 154711
3 KT 위성서비스 자료 file admin 2011-12-14 30317
2 PCM (Pulse Code Modulation) admin 2011-12-14 75466
1 PCM, G.711 admin 2011-12-14 32953