RFC2458 日本語訳
2458 Toward the PSTN/Internet Inter-Networking--Pre-PINTImplementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F.Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K.Vishwanathan. November 1998. (Format: TXT=139100 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Netowrk Working Group H. Lu
Request for Comments: 2458 Editor
Category: Informational M. Krishnaswamy
Lucent Technologies
L. Conroy
Roke Manor Research
S. Bellovin
F. Burg
A. DeSimone
K. Tewani
AT&T Labs
P. Davidson
Nortel
H. Schulzrinne
Columbia University
K. Vishwanathan
Isochrome
November 1998
Netowrk Working Group H. Lu Request for Comments: 2458 Editor Category: Informational M. Krishnaswamy Lucent Technologies L. Conroy Roke Manor Research S. Bellovin F. Burg A. DeSimone K. Tewani AT&T Labs P. Davidson Nortel H. Schulzrinne Columbia University K. Vishwanathan Isochrome November 1998
Toward the PSTN/Internet Inter-Networking
--Pre-PINT Implementations
Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Abstract
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that
Lu, et. al. Informational [Page 1] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 1] RFC 2458 Pre-PINT Implementations November 1998
will support inter-operation of the future implementations of PINT services.
will support inter-operation of the future implementations of PINT services.
Table of Contents
Table of Contents
1. Introduction ....................................... 3 2. Terminology ....................................... 3 3. PINT Services ....................................... 4 4. Architectural Overview ............................... 5 4.1 Public Switched Telephone Network ............... 5 4.2 Pre-PINT Systems ............................... 9 5. IN-Based Solutions ............................... 20 5.1 The Lucent System ............................... 20 5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20 5.1.2 A Click-to-Dial-Back Service Scenario ............... 21 5.1.3 Web Server-Service Node Interface ............... 22 5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24 5.1.5 Security Considerations ........................... 26 5.2 Siemens Web Call Center ........................... 27 5.2.1 Service Description ............................... 27 5.2.2 Implementation ................................... 29 5.2.3 Derived Requirements/Lessons ..................... 35 6. Alternative Solutions ............................... 37 6.1 The AT&T System ..................................... 37 6.1.1 High Level Architecture ............................ 38 6.1.2 IP Client to CallBroker Interface .................. 39 6.1.3 Protocol ........................................... 40 6.1.4 APIs Exposed to the IP Client ..................... 41 6.1.5 Voice-Bridge Control API ........................ 41 6.2 Simple Computer Telephony Protocol ............... 41 6.2.1 Overview ........................................... 41 6.2.2 How SCTP Fits in with the Reference PINT Services .. 42 7. Session Initiation Protocol--An Emerging Standard .. 43 7.1 Overview ....................................... 43 7.2 SIP Protocol ....................................... 44 7.3 SIP Entities ....................................... 45 7.4 Providing Call Control Functionality ............... 46 8. Overall Security Considerations ..................... 47 9. Conclusion ....................................... 48 10. Acknowledgments ................................... 48 11. Appendix ....................................... 49 11.1 PSTN/IN 101 ....................................... 49 11.1.1 Public Switched Telephone Network ............... 49 11.1.2 Intelligent Network ............................... 51 11.2 Call Center Features ............................. 54
1. Introduction ....................................... 3 2. Terminology ....................................... 3 3. PINT Services ....................................... 4 4. Architectural Overview ............................... 5 4.1 Public Switched Telephone Network ............... 5 4.2 Pre-PINT Systems ............................... 9 5. IN-Based Solutions ............................... 20 5.1 The Lucent System ............................... 20 5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20 5.1.2 A Click-to-Dial-Back Service Scenario ............... 21 5.1.3 Web Server-Service Node Interface ............... 22 5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24 5.1.5 Security Considerations ........................... 26 5.2 Siemens Web Call Center ........................... 27 5.2.1 Service Description ............................... 27 5.2.2 Implementation ................................... 29 5.2.3 Derived Requirements/Lessons ..................... 35 6. Alternative Solutions ............................... 37 6.1 The AT&T System ..................................... 37 6.1.1 High Level Architecture ............................ 38 6.1.2 IP Client to CallBroker Interface .................. 39 6.1.3 Protocol ........................................... 40 6.1.4 APIs Exposed to the IP Client ..................... 41 6.1.5 Voice-Bridge Control API ........................ 41 6.2 Simple Computer Telephony Protocol ............... 41 6.2.1 Overview ........................................... 41 6.2.2 How SCTP Fits in with the Reference PINT Services .. 42 7. Session Initiation Protocol--An Emerging Standard .. 43 7.1 Overview ....................................... 43 7.2 SIP Protocol ....................................... 44 7.3 SIP Entities ....................................... 45 7.4 Providing Call Control Functionality ............... 46 8. Overall Security Considerations ..................... 47 9. Conclusion ....................................... 48 10. Acknowledgments ................................... 48 11. Appendix ....................................... 49 11.1 PSTN/IN 101 ....................................... 49 11.1.1 Public Switched Telephone Network ............... 49 11.1.2 Intelligent Network ............................... 51 11.2 Call Center Features ............................. 54
Lu, et. al. Informational [Page 2] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 2] RFC 2458 Pre-PINT Implementations November 1998
12. References ....................................... 56 Authors' Addresses ......................................... 57 Full Copyright Statement .................................. 60
12. References ....................................... 56 Authors' Addresses ......................................... 57 Full Copyright Statement .................................. 60
1. Introduction
1. Introduction
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN.
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN.
The organization of the document is as follows. First, the basic terminology and a short "intuitive" description of the PINT services are provided. The rest of the information deals, in one way or the other, with the pre-PINT support of these services where they are used as a benchmark. Thus, an architectural overview common to all present solutions is presented. The flow of the document then divides into two streams: one is dedicated to the Intelligent Network (IN)-based solutions; the other explores alternative means (i.e., CallBroker and Computer-Telephony Integration (CTI) approach). At this point, the emerging standards are explored, in particular, the Session Initiation Protocol (SIP), which promises an elegant solution to the PINT problem. Each of the above developments is addressed in a respective section. The final sections of the document contain the overall security considerations, conclusion, acknowledgments, appendix, and a set of references. The security section summarizes the PINT security requirements derived from the pre-PINT experiences and the appendix presents a tutorial on the PSTN, IN, and Call Center functions.
The organization of the document is as follows. First, the basic terminology and a short "intuitive" description of the PINT services are provided. The rest of the information deals, in one way or the other, with the pre-PINT support of these services where they are used as a benchmark. Thus, an architectural overview common to all present solutions is presented. The flow of the document then divides into two streams: one is dedicated to the Intelligent Network (IN)-based solutions; the other explores alternative means (i.e., CallBroker and Computer-Telephony Integration (CTI) approach). At this point, the emerging standards are explored, in particular, the Session Initiation Protocol (SIP), which promises an elegant solution to the PINT problem. Each of the above developments is addressed in a respective section. The final sections of the document contain the overall security considerations, conclusion, acknowledgments, appendix, and a set of references. The security section summarizes the PINT security requirements derived from the pre-PINT experiences and the appendix presents a tutorial on the PSTN, IN, and Call Center functions.
2. Terminology
2. Terminology
This document uses the following terminology:
This document uses the following terminology:
Authentication -- verification of the identity of a party.
Authentication -- verification of the identity of a party.
Authorization -- determination of whether or not a party has the right to perform certain activities.
Authorization -- determination of whether or not a party has the right to perform certain activities.
PINT Gateway -- the PSTN node that interacts with the Internet.
PINT Gateway -- the PSTN node that interacts with the Internet.
Lu, et. al. Informational [Page 3] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 3] RFC 2458 Pre-PINT Implementations November 1998
User or Customer -- the person who asks for a service request to be issued. In the context of PINT Services, this person will use an Internet host to make his or her request. The term "user" is also used to describe a host originating the PINT service request on behalf of this person.
User or Customer -- the person who asks for a service request to be issued. In the context of PINT Services, this person will use an Internet host to make his or her request. The term "user" is also used to describe a host originating the PINT service request on behalf of this person.
3. PINT Services
3. PINT Services
This document addresses four services initially identified by the PINT Working Group and presently supported by pre-PINT implementations. These services are: click-to-dial-back, click-to- fax, click-to-fax-back and voice-access-to-content.
This document addresses four services initially identified by the PINT Working Group and presently supported by pre-PINT implementations. These services are: click-to-dial-back, click-to- fax, click-to-fax-back and voice-access-to-content.
Note that the word "click" should not be taken literally. It is rather used to point out that initiation of the related services takes place on the Internet, where point and click are the most prevalent user actions. In other words, a service request could originate from any type of IP-based platforms. There is no implication that these services must be implemented by a device within the PSTN or the Internet running a Web server.
Note that the word "click" should not be taken literally. It is rather used to point out that initiation of the related services takes place on the Internet, where point and click are the most prevalent user actions. In other words, a service request could originate from any type of IP-based platforms. There is no implication that these services must be implemented by a device within the PSTN or the Internet running a Web server.
The common denominator of the PINT services is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. (An example of such a service is combination of a Web-based Yellow Pages service with the ability to initiate PSTN calls between customers and suppliers in a manner described in what follows.)
The common denominator of the PINT services is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. (An example of such a service is combination of a Web-based Yellow Pages service with the ability to initiate PSTN calls between customers and suppliers in a manner described in what follows.)
Some of the benefits of using the PSTN are high quality of the voice, an ability to route the call to different locations depending on pre-set criteria (for example, time of the day, day of the week, and geographic location), outstanding security and reliability, and access to flexible, low cost, and secure billing and charging systems. The benefits of using the Internet are the uniform, well- defined, and widely-used interfaces available anywhere, anytime.
Some of the benefits of using the PSTN are high quality of the voice, an ability to route the call to different locations depending on pre-set criteria (for example, time of the day, day of the week, and geographic location), outstanding security and reliability, and access to flexible, low cost, and secure billing and charging systems. The benefits of using the Internet are the uniform, well- defined, and widely-used interfaces available anywhere, anytime.
Click-to-Dial-Back
Click-to-Dial-Back
With this service, a user requests (through an IP host) that the PSTN call be established between another party and himself or herself. An important pre-requisite for using this service is that the user has simultaneous access to both the PSTN and Internet.
With this service, a user requests (through an IP host) that the PSTN call be established between another party and himself or herself. An important pre-requisite for using this service is that the user has simultaneous access to both the PSTN and Internet.
One example of an application of this service is on-line shopping: a user browsing through an on-line catalogue, clicks a button thus inviting a call from a sales representative. Note that (as is the case with the all-PSTN Free-Phone, or "800", service) flexible
One example of an application of this service is on-line shopping: a user browsing through an on-line catalogue, clicks a button thus inviting a call from a sales representative. Note that (as is the case with the all-PSTN Free-Phone, or "800", service) flexible
Lu, et. al. Informational [Page 4] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 4] RFC 2458 Pre-PINT Implementations November 1998
billing arrangements can be implemented here on behalf of the service provider. In addition (and also similarly to the Free-Phone/800), the PSTN could route the call depending on the time of day, day of week, availability of agents in different locations, and so on.
billing arrangements can be implemented here on behalf of the service provider. In addition (and also similarly to the Free-Phone/800), the PSTN could route the call depending on the time of day, day of week, availability of agents in different locations, and so on.
Click-to-Fax
Click-to-Fax
With this service, a user at an IP host requests that a fax be sent to a particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax machine (but no access to the Internet). Consider, as an example, a service scenario in which a Web user makes a reservation for a hotel room in Beijing from a travel service page containing hotel information of major cities around the world. Suppose a specific Beijing hotel chosen by the user does not have Internet connection but has a fax machine. The user fills out the hotel reservation form and then clicks a button sending out the form to the travel service provider, which in turn generates a fax request and sends it together with the hotel reservation form to the PSTN. Upon receiving the request and the associated data, the PSTN translates the data into the proper facsimile format and delivers it to the Beijing hotel as specified in the fax request.
With this service, a user at an IP host requests that a fax be sent to a particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax machine (but no access to the Internet). Consider, as an example, a service scenario in which a Web user makes a reservation for a hotel room in Beijing from a travel service page containing hotel information of major cities around the world. Suppose a specific Beijing hotel chosen by the user does not have Internet connection but has a fax machine. The user fills out the hotel reservation form and then clicks a button sending out the form to the travel service provider, which in turn generates a fax request and sends it together with the hotel reservation form to the PSTN. Upon receiving the request and the associated data, the PSTN translates the data into the proper facsimile format and delivers it to the Beijing hotel as specified in the fax request.
Click-to-Fax-Back
Click-to-Fax-Back
With this service, a user at an IP host can request that a fax be sent to him or her. (Consider the user of the previous example, who now requests the confirmation from the Beijing Hotel. Another useful application of the service is when size of the information that a user intends to get is so large that downloading it to the user's PC over the Internet will require a long time and a lot of disk space.)
With this service, a user at an IP host can request that a fax be sent to him or her. (Consider the user of the previous example, who now requests the confirmation from the Beijing Hotel. Another useful application of the service is when size of the information that a user intends to get is so large that downloading it to the user's PC over the Internet will require a long time and a lot of disk space.)
Voice-Access-to-Content
Voice-Access-to-Content
With this service, a user at an IP host requests that certain information on the Internet be accessed (and delivered) in an audio form over the PSTN, using the telephone as an informational appliance. One application of this service is to provide Web access to the blind. (This may require special resources--available in the PSTN--to convert the Web data into speech.)
With this service, a user at an IP host requests that certain information on the Internet be accessed (and delivered) in an audio form over the PSTN, using the telephone as an informational appliance. One application of this service is to provide Web access to the blind. (This may require special resources--available in the PSTN--to convert the Web data into speech.)
4. Architectural Overview
4. Architectural Overview
4.1 Public Switched Telephone Network
4.1 Public Switched Telephone Network
From an application perspective, Internet nodes are interconnected directly, as shown in Figure 1. When two machines are to communicate, they will have the address of the destination end system, and will
From an application perspective, Internet nodes are interconnected directly, as shown in Figure 1. When two machines are to communicate, they will have the address of the destination end system, and will
Lu, et. al. Informational [Page 5] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 5] RFC 2458 Pre-PINT Implementations November 1998
send network level datagrams, assuming that the underlying infrastructure will deliver them as required.
send network level datagrams, assuming that the underlying infrastructure will deliver them as required.
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.
\_____ _______/ |
__ \__./ __ .
[__] / [__] |
[----]-. [----]-.
_____ __ _____/ \_____ [__] / \ [----]-.-.-.-. Internet .-. \_____ _______/ | __ \__./ __ . [__] / [__] | [----]-. [----]-.
Key: .-.-. Internet Access Link
Key: .-.-. Internet Access Link
Figure 1
Figure 1
Where all nodes are on the same (broadcast) network, there is no need for intervening routers; they can send and deliver packets to one another directly. The Internet nodes are responsible for their own communications requests, and act as peers in the communication sessions that result.
Where all nodes are on the same (broadcast) network, there is no need for intervening routers; they can send and deliver packets to one another directly. The Internet nodes are responsible for their own communications requests, and act as peers in the communication sessions that result.
This contrasts with the situation in the PSTN. There, the end systems are configured as shown in Figure 2. The end systems tend to be specific to a particular type of traffic, so that, for example, the majority of terminals are dedicated to carrying speech traffic (telephones) or to carrying facsimile data (fax machines). The terminals all connect to Central Offices (COs) via access lines, and these COs are interconnected into a network.
This contrasts with the situation in the PSTN. There, the end systems are configured as shown in Figure 2. The end systems tend to be specific to a particular type of traffic, so that, for example, the majority of terminals are dedicated to carrying speech traffic (telephones) or to carrying facsimile data (fax machines). The terminals all connect to Central Offices (COs) via access lines, and these COs are interconnected into a network.
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
/--\ ()/\()__ /__\ \ ................................. \ ! ! ! /--\ __ \ [-!-] [-!-] ! ()/\() \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ [Fax]________[---] [---] \\ [-!-] / __ \\=======[CO ]____/ \ \ [---]________[Fax] Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links CO Central Office (Telephone Exchange)
Figure 2
Figure 2
Lu, et. al. Informational [Page 6] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 6] RFC 2458 Pre-PINT Implementations November 1998
Communications between the terminals are all "circuit switched", so a dedicated synchronous data path (or circuit) needs to be placed between the end terminals for carrying all communications. Arranging for such a circuit to be made or removed (cleared) is the responsibility of the Central Offices in the network. A user makes a request via his or her terminal, and this request is passed on to the "local" Central Office. The relationship between the terminals and the local Central Offices to which they are connected is strictly Client/Server.
Communications between the terminals are all "circuit switched", so a dedicated synchronous data path (or circuit) needs to be placed between the end terminals for carrying all communications. Arranging for such a circuit to be made or removed (cleared) is the responsibility of the Central Offices in the network. A user makes a request via his or her terminal, and this request is passed on to the "local" Central Office. The relationship between the terminals and the local Central Offices to which they are connected is strictly Client/Server.
The COs are interconnected using two different types of connections. One of these is called a trunk connection (shown as a double line in the above figure) and is used to carry the data traffic generated by the terminals. The other connection acts as part of a separate network (and is shown as a dotted line in the above figure). This is the signaling network, and is used by the Central Offices to request a connection to be made between themselves and the destination of the required circuit. This will be carried across the trunk link to the "next" Central Office in the path. The path, once in place through the PSTN, always takes the same route. This contrasts with the Internet, where the underlying datagram nature of the infrastructure means that data packets are carried over different routes, depending on the combined traffic flows through the network at the time.
The COs are interconnected using two different types of connections. One of these is called a trunk connection (shown as a double line in the above figure) and is used to carry the data traffic generated by the terminals. The other connection acts as part of a separate network (and is shown as a dotted line in the above figure). This is the signaling network, and is used by the Central Offices to request a connection to be made between themselves and the destination of the required circuit. This will be carried across the trunk link to the "next" Central Office in the path. The path, once in place through the PSTN, always takes the same route. This contrasts with the Internet, where the underlying datagram nature of the infrastructure means that data packets are carried over different routes, depending on the combined traffic flows through the network at the time.
The call set up process can be viewed as having two parts: one in which a request for connection is made, and the other in which the circuit is made across the PSTN and call data flows between the communicating parties. This is shown in the next pair of figures (3a and 3b).
The call set up process can be viewed as having two parts: one in which a request for connection is made, and the other in which the circuit is made across the PSTN and call data flows between the communicating parties. This is shown in the next pair of figures (3a and 3b).
/--\
() ()
--____
/++\ \
/----\ \
A \ [-!-]
\->[CO ]
[---]
Time = 13:55
/--\ () () --____ /++\ \ /----\ \ A \ [-!-] \->[CO ] [---] Time = 13:55
Figure 3a
Figure 3a
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links CO Central Office (Telephone Exchange)
Lu, et. al. Informational [Page 7] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 7] RFC 2458 Pre-PINT Implementations November 1998
/--\
() ()
-- .................................
/ \<--- ^ ! ! /--\
/----\ \ ! v ! () ()
A' \ [-!-] [-!-] ! --
\__[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B'
Time = 14:00 [---]
/--\ () () -- ................................. / \<--- ^ ! ! /--\ /----\ \ ! v ! () () A' \ [-!-] [-!-] ! -- \__[CO ]=========[CO ]==\\ v ->-/ \ [---] [---] \\ [-!-] / /----\ \\=======[CO ]____/ B' Time = 14:00 [---]
Figure 3b
Figure 3b
Figure 3 shows a particular kind of service that can be provided; call booking. With this service, a request is sent for a connection to be made between the A and B telephones at a specified time. The telephone is then replaced (the request phase is terminated). At the specified time, the CO will make a connection across the network in the normal way, but will, first, ring the "local" or A' telephone to inform the user that his or her call is now about to be made.
Figure 3 shows a particular kind of service that can be provided; call booking. With this service, a request is sent for a connection to be made between the A and B telephones at a specified time. The telephone is then replaced (the request phase is terminated). At the specified time, the CO will make a connection across the network in the normal way, but will, first, ring the "local" or A' telephone to inform the user that his or her call is now about to be made.
For more complex services, the requesting telephone is often connected via its "local" CO to a Service Node (SN), where the user can be played prompts and can specify the parameters of his or her request in a more flexible manner. This is shown below, in Figures 4a and 4b. For more details of the operation of the Service Node (and other Intelligent Network units), see the Appendix.
For more complex services, the requesting telephone is often connected via its "local" CO to a Service Node (SN), where the user can be played prompts and can specify the parameters of his or her request in a more flexible manner. This is shown below, in Figures 4a and 4b. For more details of the operation of the Service Node (and other Intelligent Network units), see the Appendix.
When the SN is involved in the request and in the call setup process, it appears, to the CO, to be another PSTN terminal. As such, the initial request is routed to the Service Node, which, as an end system, then makes two independent calls "out" to A' and B'.
When the SN is involved in the request and in the call setup process, it appears, to the CO, to be another PSTN terminal. As such, the initial request is routed to the Service Node, which, as an end system, then makes two independent calls "out" to A' and B'.
/--\ [---]
() () [SN ]
--___ [|--]
/++\ \ |
/----\ \ |
\ |
A \ [|-!]
\->[CO ]
[---]
Time = 13:55
/--\ [---] () () [SN ] --___ [|--] /++\ \ | /----\ \ | \ | A \ [|-!] \->[CO ] [---] Time = 13:55
Figure 4a
Figure 4a
Lu, et. al. Informational [Page 8] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 8] RFC 2458 Pre-PINT Implementations November 1998
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
SN Service Node
Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links CO Central Office (Telephone Exchange) SN Service Node
/--\ [---]
() () [SN ]
-- [|--] /--\
/ \<-- | ............................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] /
[---] [---] [---]___/ B'
Time = 14:00
/--\ [---] () () [SN ] -- [|--] /--\ / \<-- | ............................... () () /----\ \ | ^ ! ! -- \ | / v v / \ A' \ [|-!] [-!-] [-!-] ->-/----\ \--[CO ] [CO ] [CO ] / [---] [---] [---]___/ B' Time = 14:00
Figure 4b
Figure 4b
Note that in both cases as shown in Figures 3 and 4 a similar service can be provided in which the B' telephone is replaced by an Intelligent Peripheral (or an Special Resource Functional entity within a Service Node), playing an announcement. This allows a "wake up" call to be requested, with the Intelligent Peripheral or Service Node Special Resource playing a suitable message to telephone A' at the specified time. Again, for more details of the operation of the Special Resources (and other Intelligent Network units), see the Appendix.
Note that in both cases as shown in Figures 3 and 4 a similar service can be provided in which the B' telephone is replaced by an Intelligent Peripheral (or an Special Resource Functional entity within a Service Node), playing an announcement. This allows a "wake up" call to be requested, with the Intelligent Peripheral or Service Node Special Resource playing a suitable message to telephone A' at the specified time. Again, for more details of the operation of the Special Resources (and other Intelligent Network units), see the Appendix.
4.2 Pre-PINT Systems
4.2 Pre-PINT Systems
Although the pre-PINT systems reported here (i.e., those developed by AT&T, Lucent, Siemens and Nortel) vary in the details of their operation, they exhibit similarities in the architecture. This section highlights the common features. Specific descriptions of these systems will follow.
Although the pre-PINT systems reported here (i.e., those developed by AT&T, Lucent, Siemens and Nortel) vary in the details of their operation, they exhibit similarities in the architecture. This section highlights the common features. Specific descriptions of these systems will follow.
All of the systems can be seen as being quite similar to that shown in the following diagram. In each case, the service is separated into two parts; one for the request and another for execution of the service. Figure 5 summarizes the process.
All of the systems can be seen as being quite similar to that shown in the following diagram. In each case, the service is separated into two parts; one for the request and another for execution of the service. Figure 5 summarizes the process.
Lu, et. al. Informational [Page 9] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 9] RFC 2458 Pre-PINT Implementations November 1998
_____
__ _____/ \_____
[__] / \
[-++-]-.-.>.-. Internet .-.-
\_____ _______/ .
\___/ v
[----] .
[PINT]-.-
[----]
%
v
[---]
[SN ]
[|--]
_____ __ _____/ \_____ [__] / \ [-++-]-.-.>.-. Internet .-.- \_____ _______/ . \___/ v [----] . [PINT]-.- [----] % v [---] [SN ] [|--]
Figure 5a
Figure 5a
Key: CO Central Office (Telephone Exchange)
SN Service Node
PINT PSTN/Internet Gateway
.-.-. Internet Access Link
%%% Gateway/Service Node Link
___ PSTN Access Lines
=== PSTN Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
Key: CO Central Office (Telephone Exchange) SN Service Node PINT PSTN/Internet Gateway .-.-. Internet Access Link %%% Gateway/Service Node Link ___ PSTN Access Lines === PSTN Trunk Links (inter-CO user data links) ... Inter-CO signaling network links
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.-
\_____ _______/ .
\___/ |
[----] .
[PINT]-.-
[-%--]
%
%
/--\ [-%-]
() () [SN ]
-- [|--] /--\
/ \<-- | .................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B'
_____ __ _____/ \_____ [__] / \ [----]-.-.-.-. Internet .-.- \_____ _______/ . \___/ | [----] . [PINT]-.- [-%--] % % /--\ [-%-] () () [SN ] -- [|--] /--\ / \<-- | .................... () () /----\ \ | ^ ! ! -- \ | / v v / \ A' \ [|-!] [-!-] [-!-] ->-/----\ \--[CO ]=======[CO ]======[CO ] / [---] [---] [---]__/ B'
Figure 5b
Figure 5b
Lu, et. al. Informational [Page 10] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 10] RFC 2458 Pre-PINT Implementations November 1998
Comparing Figure 4a with Figure 5a, the differences lie in the way that the information specifying the request is delivered to the Service Node. In the PSTN/IN method shown in the earlier diagram, the user connects to the SN from the telephone labeled A, with the connection being routed via the CO. In the latter case, the request is delivered from an Internet node, via the PINT gateway, and thence to the Service Node over a "private" link. The effect is identical, in that the request for service is specified (although the actual parameters used to specify the service required may differ somewhat).
Comparing Figure 4a with Figure 5a, the differences lie in the way that the information specifying the request is delivered to the Service Node. In the PSTN/IN method shown in the earlier diagram, the user connects to the SN from the telephone labeled A, with the connection being routed via the CO. In the latter case, the request is delivered from an Internet node, via the PINT gateway, and thence to the Service Node over a "private" link. The effect is identical, in that the request for service is specified (although the actual parameters used to specify the service required may differ somewhat).
The figures depicting the respective service execution phases (Figures 4b and 5b) show that the operation, from the IN/PSTN perspective, is again identical. The Service Node appears to initiate two independent calls "out" to telephones A' and B'.
The figures depicting the respective service execution phases (Figures 4b and 5b) show that the operation, from the IN/PSTN perspective, is again identical. The Service Node appears to initiate two independent calls "out" to telephones A' and B'.
The alternative systems developed by AT&T and by Nortel allow another option to be used in which the PINT Gateway does not have to connect to the PSTN via a Service Node (or other Intelligent Network component), but can instead connect directly to Central Offices that support the actions requested by the gateway. In these alternatives, the commands are couched at a "lower level", specifying the call states required for the intended service connection rather than the service identifier and the addresses involved (leaving the Intelligent Network components to coordinate the details of the service call on the gateway's behalf). In this way the vocabulary of the commands is closer to that used to control Central Offices. The difference really lies in the language used for the services specification, and all systems can use the overall architecture depicted in Figure 5; the only question remains whether the Intelligent Network components are actually needed in these other approaches.
The alternative systems developed by AT&T and by Nortel allow another option to be used in which the PINT Gateway does not have to connect to the PSTN via a Service Node (or other Intelligent Network component), but can instead connect directly to Central Offices that support the actions requested by the gateway. In these alternatives, the commands are couched at a "lower level", specifying the call states required for the intended service connection rather than the service identifier and the addresses involved (leaving the Intelligent Network components to coordinate the details of the service call on the gateway's behalf). In this way the vocabulary of the commands is closer to that used to control Central Offices. The difference really lies in the language used for the services specification, and all systems can use the overall architecture depicted in Figure 5; the only question remains whether the Intelligent Network components are actually needed in these other approaches.
Lu, et. al. Informational [Page 11] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 11] RFC 2458 Pre-PINT Implementations November 1998
The following diagram (Figure 6) shows the interface architecture involved in providing the kind of service mentioned above.
The following diagram (Figure 6) shows the interface architecture involved in providing the kind of service mentioned above.
Internet __ __
Server [__] _______ [__]
[W3S-]-. ___/ .-.-.-[W3C-] Internet
_________________|/.-.-.-.-. \ Terminal
/ .. . \
| Internet / . \ |
\___________ . . . /
\/___|____\_________/
. . .
/ | \
(A) (B) (E)
. . .
_|_ _|_ _|_
[SN ]<-(D)--[SMS]--(H)->[SCP]
[|-|] --- [-!-]
/ \ !
(C) (I) ...........(F)...!.(G).
/ \ ! !
[--|] [|-!] [-!-]
[CO ] [MSC] [SSP]
[---] [---] \|/ [---]
/--\ | |____| | /--\
()/\() | | ()/\()
/--\___| 1 |___/--\
Fixed PSTN Terminal [] Fixed PSTN Terminal
Mobile Terminal
Internet __ __ Server [__] _______ [__] [W3S-]-. ___/ .-.-.-[W3C-] Internet _________________|/.-.-.-.-. \ Terminal / .. . \ | Internet / . \ | \___________ . . . / \/___|____\_________/ . . . / | \ (A) (B) (E) . . . _|_ _|_ _|_ [SN ]<-(D)--[SMS]--(H)->[SCP] [|-|] --- [-!-] / \ ! (C) (I) ...........(F)...!.(G). / \ ! ! [--|] [|-!] [-!-] [CO ] [MSC] [SSP] [---] [---] \|/ [---] /--\ | |____| | /--\ ()/\() | | ()/\() /--\___| 1 |___/--\ Fixed PSTN Terminal [] Fixed PSTN Terminal Mobile Terminal
Key: W3S HTTP (Web) Server
W3C HTTP (Web) Client/Browser
CO Central Office (Telephone Exchange)
MSC Mobile Switching Center (Mobile Network Telephone
Exchange)
SN Service Node
SSP Service Switching Point
SCP Service Control Point
SMS Service Management System
.-.-. Internet relationship
___ PSTN Access relationship
... PSTN "core" signaling relationship
Key: W3S HTTP (Web) Server W3C HTTP (Web) Client/Browser CO Central Office (Telephone Exchange) MSC Mobile Switching Center (Mobile Network Telephone Exchange) SN Service Node SSP Service Switching Point SCP Service Control Point SMS Service Management System .-.-. Internet relationship ___ PSTN Access relationship ... PSTN "core" signaling relationship
Figure 6
Figure 6
Lu, et. al. Informational [Page 12] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 12] RFC 2458 Pre-PINT Implementations November 1998
The interfaces are:
The interfaces are:
A The interface over which Internet requests for service are
delivered to the Service Node
B The interface over which Service Management requests are sent
from the Internet to the Service Management System
C The interface over which the Service Node sends call control
requests to a connected Central Office
D The interface over which the Service Management System manages
the Service Node
E The interface over which Internet requests for service are
delivered to the Service Control Point
F The interface over which the Service Control Point sends service
call control requests to the Mobile Switching Center
G The interface over which the Service Control Point sends service
control requests to the Service Switching Point
H The interface over which the Service Management System manages
the Service Control Point
I The interface over which the Service Node sends service call
control requests to the Mobile Switching Center
A The interface over which Internet requests for service are delivered to the Service Node B The interface over which Service Management requests are sent from the Internet to the Service Management System C The interface over which the Service Node sends call control requests to a connected Central Office D The interface over which the Service Management System manages the Service Node E The interface over which Internet requests for service are delivered to the Service Control Point F The interface over which the Service Control Point sends service call control requests to the Mobile Switching Center G The interface over which the Service Control Point sends service control requests to the Service Switching Point H The interface over which the Service Management System manages the Service Control Point I The interface over which the Service Node sends service call control requests to the Mobile Switching Center
In practice, a number of the interfaces have very similar purposes to one another. The means by which these purposes are achieved differ, in that some of the interfaces (C and I) reflect access arrangements, whilst others (F and G) imply a "core" signaling relationship. However, it is possible to categorize them in terms of the "intent" of messages sent across the interfaces.
In practice, a number of the interfaces have very similar purposes to one another. The means by which these purposes are achieved differ, in that some of the interfaces (C and I) reflect access arrangements, whilst others (F and G) imply a "core" signaling relationship. However, it is possible to categorize them in terms of the "intent" of messages sent across the interfaces.
For example, Interfaces A and E are similar; one of the main aims of PINT work is to ensure that they are the same. Similarly, Interfaces D and H imply similar actions and are likely to carry similar messages. Interfaces C, F, G, and I are all used to request that a call be initiated, albeit via access or core signaling relationships.
For example, Interfaces A and E are similar; one of the main aims of PINT work is to ensure that they are the same. Similarly, Interfaces D and H imply similar actions and are likely to carry similar messages. Interfaces C, F, G, and I are all used to request that a call be initiated, albeit via access or core signaling relationships.
The interfaces can also be viewed in terms of the kind of components that are involved and the bodies by which they are codified. Interfaces A, B, and E are all going to be realized as Internet Protocols. All of the others use existing protocols in the PSTN/IN. Traditionally, these have been codified by different groups, and this is likely to be the case in the PINT work.
The interfaces can also be viewed in terms of the kind of components that are involved and the bodies by which they are codified. Interfaces A, B, and E are all going to be realized as Internet Protocols. All of the others use existing protocols in the PSTN/IN. Traditionally, these have been codified by different groups, and this is likely to be the case in the PINT work.
The general arrangements for the different systems are shown below (Figures 7, 8, 9, and 10). They differ in the details of their configurations, but the main tasks they perform are very similar, and so the overall operation is similar to the generic architecture shown in Figures 5 and 6.
The general arrangements for the different systems are shown below (Figures 7, 8, 9, and 10). They differ in the details of their configurations, but the main tasks they perform are very similar, and so the overall operation is similar to the generic architecture shown in Figures 5 and 6.
Lu, et. al. Informational [Page 13] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 13] RFC 2458 Pre-PINT Implementations November 1998
Key for following diagrams:
Key for following diagrams:
Components:
Components:
W3C World Wide Web Client
W3S World Wide Web Server
WSA Web Server "Back End Program" Interface (CGI or Servlet
interface)
Srvlt Servlet "back end" program/objects
FS Finger Server
SCTPC Simple Computer Telephony Protocol Client
SCTPS Simple Computer Telephony Protocol Server
CBC CallBroker Client
CBS CallBroker Server
SSTPC Service Support Transport Protocol Client
SSF Service Switching Function
SCF Service Control Function
SRF Special Resource Function
CO Central Office/ Public Telephone Exchange
SSP Service Switching Point
SCP Service Control Point
SR/I.IP Special Resource/ "Internet" Intelligent Peripheral
SMS Service Management System
INAPAd Intelligent Network Application Part Adaptor
PktFlt Packet Filter (Firewall)
SNMPAg Simple Network Management Protocol Agent
W3C World Wide Web Client W3S World Wide Web Server WSA Web Server "Back End Program" Interface (CGI or Servlet interface) Srvlt Servlet "back end" program/objects FS Finger Server SCTPC Simple Computer Telephony Protocol Client SCTPS Simple Computer Telephony Protocol Server CBC CallBroker Client CBS CallBroker Server SSTPC Service Support Transport Protocol Client SSF Service Switching Function SCF Service Control Function SRF Special Resource Function CO Central Office/ Public Telephone Exchange SSP Service Switching Point SCP Service Control Point SR/I.IP Special Resource/ "Internet" Intelligent Peripheral SMS Service Management System INAPAd Intelligent Network Application Part Adaptor PktFlt Packet Filter (Firewall) SNMPAg Simple Network Management Protocol Agent
Protocols:
Protocols:
P0 HyperText Transfer Protocol
P1 HTTP Server <-> "Back End Program" internal protocol
P2 CallBroker Client <-> CallBroker Server protocol (AT&T system),
or SCTP Client <-> Server protocol (Nortel system)
P3 PINT User Agent <-> PINT Gateway protocol
P4 Intra-Intelligent Network protocol (e.g., INAP)
P5 Proprietary (INAP-based) Gateway-> I.IP protocol
P6 Finger protocol
P7 Digital Subscriber Signaling 1 protocol
P8 Simple Network Management Protocol
P9 SMS <-> Service Control Point/Service Node protocol
P0 HyperText Transfer Protocol P1 HTTP Server <-> "Back End Program" internal protocol P2 CallBroker Client <-> CallBroker Server protocol (AT&T system), or SCTP Client <-> Server protocol (Nortel system) P3 PINT User Agent <-> PINT Gateway protocol P4 Intra-Intelligent Network protocol (e.g., INAP) P5 Proprietary (INAP-based) Gateway-> I.IP protocol P6 Finger protocol P7 Digital Subscriber Signaling 1 protocol P8 Simple Network Management Protocol P9 SMS <-> Service Control Point/Service Node protocol
Lu, et. al. Informational [Page 14] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 14] RFC 2458 Pre-PINT Implementations November 1998
_____ _______ _____
|[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
|[---]| | [WSA] | |[FS.]|
|-----| | ! | |[-!-]|
| (p1) | |--\--|
| ! | ^
| ! | (p6)
| ! | \
| (p1) | \
| ! | \
|[Srvlt]| \
|___!___| \
! \
(p3) \
Internet ! !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.
PSTN/IN _______________!_________________ ____!_____ __________
|I [PktFlt] I| |[PktFlt]| |[PktFlt]|
|N Gateway N| | ! | | ! |
|A ___________________________ A| | ! | | ! |
|P | | P| | ! | |[SNMPAg]|
-(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] |
\ |d | [-^-] | d| |[------]| | [-^-] |
\ |__| ! |__| |________| |___!____|
\ ! !
[-v-] !-----------------(p9)-----------------!
[SSP]
[---]
___| |______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
_____ _______ _____ |[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]| |[---]| | [WSA] | |[FS.]| |-----| | ! | |[-!-]| | (p1) | |--\--| | ! | ^ | ! | (p6) | ! | \ | (p1) | \ | ! | \ |[Srvlt]| \ |___!___| \ ! \ (p3) \ Internet ! ! .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+. PSTN/IN _______________!_________________ ____!_____ __________ |I [PktFlt] I| |[PktFlt]| |[PktFlt]| |N Gateway N| | ! | | ! | |A ___________________________ A| | ! | | ! | |P | | P| | ! | |[SNMPAg]| -(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] | \ |d | [-^-] | d| |[------]| | [-^-] | \ |__| ! |__| |________| |___!____| \ ! ! [-v-] !-----------------(p9)-----------------! [SSP] [---] ___| |______ | | | /--\ | /--\ | ()/\() | ()/\() |__/__\ |____/__\
Figure 7: The Siemens Web Call Center
Figure 7: The Siemens Web Call Center
Lu, et. al. Informational [Page 15] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 15] RFC 2458 Pre-PINT Implementations November 1998
_____ _______
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
| ! |
| ! |
| (p1) |
| ! |
|[SSTPC]|-<----------------------------------
|___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[-v-] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
_____ _______ |[W3C]|----(p0)-->| [W3S] | |[---]| | [WSA] | |-----| | ! | | (p1) | | ! | | ! | | ! | | (p1) | | ! | |[SSTPC]|-<---------------------------------- |___!___| ! ! (p8) (p3) ! Internet ! v .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ PSTN/IN _______________!__________________________________ ____!_____ | [PktFlt] Service [PktFlt]| |[PktFlt]| | ! Node | | ! | | [SCF Adaptor] | | ! | | ! | |[SNMPAg]| |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | |[|--] [-^-] [---] | | [-^-] | |_|_____________!________________________________| |___!____| | ! ! [-v-] (p7) !-----------------(p9)-----------------! [CO.]____| [---] ___| |_______ | | | /--\ | /--\ | ()/\() | ()/\() |__/__\ |____/__\
Figure 8: The Lucent System
Figure 8: The Lucent System
Lu, et. al. Informational [Page 16] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 16] RFC 2458 Pre-PINT Implementations November 1998
_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/CBS]|
|[Adaptr]|
|___!____|
^
(p2)
_____ ___v____
|[CBC]| | [CBS] |
|[---]|<---(p2)-->| [---] |-<---------------------------------
|-----| |___!____| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
_____ ________ |[W3C]|----(p0)-->| [W3S] | |[---]| | [WSA] | |-----| | ! | | (p1) | | ! | |[WS/CBS]| |[Adaptr]| |___!____| ^ (p2) _____ ___v____ |[CBC]| | [CBS] | |[---]|<---(p2)-->| [---] |-<--------------------------------- |-----| |___!____| ! ! (p8) (p3) ! Internet ! v .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ PSTN/IN _______________!__________________________________ ____!_____ | [PktFlt] Service [PktFlt]| |[PktFlt]| | ! Node | | ! | | [SCF Adaptor] | | ! | | ! | |[SNMPAg]| |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | |[|--] [-^-] [---] | | [-^-] | |_|_____________!________________________________| |___!____| | ! ! [---] (p7) !-----------------(p9)-----------------! [CO.]____| [---] ___| |_______ | | | /--\ | /--\ | ()/\() | ()/\() |__/__\ |____/__\
Figure 9: The AT&T System
Figure 9: The AT&T System
Lu, et. al. Informational [Page 17] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 17] RFC 2458 Pre-PINT Implementations November 1998
_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/ ]|
|[ SCTPS]|
|[Adaptr]|
|___!____|
^
(p2)
_______ ___v___
|[SCTPC]| |[SCTPS]|
|[-----]| <-(p2)--> |[-----]|-<----------------------------------
|-------| |___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+.
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
_____ ________ |[W3C]|----(p0)-->| [W3S] | |[---]| | [WSA] | |-----| | ! | | (p1) | | ! | |[WS/ ]| |[ SCTPS]| |[Adaptr]| |___!____| ^ (p2) _______ ___v___ |[SCTPC]| |[SCTPS]| |[-----]| <-(p2)--> |[-----]|-<---------------------------------- |-------| |___!___| ! ! (p8) (p3) ! Internet ! v .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+. PSTN/IN _______________!__________________________________ ____!_____ | [PktFlt] Service [PktFlt]| |[PktFlt]| | ! Node | | ! | | [SCF Adaptor] | | ! | | ! | |[SNMPAg]| |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | |[|--] [-^-] [---] | | [-^-] | |_|_____________!________________________________| |___!____| | ! ! [---] (p7) !-----------------(p9)-----------------! [CO.]____| [---] ___| |_______ | | | /--\ | /--\ | ()/\() | ()/\() |__/__\ |____/__\
Figure 10: The Nortel System
Figure 10: The Nortel System
As these are independent systems developed by different groups, the names of the components, unsurprisingly, don't match. Some features are offered by one of the systems, while they aren't by others. However, there are a number of common features. All of the systems provide a Web-based interface (at least as an option), using "back end" programs to construct protocols to pass onwards to the Intelligent Network system.
As these are independent systems developed by different groups, the names of the components, unsurprisingly, don't match. Some features are offered by one of the systems, while they aren't by others. However, there are a number of common features. All of the systems provide a Web-based interface (at least as an option), using "back end" programs to construct protocols to pass onwards to the Intelligent Network system.
Lu, et. al. Informational [Page 18] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 18] RFC 2458 Pre-PINT Implementations November 1998
Several Intelligent Network Functional Entities are combined into a Service Node in the Lucent, AT&T , and Nortel systems, while in the Siemens scheme they are separate units. However, this is not particularly important for the provision of the services they offer.
Several Intelligent Network Functional Entities are combined into a Service Node in the Lucent, AT&T , and Nortel systems, while in the Siemens scheme they are separate units. However, this is not particularly important for the provision of the services they offer.
The main difference lies in whether or not the SCF is "aware" of the Internet interface and has been modified to be "complicit" in supporting these Internet requests. The Siemens approach was to re- use an existing SCP, providing a gateway function to translate as needed. The Lucent system used a "lighter weight" SCF adapter to terminate the Internet protocols, as the SCF was modified to support the Internet interface directly.
The main difference lies in whether or not the SCF is "aware" of the Internet interface and has been modified to be "complicit" in supporting these Internet requests. The Siemens approach was to re- use an existing SCP, providing a gateway function to translate as needed. The Lucent system used a "lighter weight" SCF adapter to terminate the Internet protocols, as the SCF was modified to support the Internet interface directly.
The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate protocol (labeled p2) that allows an alternative to the Web based interface supported by the others. This protocol matches the "CallBroker Client API", or the "SCTP Client API". These options provide for a bi-directional protocol, with indications sent from the Call Broker or SCTP Server to the Client as needed. This is not easily possible using an HTTP-based scheme (and in the Siemens case, a dedicated Finger client/server pair was used to emulate such an interface)
The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate protocol (labeled p2) that allows an alternative to the Web based interface supported by the others. This protocol matches the "CallBroker Client API", or the "SCTP Client API". These options provide for a bi-directional protocol, with indications sent from the Call Broker or SCTP Server to the Client as needed. This is not easily possible using an HTTP-based scheme (and in the Siemens case, a dedicated Finger client/server pair was used to emulate such an interface)
The protocol between the Internet server and the Intelligent Network (labeled p3 in the above diagrams) differs in each of the systems. One of the main aims of future work will be to develop a common protocol that will support the services offered, so that the p3 interface will allow different implementations to inter-operate. In the Lucent, Siemens, and Nortel systems, this was an "internal" protocol, as it was carried between entities within the Service Node or Gateway.
The protocol between the Internet server and the Intelligent Network (labeled p3 in the above diagrams) differs in each of the systems. One of the main aims of future work will be to develop a common protocol that will support the services offered, so that the p3 interface will allow different implementations to inter-operate. In the Lucent, Siemens, and Nortel systems, this was an "internal" protocol, as it was carried between entities within the Service Node or Gateway.
Other contrasts between the systems lie in the support for Internet access to Service Management, and access to the Internet by Special Resources. Internet Management access was most developed in the Lucent system, in which a Simple Network Management Protocol (SNMP) agent was provided to allow inter-operation with the SMS controlling the Service Node. In the Siemens scheme, the SMS had no direct Internet access; any management actions were carried out within the normal PSTN management activities. As for Internet access to special resources, this was only required by the Siemens system as part of its support for Call Center agent notification. Equivalent functionality would be provided in the AT&T and Nortel systems as mentioned above, and this would in turn be associated with event notifications being sent as part of their (p3) Internet/IN protocol. These differences reflect the different emphases in the products as they were developed; again, future work will have to ensure that common protocols can be used to support the chosen services fully.
Other contrasts between the systems lie in the support for Internet access to Service Management, and access to the Internet by Special Resources. Internet Management access was most developed in the Lucent system, in which a Simple Network Management Protocol (SNMP) agent was provided to allow inter-operation with the SMS controlling the Service Node. In the Siemens scheme, the SMS had no direct Internet access; any management actions were carried out within the normal PSTN management activities. As for Internet access to special resources, this was only required by the Siemens system as part of its support for Call Center agent notification. Equivalent functionality would be provided in the AT&T and Nortel systems as mentioned above, and this would in turn be associated with event notifications being sent as part of their (p3) Internet/IN protocol. These differences reflect the different emphases in the products as they were developed; again, future work will have to ensure that common protocols can be used to support the chosen services fully.
Lu, et. al. Informational [Page 19] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 19] RFC 2458 Pre-PINT Implementations November 1998
5. IN-Based Solutions
5. IN-Based Solutions
5.1 The Lucent System
5.1 The Lucent System
Figure 11 depicts the overall interconnection architecture of the Lucent prototype in support of the four PINT services. The IN-based architecture utilizes the Service Node and Service Management System in addition to the Web server, which enables Web-based access to the PINT services. This section summarizes the roles of these elements (complemented by a click-to-dial-back service scenario), outlines the interfaces of Web Server-Service Node and Web Server-Service Management System (i.e., the interfaces A & B), and addresses the common security concerns.
Figure 11 depicts the overall interconnection architecture of the Lucent prototype in support of the four PINT services. The IN-based architecture utilizes the Service Node and Service Management System in addition to the Web server, which enables Web-based access to the PINT services. This section summarizes the roles of these elements (complemented by a click-to-dial-back service scenario), outlines the interfaces of Web Server-Service Node and Web Server-Service Management System (i.e., the interfaces A & B), and addresses the common security concerns.
5.1.1 Roles of the Web Server, Service Node, and Service Management
System
5.1.1 Roles of the Web Server, Service Node, and Service Management System
Web Server
Web Server
The Web Server stores the profiles of content providers as well as pre-registered users. The content provider profile contains information such as content provider ID, telephone number, and fax number. In addition, the profile may also include service logic that specifies, for example, the telephone (or fax) number to be reached based on time of the day, day of the week, or geographical location of the user, and the conditions to accept the charge of the calls.
The Web Server stores the profiles of content providers as well as pre-registered users. The content provider profile contains information such as content provider ID, telephone number, and fax number. In addition, the profile may also include service logic that specifies, for example, the telephone (or fax) number to be reached based on time of the day, day of the week, or geographical location of the user, and the conditions to accept the charge of the calls.
Similar to the content provider profile, the pre-registered user profile contains information such as user name, password, telephone number, and fax number. The last two pieces of information can also be linked to time of the day and day of the week so the user can be reached at the appropriate telephone (or fax) number accordingly.
Similar to the content provider profile, the pre-registered user profile contains information such as user name, password, telephone number, and fax number. The last two pieces of information can also be linked to time of the day and day of the week so the user can be reached at the appropriate telephone (or fax) number accordingly.
Service Node
Service Node
Situated in the PSTN, the SN, like the SCP, performs the service control function [1, 2, 3]. It executes service logic and instructs switches on how to complete a call. The SN also performs certain switching functions (like bridging of calls) as well as a set of specialized functions (like playing announcements, voice recognition and text-to-speech conversion).
Situated in the PSTN, the SN, like the SCP, performs the service control function [1, 2, 3]. It executes service logic and instructs switches on how to complete a call. The SN also performs certain switching functions (like bridging of calls) as well as a set of specialized functions (like playing announcements, voice recognition and text-to-speech conversion).
Service Management System
Service Management System
The SMS performs administration and management of service logic and customer-related data on the SN. It is responsible for the replication of content provider profiles and provision of these data on the SN. These functions are non-real time.
The SMS performs administration and management of service logic and customer-related data on the SN. It is responsible for the replication of content provider profiles and provision of these data on the SN. These functions are non-real time.
Lu, et. al. Informational [Page 20] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 20] RFC 2458 Pre-PINT Implementations November 1998
Web Users
____________
O -------------------------- | Internet |-------------------
------------ |
|
|
---------------- -------------- ------------
| Service Node | D | Service | B |Web Server|
| (SN) |------------| Management |---------------| |
| | |System (SMS)| | |
| | A -------------- | |
| |-----------------------------------------| |
---------------- ------------
| |
| I | C
| |
----------- ---------
|Mobile | |Central|
|Switching| |Office |
| Center | ---------
----------- |
| |
| |
O O
Web Users ____________ O -------------------------- | Internet |------------------- ------------ | | | ---------------- -------------- ------------ | Service Node | D | Service | B |Web Server| | (SN) |------------| Management |---------------| | | | |System (SMS)| | | | | A -------------- | | | |-----------------------------------------| | ---------------- ------------ | | | I | C | | ----------- --------- |Mobile | |Central| |Switching| |Office | | Center | --------- ----------- | | | | | O O
Mobile Wireline PSTN
Users Users
Mobile Wireline PSTN Users Users
Figure 11: Overall Interconnection Architecture of the Lucent System
Figure 11: Overall Interconnection Architecture of the Lucent System
5.1.2 A Click-to-Dial-Back Service Scenario
5.1.2 A Click-to-Dial-Back Service Scenario
A Web user, who has simultaneous access to the Web and telephone services (this can be achieved, for example, by having an ISDN connection), is browsing through a sales catalogue and deciding to speak to a sales representative.
ウェブユーザ(ウェブと電話サービス(例えば、ISDN接続があることによって、これを達成できる)に同時アクセスを持っている)は、販売カタログをブラウズして、セールスレップと話すと決めています。
When the Web user clicks a button inviting a telephone call from the sales office, the Web Server sends a message to the SN over the A interface, thus crossing the Internet-to-PSTN boundary. By matching the information received from the Web Server with the content provider profile that had been previously loaded and activated by the SMS over the D interface, the SN recognizes the signal.
ウェブユーザが営業所から通話を招待するボタンをクリックするとき、ウェブServerはAインタフェースの上のSNにメッセージを送ります、その結果、インターネットからPSTNへの境界に交差しています。 以前にロードされたコンテンツプロバイダープロフィールでウェブServerから受け取られて、Dインタフェースの上のSMSによって活性化した情報を合わせることによって、SNは信号を認識します。
At this point, the SN calls the Web user. The user answers the call, hears an announcement, e.g., "Please wait, while we are connecting you to the sale agent", and is waiting to be connected to the sale agent. Then the SN invokes service logic as indicated in the profile.
ここに、SNは、ウェブユーザに電話をします。 ユーザは、電話口に出て、例えば発表を聞きます。「私たちが販売エージェントにあなたに接している間、待ちを喜ばせ」て、販売エージェントに接されるのを待っています。 そして、SNはプロフィールにみられるようにサービス論理を呼び出します。
Lu, et. al. Informational [Page 21] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [21ページ]情報のRFC2458プレパイント実装1998年11月
The execution of this logic selects an appropriate sales agent to call based on the time of the day. It is 8 P.M. in New York where the Web user is located, and the New York sales office has closed. The San Francisco office, however, is still open, and so the SN makes a call to an agent in that office. Finally, the SN bridges the two calls and establishes a two-party call between the sales agent and the Web user.
この論理の実行は、適切な販売代理店が1日の時間に基づいて電話をするのを選択します。 ウェブユーザが位置していて、ニューヨーク営業所が休んだニューヨークで午後8時です。 しかしながら、サンフランシスコオフィスがまだ開放されているので、SNはそのオフィスでエージェントに電話をかけます。 最終的に、SNは販売代理店とウェブユーザの間で2つの呼び出しをブリッジして、2パーティーの呼び出しを確立します。
5.1.3 Web Server-Service Node Interface
5.1.3 ウェブサーバサービスノードインタフェース
Lucent developed the Service Support Transfer Protocol (SSTP) for communications between the SN and Web Server. SSTP is of a request/response type running on top of a reliable transport layer, such as TCP. The Web Server sends a request to the SN to invoke a service and the SN responds with a message indicating either success or failure. Note that SSTP engages only the service control function [1, 2, 3] of the SN.
透明である、開発されて、信頼できるトランスポート層の上を走る要求/応答タイプにはSNとウェブServer. SSTPとのコミュニケーションのためのService Support Transferプロトコル(SSTP)があります、TCPなどのように。 ウェブServerはサービスを呼び出すために要求をSNに送ります、そして、メッセージが成功か失敗のどちらかを示していて、SNは応じます。 SSTPがSNのサービス制御機能[1、2、3]だけを従事させることに注意してください。
5.1.3.1 Web Server to Service Node
5.1.3.1 サービスノードへのウェブサーバー
In this direction, three kinds of messages may be sent: the Transaction Initiator message, the Data Message, and the End of Data message.
この方向に、3種類のメッセージを送るかもしれません: DataメッセージのTransaction Initiatorメッセージ、Data Message、およびEnd。
The latter two messages are needed if the service to be invoked involves data (such as the case in click-to-fax, click-to-fax-back and voice-access-to-content). This was so designed to handle the varying size of data and to ensure that the size of each stream is within the allowable size of the underlying transport packet data unit (imposed by some implementations of TCP/IP).
呼び出されるべきサービスがデータ(クリックからファックス、クリックからファックス後部、および内容への声のアクセスにおけるケースなどの)にかかわるなら、後者の2つのメッセージが必要です。 データの異なったサイズを扱って、基本的な輸送パケットデータ単位(TCP/IPのいくつかの実装で、課される)の許容できるサイズの中にそれぞれのストリームのサイズがあるのを保証するほどこれは設計されました。
a. Transaction Initiator
a。 トランザクション創始者
This message provides all the necessary information but data for invoking a service. It includes the following information elements:
このメッセージは、すべての必要事項を提供して、サービスを呼び出すためのデータを提供します。 それは以下の情報要素を含んでいます:
+ Transaction ID, which uniquely specifies a service request. The same transaction ID should be used for all the accompanying data- related messages, if the service request involves data. One way for generating unique transaction IDs is to concatenate the information: date, time, Web Server ID (uniquely assigned for each one connected to the SN), and transaction sequence number (a cyclic counter incremented for each service request).
+ Transaction ID。(そのIDは唯一サービスのリクエストを指定します)。 サービスのリクエストがデータにかかわるなら、同じトランザクションIDは話されたすべての付随のデータメッセージに使用されるべきです。 ユニークなトランザクションIDを生成するための1つの方法は情報を連結することです: 日付、時間、ウェブServer ID(SNに接続されたそれぞれのために唯一割り当てられる)、およびトランザクション一連番号(各サービスのリクエストのために増加された周期的なカウンタ)。
+ Service ID, which specifies the service to be invoked. The service may be click-to-dial-back, click-to-fax, click-to-fax-back or voice- access-to-content.
+ Service ID。(そのIDは、呼び出されるためにサービスを指定します)。 サービスは、声のアクセスからクリックからダイヤル後部、クリックからファックス、クリックからファックス後部または内容であるかもしれません。
Lu, et. al. Informational [Page 22] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [22ページ]情報のRFC2458プレパイント実装1998年11月
+ Content Provider ID, which uniquely represents the content provider. This information is the key to accessing the content provider's service logic and data on the SN.
+ 満足しているProvider ID。(そのIDは唯一コンテンツプロバイダーを代表します)。 この情報はSNに関するコンテンツプロバイダーのサービス論理とデータにアクセスするキーです。
+ Content Provider Directory Number, which is the telephone or fax number of the content provider to be called through the PSTN.
+ 内容ProviderディレクトリNumber。(そのNumberはPSTNを通して呼ばれるコンテンツプロバイダーの電話かファックス番号です)。
+ User Directory Number, which is the telephone or fax number of the user requesting the service.
+ ユーザディレクトリNumber。(そのNumberはサービスを要求するユーザの電話かファックス番号です)。
+ Billed Party, which specifies the party (either the user or content provider), to be billed.
+ 請求されたパーティ。(そのパーティは、請求されるために、パーティー(ユーザかコンテンツプロバイダー)を指定します)。
In addition, optional parameters may be sent from the Web Server to the SN. For example, a retry parameter may be sent to specify the number of times the SN will attempt to complete a service request upon failure before the transport connection times out.
さらに、ウェブServerからSNに任意のパラメタを送るかもしれません。 例えば、SNが、輸送接続回数の前に外で失敗にサービスのリクエストを完成するのを試みるという回の数を指定するために再試行パラメタを送るかもしれません。
b. Data Message
b。 データメッセージ
This message provides the (encapsulated) user data part of a service request. For example, in the case of click-to-fax-back such data are the content to be faxed to the user. Each message is composed of the transaction ID and a data segment. The transaction ID must be the same as that of the transaction initiator part first invoking the service.
このメッセージはサービスのリクエストの(要約します)利用者データ部分を提供します。 例えば、クリックからファックス後部の場合では、そのようなデータはファックスでユーザに送られる内容です。 各メッセージはトランザクションIDとデータ・セグメントで構成されます。 トランザクションIDは最初にサービスを呼び出すトランザクション創始者部分のものと同じであるに違いありません。
c. End of Data Message
c。 データメッセージの終わり
This message contains the transaction ID and the end of data delimiter. The transaction ID is the same as that of the relevant transaction initiator message.
このメッセージはトランザクションIDとデータのデリミタの終わりを含んでいます。 トランザクションIDは関連トランザクション創始者メッセージのものと同じです。
5.1.3.2 Service Node to Web Server
5.1.3.2 ウェブサーバーへのサービスノード
The SN must respond to a service request from the Web Server. The response message consists of the information elements:
SNはウェブServerからサービスのリクエストに応じなければなりません。応答メッセージは情報要素から成ります:
transaction ID, service type, result, time, and error code.
トランザクションID、サービスタイプ、結果、時間、およびエラーコード。
+ Transaction ID, which is the same as that of the original service request.
+ Transaction ID。(そのIDはオリジナルのサービスのリクエストのものと同じです)。
+ Service Type, which is the same as that of the original service request.
+ サービスType。(そのTypeはオリジナルのサービスのリクエストのものと同じです)。
+ Result, which is either success or failure.
+ 結果。(成功かその結果は失敗のどちらかです)。
Lu, et. al. Informational [Page 23] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [23ページ]情報のRFC2458プレパイント実装1998年11月
+ Time, which indicates the time of the day completing the request.
+時間。(その時間は、要求を終了しながら、1日の時間を示します)。
+ Error Code, which gives the reason for failure. Possible reasons for failure are content provider telephone (or fax) busy, content provider telephone (or fax) no answer, user telephone busy, user refusal to complete, user no answer, nuisance control limit reached, and content provider telephone (or fax) not in the SN database.
+ 誤りCode。(そのCodeは失敗の理由を明かします)。 失敗の可能な理由はコンテンツプロバイダー電話(または、ファックス)忙しいです、コンテンツプロバイダー電話(または、ファックス)ノー答え、ユーザ電話忙しいです、終了するユーザ拒否、ユーザノー、は答えます、達した迷惑管理限界ということであり、コンテンツプロバイダーはSNデータベースでないところの電話(または、ファックス)です。
5.1.3.3 Usage Scenarios: Click-to-Fax and Click-to-Fax-Back
5.1.3.3 用法シナリオ: ファックスにクリックしてください、そして、クリックして、ファックスで後部を送ってください。
For the click-to-fax and click-to-fax-back services, the Lucent system implemented only the case where the data to be sent as facsimile reside in the Web server. There are at least three messages that need to be sent from the Web server to the Service Node for these services.
クリックからファックスとクリックからファックス後部に対するサービスのために、Lucentシステムはファクシミリとして送られるデータがウェブサーバであるケースだけを実装しました。これらのサービスのためにウェブサーバからService Nodeに送られる必要がある少なくとも3つのメッセージがあります。
The first message is the Transaction Initiator that identifies the service type as well as a unique Transaction ID. It also includes the sender/receiver fax number.
最初のメッセージはまた、サービスタイプがユニークなTransaction IDであると認識するTransaction Initiatorです。 また、それは送付者/受信機ファックス番号を含んでいます。
The next is one or more messages of the data to be faxed. Each message carries the same unique Transaction ID as the above.
次のことはデータがファックスで送られる1つ以上のメッセージです。 各メッセージは上記の同じユニークなTransaction IDを運びます。
Last comes the end of message. It consists of the Transaction ID (again, the same as that of the messages preceding it) and the end of data delimiter.
最後に、メッセージの終わりは来ます。 それはTransaction ID(再びそれに先行するメッセージのものと同じくらい)とデータのデリミタの終わりから成ります。
Upon receiving these messages, the Service Node, equipped with the special resource of a fax card, converts the data into the G3 format, calls the receiver fax, and sends back the result to the Web server immediately. Note that the receiver fax busy or no answer is interpreted as failure. Further, while the receiver fax answering the call is interpreted as success, it does not necessarily mean that the fax would go through successfully.
これらのメッセージを受け取ると、ファックスカードの特別なリソースを備えていたService Nodeはすぐに、ウェブサーバにG3形式にデータを変換して、受信機ファックスを呼んで、結果を返送します。 受信機ファックスがあると忙しくするか、または答えない注意は失敗を解釈しました。 さらに、電話口に出る受信機ファックスが成功として解釈されている間、それは、必ずファックスが首尾よく通られることを意味するというわけではありません。
5.1.4 Web Server-SMS Interface and SNMP MIB
5.1.4 ウェブサーバ-SMSインタフェースとSNMP MIB
This interface is responsible for uploading the content provider profile from the Web Server to the SMS and for managing the information against any possible corruption. The SN verifies the Content Provider ID and the Content Provider Directory Number sent by the Web Server with the content provider profile pre-loaded from the SMS.
このインタフェースはコンテンツプロバイダーがウェブServerからSMSまで輪郭を描くアップロードとどんな可能な不正に対して情報を管理するのに責任があります。 SNはコンテンツプロバイダープロフィールがSMSからプレロードされている状態でウェブServerによって送られたContent Provider IDとContent ProviderディレクトリNumberについて確かめます。
The content provider profile was based on ASN.1 [4] structure and SNMP [5] was used to set/get the object identifiers in the SMS database.
コンテンツプロバイダープロフィールはASN.1[4]構造に基づいて、SNMP[5]は、SMSデータベースのオブジェクト識別子を設定するか、または得るのに使用されました。
Lu, et. al. Informational [Page 24] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [24ページ]情報のRFC2458プレパイント実装1998年11月
Following is an example of the simple MIB available on the SMS.
以下に、SMSで利用可能な簡単なMIBに関する例があります。
inwebContProviderTable OBJECT-TYPE
SYNTAX SEQUENCE OF InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A table containing Content Provider profiles "
:= { inweb 1}
inwebContProviderTable OBJECT-TYPEのSYNTAX SEQUENCE OF InwebContProviderEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述「Content Providerプロフィールを含むテーブル」:=inweb1
inwebContProviderEntry OBJECT-TYPE
SYNTAX InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A conceptual row of the inweb. Each row
contains profile of one Content Provider"
INDEX { inwebSmsNumber }
:= { inwebContProviderTable 1 }
inwebContProviderEntry OBJECT-TYPE SYNTAX InwebContProviderEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「inwebの概念的な行。」 「各行は1Content Providerのプロフィールを含んでいる」INDEX inwebSmsNumber:=inwebContProviderTable1
InwebContProviderEntry := SEQUENCE {
inwebSmsNumber Integer32,
inwebContentProviderId Integer32,
inwebContentProviderPhoneNumber Integer32,
inwebContentProviderFaxNumber Integer32
}
InwebContProviderEntry:=系列inwebSmsNumber Integer32、inwebContentProviderId Integer32、inwebContentProviderPhoneNumber Integer32、inwebContentProviderFaxNumber Integer32
inwebSmsNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" Serial number of the SMS - used for SNMP indexing "
:= { inwebContProviderEntry 1 }
inwebSmsNumber OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述「SMS--SNMPインデックスに使用される通し番号」:=inwebContProviderEntry1
inwebContentProviderId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" A number that uniquely identifies each Content
Provider "
:= { inwebContProviderEntry 2 }
inwebContentProviderId OBJECT-TYPE SYNTAX Integer32マックス-ACCESSはSTATUSの現在の記述「唯一各Content Providerを特定する数」:=を読書して作成します。inwebContProviderEntry2
inwebContentProviderPhoneNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
inwebContentProviderPhoneNumber OBJECT-TYPE SYNTAX Integer32マックス-ACCESSはSTATUS海流を読書して引き起こします。
Lu, et. al. Informational [Page 25] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [25ページ]情報のRFC2458プレパイント実装1998年11月
DESCRIPTION
" Content Provider's Phone Number "
:= { inwebContProviderEntry 3 }
記述「コンテンツプロバイダーの電話番号」:=inwebContProviderEntry3
inwebContentProviderFaxNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Fax Number "
:= { inwebContProviderEntry 4 }
inwebContentProviderFaxNumber OBJECT-TYPE SYNTAX Integer32マックス-ACCESSはSTATUSの現在の記述「コンテンツプロバイダーのファックス番号」:=を読書して作成します。inwebContProviderEntry4
5.1.5 Security Considerations
5.1.5 セキュリティ問題
The Lucent prototype addressed the security issues concerning the interface between the Web Server and the SN. Those concerning the interface between the Web Server and SMS, which was based in SNMP, were handled by the built-in security features of SNMP.
Lucentプロトタイプは、ウェブServerとSNとのインタフェースに関してセキュリティが問題であると扱いました。 SNMPに基づいたウェブServerとSMSとのインタフェースに関するそれらはSNMPの内蔵のセキュリティー機能によって扱われました。
+ Secure Communication Links
+ 安全な通信リンク
If the Network Operator (PSTN provider) is also the Web Service provider, the Web Server and SN/SMS will communicate over a corporate intranet. This network is almost always protected by the corporation's firewall and so can be deemed secure. This was the case handled by the Lucent prototype.
また、Network Operator(PSTNプロバイダー)がウェブServiceプロバイダーであるなら、ウェブServerとSN/SMSは企業イントラネットの上で交信するでしょう。 ほとんどいつも会社のファイアウォールによって保護されるので、安全であるとこのネットワークを考えることができます。 これはLucentプロトタイプによって扱われたそうでした。
Nevertheless, if different corporations serve as the Network Operator and the Web Service Provider, then it is likely that there may not exist a dedicated secure communication link between the Web Server and SN/SMS. This raises serious security considerations. One possible solution is to use Virtual Private Networks (VPN). VPN features support authentication of the calling and called parties and encryption of the messages sent over insecure links (such as those on the Internet).
それにもかかわらず、異なった会社がNetwork OperatorとウェブService Providerとして機能するなら、ウェブServerの間のひたむきな安全な通信リンクとSN/SMSは存在しそうにはありません。これは重大なセキュリティ問題を提起します。 1つの可能なソリューションはVirtual兵士のNetworks(VPN)を使用することです。 VPNの特徴は不安定なリンク(インターネットのそれらなどの)の上に送られたメッセージの呼ぶこと、被呼者、および暗号化の認証をサポートします。
+ Non-Repudiation
+ 非拒否
All transactions were logged on both the Web Server and the Service Node to account for all operations in case of doubt or dispute. The log information on the SN may also be used to generate bills.
すべてのトランザクションが、疑わしい場合はすべての操作を説明するか、または議論するためにウェブServerとService Nodeの両方に登録されました。 また、SNに関するログ情報は、請求書を作るのに使用されるかもしれません。
+ Malicious Requests of Users
+ ユーザの悪意がある要求
A user may make repeated requests to a content provider directory number maliciously. This scenario was handled by setting a Nuisance Control Limit (NCL) on either the SN or the Web Server or both. The NCL has two parameters: one defining the number of requests from a
ユーザは陰湿にコンテンツプロバイダーディレクトリ番号まで度重なる要求するかもしれません。 このシナリオは、SNかウェブServerか両方のどちらかにNuisance Control Limit(NCL)をけしかけることによって、扱われました。 NCLには、2つのパラメタがあります: aから要求の数を定義する1つ
Lu, et. al. Informational [Page 26] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [26ページ]情報のRFC2458プレパイント実装1998年11月
user and the other the period over which these requests takes place.
ユーザ、もう片方がこれらの要求が行われる期間をそうします。
A user may also attempt to request a call from a directory number other than that of a content provider. This scenario was handled by verifying the directory number (and the content provider ID) against the database on the SN containing all the content provider information. If the directory number (or the content provider ID) was not in the database, the request would be rejected.
また、ユーザは、コンテンツプロバイダーのもの以外のディレクトリ番号から呼び出しを要求するのを試みるかもしれません。 このシナリオは、すべてのコンテンツプロバイダー情報を含んでいて、SNでデータベースに対してディレクトリ番号(そして、コンテンツプロバイダーID)について確かめることによって、扱われました。 ディレクトリ番号(または、コンテンツプロバイダーID)がデータベースにないなら、要求は拒絶されるでしょうに。
5.2 Siemens Web Call Center
5.2 ジーメンスウェブコールセンター
5.2.1 Service Description
5.2.1 サービス記述
The Web Call Center is an Intelligent Network System that accepts requests from Internet nodes for services to be provided on the PSTN. As the name suggests, it was designed to support a cluster of services that, taken together, provide a subset of the features of a Call Center, with almost all user interactions provided via World Wide Web requests and responses. See the appendix for a background description of Call Center Features.
ウェブCallセンターはサービスがPSTNで提供されるインターネット接続装置から要求を受け入れるIntelligent Network Systemです。 名前が示すように、それは一緒に取って、Callセンターの特徴の部分集合を提供するサービスのクラスタを支えるように設計されました、WWW要求と応答でほとんどすべてのユーザ相互作用を供給していて。 CallセンターFeaturesのバックグラウンド記述に関して付録を見てください。
From an Intelligent Network perspective, there are a number of services that, when combined, provide the Call Center features. The Call Center features as implemented supported the scenario in which a customer makes a request to be called back by an agent at a time of the customer's choosing to discuss an item of interest to him or her. The agent will be selected based on his or her availability and expertise in this topic; the agent will be told whom he or she is calling and the topic of interest, and then the agent will be connected to the customer.
Intelligent Network見解から、結合されるとCallセンターの特徴を提供する多くのサービスが来ています。 センターが実装されるように特集するCallは顧客がエージェントによってコールバックされるという一度に顧客が、その人にとって、興味深い項目について議論するのを選ぶ要求をするシナリオをサポートしました。 エージェントはこの話題におけるその人の有用性と専門的技術に基づいて選ばれるでしょう。 その人が、だれに電話をしているか、そして、興味がある話題はエージェントに言われるでしょう、そして、次に、エージェントは顧客に接されるでしょう。
In addition, the individual services that were deployed to support this scenario provided support for management of the list of available agents as well. This involved allowing the agent to "log into" and "out of" the system and to indicate whether the agent was then ready to handle calls to the customer. The list of services, as seen from a user perspective, follows.
さらに、このシナリオをサポートするために配布された個々のサービスはまた、手があいているエージェントのリストの管理のサポートを提供しました。 これは、「ログインする」エージェントと“out of"にシステムを許容することを伴いました、そして、次に、エージェントが準備ができていたかどうかを示すのがハンドルに顧客に呼びかけます。 ユーザ見解から見られるサービスのリストは従います。
The services support:
サービスサポート:
i) Customer Request service - the customer explores a corporate Web site, selects a link that offers to request an agent to call the customer back and then is redirected to the Web Call Center server. This presents customer with a form asking for name, the telephone number at which he or she wishes to be called, and the time at which the call is to be made. Note will also be made of the page to which the customer was referred to when he or she was redirected. Once the form has been returned, the customer receives an acknowledgment page
i) 顧客は、法人のウェブサイトを探検して、顧客に電話し直すようエージェントに要求すると申し出るリンクを選択して、次に、ウェブCallセンターサーバに向け直されます。顧客Requestサービス--これは、名前、その人に電話をしたい電話番号、および作られる呼び出しがことである時を求めながら、フォームを顧客に与えます。 また、メモはその人が向け直されたとき顧客が差し向けられたページで作られるでしょう。 いったんフォームを返すと、顧客は承認ページを受けます。
Lu, et. al. Informational [Page 27] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [27ページ]情報のRFC2458プレパイント実装1998年11月
listing the parameters he or she has entered.
パラメタをリストアップして、その人は入りました。
ii) Agent Registration/Logon - An agent requests a "login" page on the Web Call Center server. The service checks whether it has a record of an agent present at the Internet node from which th call is made. If not, then the caller will be sent a form allowing him or her to enter the service identity, the company's agent identifier and password. On return, the service identity and company agent identifier will be checked against a list of known identities. If found, the password will be checked, and if this matches the record held by the service then a new session record is made of this identity and the Internet node from which the call has been made.
ii) エージェントRegistration/はログオンします--エージェントはウェブCallセンターサーバで「ログイン」ページを要求します。サービスが、それにはインターネット接続装置に出席しているエージェントの記録があるかどうかチェックする、どれ、電話を第かけるか。 そうでなければ、そして、その人が会社のサービスのアイデンティティ、エージェント識別子、およびパスワードを入力できるフォームを訪問者に送るでしょう。 リターンのときに、サービスのアイデンティティと会社のエージェント識別子は知られているアイデンティティのリストに対してチェックされるでしょう。 見つけられると、パスワードはチェックされるでしょう、そして、これがサービスで保持された記録に合っているなら、新しいセッション記録は電話をかけてあるこのアイデンティティとインターネット接続装置で作られます。
NB: This is very similar to the Universal Personal Telecommunications (UPT) service feature "register for incoming calls". It implies that the identified person has exclusive use of the Internet node from that point onwards, so messages for them can be directed there.
ネブラスカ: これは「かかってきた電話に登録する」というUniversalパーソナルTelecommunications(UPT)サービス機能と非常に同様です。 それが、特定された人にはそのポイントからのインターネット接続装置の専用が前方へあるのを含意するので、そこでそれらへのメッセージを指示できます。
iii) Agent Ready - an agent who has already logged on can indicate that he or she is ready by requesting an appropriate "ready" page on the Web Call Center Server. The service will match the agent by the Internet node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. It will mark them as being ready to handle calls in its list of available agents (with their pre-defined skill set).
iii) 既にログオンしたエージェントは、その人がウェブCallセンターServerで適切な「準備ができる」ページを要求することによって準備ができているのを示すことができます。エージェントReady--サービスはウェブ要求と共に「アクティブな」エージェントのリストに対して渡されたインターネット接続装置IdentifierとエージェントIdentityでエージェントに合うでしょう。 扱う準備ができているのが手があいているエージェント(彼らの事前に定義されたスキルセットがある)のリストを回収するとき、それはそれらをマークするでしょう。
iv) Agent Not Ready - an agent can request an appropriate "ready" page on the Web Call Center Server to indicate that he or she is temporarily not ready to handle calls.
iv) エージェントNot Ready--エージェントは、ウェブCallセンターでその人を一時呼び出しを扱う準備ができていないのを示すようServerに適切な「準備ができる」ページ要求できます。
v) Agent Logoff - an agent can request an appropriate "Logout" page on the Web Call Center Server to indicate that he or she is no longer associated with a particular Internet node. The service will match the agent by the Internet Node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. Once found, the session record for that agent is removed and the caller is notified of this with an acknowledgment page.
v) エージェントLogoff--エージェントは、ウェブCallセンターでその人がもう特定のインターネット接続装置に関連していないのを示すようServerに「ログアウトしてください」という適切なページ要求できます。 サービスはウェブ要求と共に「アクティブな」エージェントのリストに対して渡されたインターネットNode IdentifierとエージェントIdentityでエージェントに合うでしょう。 いったん見つけられると、そのエージェントへのセッション記録は取り除かれます、そして、訪問者は承認ページでこれについて通知されます。
NB: This is very similar to the UPT "unregister" service feature.
ネブラスカ: これはUPT"「非-レジスタ」"サービス機能と非常に同様です。
vi) Call Center Agent Selection and Notification - When the time that the customer selected has arrived and an available agent with the right skills has been selected from the appropriate list, this service will send a notification to the Internet node associated with that agent. A dedicated server is assumed to be running on the agent's machine that, on receiving the notification, triggers the agent's browser into requesting a "Agent Call In" page from the Web Call Center Server. Once the agent's machine has made this request,
vi) センターをエージェントSelectionとNotificationと呼んでください--顧客が選択した時間が来て、適切な技術の手があいているエージェントが適切なリストから選ばれたとき、このサービスはそのエージェントに関連しているインターネット接続装置に通知書を送るでしょう。 通知を受け取るとき「エージェント呼び出しコネ」を要求するのにエージェントのブラウザの引き金となるエージェントのマシンで動いて、ウェブCallセンターからServerを呼び出してください。専用サーバはエージェントのマシンが一度、この要求をしたことがあるということであると思われます。
Lu, et. al. Informational [Page 28] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [28ページ]情報のRFC2458プレパイント実装1998年11月
he or she will be told that there is a customer to call.
その人は呼ぶ顧客がいると言われるでしょう。
NB: This is similar to a "Message Waiting" or "Wake Up Call" service.
ネブラスカ: これは「メッセージの待ち」か「モーニングコール」サービスと同様です。
Note: As implemented, the agent is led automatically into the following service (the returned Web page includes an automatic reload command).
以下に注意してください。 実装されるように、エージェントは自動的に以下のサービスに導かれます(返されたウェブページは自動再び荷を積む指令を含んでいます)。
vii) Agent Instruction - a selected agent makes a request of the "Customer Processing" page on the Web Call Center Server. The Internet node Identifier and Agent Identity the agent uses will be matched against a list of agents expected to handle calls, and the instructions for the calls will be returned to the agent.
vii) 選択されたエージェントはウェブにおける「顧客処理」ページの要求をCallセンターServerにします。エージェントInstruction--エージェントが使用するインターネット接続装置IdentifierとエージェントIdentityは呼び出しを扱うと予想されたエージェントのリストに取り組ませて、呼び出しのための指示をエージェントに返すでしょう。
NB: This is similar to a "Voice Mail Replay" message service, but in this case the message is automatically generated; there is no associated voice mail record feature accessible.
ネブラスカ: これは「ボイスメール再生」メッセージサービスと同様ですが、この場合、メッセージは自動的に生成されます。 どんなアクセス可能なボイスメールの関連記録機能もありません。
Note: As implemented, the instructions page will include a number of buttons, allowing the agent to view the page the customer was looking at when he or she made the request, and to trigger the customer callback (as described next).
以下に注意してください。 実装されるように、指示ページは多くのボタンを含むでしょう、エージェントがその人が要求をしたとき、顧客が見ていたページを見て、顧客コールバックの引き金となるのを許容して(次に説明されるように)。
ix) Agent/Customer Telephony Callback - the agent will make a request of a "dial-back" page on the Web Call Center Server. The Internet node Identifier and Agent Identity he or she uses will be matched against a list of agents expected to handle calls, and, when the appropriate records have been found, the service will make the telephone call through to the customer and then connect the agent to this telephone call (using the telephone number registered in the respective Call Center service record).
ix) エージェントはウェブにおける「ダイヤル逆」ページの要求をCallセンターServerにするでしょう。エージェント/顧客Telephony Callback--その人が使用するインターネット接続装置IdentifierとエージェントIdentityが呼び出しを扱うと予想されたエージェントのリストに取り組まされて、適切な記録が見つけられたとき、サービスは、通話を顧客にとって突き抜けるようにして、次に、この通話にエージェントを接続するでしょう(電話番号を使用するのはそれぞれのCallセンター人事記録に登録されました)。
5.2.2 Implementation
5.2.2 実装
5.2.2.1 Introduction
5.2.2.1 序論
The Siemens Web Call Center used an existing IN system and service logic that supported Call Center features. The scenario it supports is very similar to the Siemens IN-based Call Center on which it was based; one of the goals was to minimize changes to the service offered. It is also virtually identical to the service "Internet Requested Telephony Dial-back" provided by the Lucent system.
シーメンスウェブCallセンターはセンターの特徴をCallにサポートした既存のINシステムとサービス論理を使用しました。 それがサポートするシナリオはそれが基づいたシーメンスのINを拠点とするCallセンターと非常に同様です。 目標の1つは提供されたサービスへの変化を最小にすることでした。 また、それも実際には「インターネットは電話ダイヤル後部を要求したこと」がLucentシステムで提供したサービスと同じです。
As provided via the Internet, the services involved are mostly the same as those provided via the PSTN and IN alone. The main differences lie in the use of the World Wide Web as an interface to the services rather than a telephone, SSP, and Intelligent Peripheral. Also, the feature by which a telephone call is made
インターネットを通して提供するように、かかわったサービスはものがPSTNとIN経由で単独で提供されたのとほとんど同じです。 インタフェースとして電話、SSP、およびIntelligent Peripheralよりむしろサービスには主な違いがWWWの使用であります。 通話がされる特徴も
Lu, et. al. Informational [Page 29] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [29ページ]情報のRFC2458プレパイント実装1998年11月
between the agent and the customer is implemented within the IN system in a different way; this is the only element in which the PSTN is involved.
INシステムの中でエージェントと顧客の間で異なった方法で実装されます。 これはPSTNがかかわる唯一の要素です。
5.2.2.2 Web Call Center Configuration
5.2.2.2 ウェブコールセンター構成
The general arrangement for the Web Call Center system is shown in Figure 7. The components that were added to an existing IN system to deal with the Internet interface are described next.
ウェブCallセンターシステムのための一般配置図は図7に示されます。 インターネットインタフェースに対処するために既存のINシステムに追加されたコンポーネントは次に、説明されます。
In addition to the SCP, SSP and SMS that were part of the original IN-based system, another unit was included to send notification messages to agents; in the IN system the agents were sent "wake up" telephone calls when they were required to handle their next customers' call back. This unit is called the "Internet Intelligent Peripheral", and its use is described later under "Non-World Wide Web Interactions".
オリジナルのINベースのシステムの一部であったSCP、SSP、およびSMSに加えて、もう1個のユニットは通知メッセージをエージェントに送るために含まれていました。 それらが彼らの次の顧客の呼び出しを扱い返すのが必要であったときに、INシステムでは、「目覚めてください」という通話をエージェントに送りました。 このユニットは「インターネットの知的な周辺機器」と呼ばれます、そして、使用は後で「非WWW相互作用」の下で説明されます。
As there was a need to re-use as many of the existing IN components unchanged, a Gateway unit to deal with the interface between the Internet and the SCP was provided. This injected INAP (Intelligent Network Application Protocol) messages into the SCP, making it think that it had received an Initial DP trigger from an SSP. It also intercepted the "Connect To Resource" and "Prompt and Collect" INAP messages sent from the SCP, acting on these to return the parameters generated by the Internet users when they filled in the forms that triggered the service transaction. It also translated the "Play Announcement" message sent to the Intelligent Peripheral into a form that it could use. Finally, it passed on the INAP message used by the SCP to trigger SSP into making the telephone call back.
変わりがない状態で既存のINコンポーネントの同じくらい多くを再使用する必要があったとき、インターネットとSCPとのインタフェースに対処するゲートウェイ部隊を提供しました。 これはINAP(知的なNetwork Applicationプロトコル)メッセージをSCPに注入しました、SSPからInitial DP引き金を受けたと思わせて。 また、それは「リソースに接続してください」を妨害しました、そして、「迅速で料金先方払い」のINAPメッセージはSCPから発信しました、サービス取引の引き金となった彼らが伝票を書いたときインターネットユーザによって生成されたパラメタを返すためにこれらに影響して。 また、それはIntelligent Peripheralに送られた「プレー発表」メッセージを使用できたフォームに翻訳しました。 最終的に、それは通話をし返すのにSSPの引き金となるのにSCPによって使用されたINAPメッセージを伝えました。
5.2.2.3 User Interaction
5.2.2.3 ユーザ相互作用
In the IN/PSTN-based system, the services have contact with the customers and agents via their telephones, SSPs, and Intelligent Peripherals programmed to play announcements to them and to capture their responses. These responses are indicated by DTMF tones sent by pressing keys on the telephones.
PSTN IN/ベースのシステムでは、サービスはそれらに発表をプレーして、彼らの応答を得るようにプログラムされた彼らの電話、SSPs、およびIntelligent Peripheralsを通して顧客とエージェントとの接触を持っています。 これらの応答は電話の上でキーを押すことによって送られたDTMFトーンによって示されます。
In this case, almost all interactions are provided via World Wide Web requests and responses. The sequence of announcements and responses for each service are "collapsed" into individual form filling transactions, and the requests are not limited to digits (or "star" and "hash"). The implications of the use of forms on service operation are covered in more detail later (under HTTP/IN Service mapping).
この場合、WWW要求と応答でほとんどすべての相互作用を供給します。 各サービスのための発表と応答の系列は個々の用紙記入トランザクションまで「潰されます」、そして、要求はケタ(または、「星」と「ハッシュ」)に制限されません。 サービス操作のフォームの使用の含意はさらに詳細に後で(HTTP/IN Serviceマッピングの下で)カバーされています。
Lu, et. al. Informational [Page 30] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [30ページ]情報のRFC2458プレパイント実装1998年11月
5.2.2.4 Service/Caller Identifiers
5.2.2.4 サービス/訪問者識別子
When provided via the IN/PSTN-based system, the services are passed the Calling Line Identity (CLI) of the caller and the number the caller dials (the DN). The CLI value is used extensively to identify the caller and (in the case of the agent) to index into service data tables to decide what to do next. While an equivalent value to the DN is passed to the Web-based transactions as the requested Universal Resource Locator (URL), the CLI cannot be given reliably. The nearest equivalent caller identifier is the IP Address of the customer or agent's machine. However, the use of HTTP proxies means that this "original" Internet node Address may not be available; if a proxy is used then its IP Address will be associated with the request.
PSTN IN/ベースのシステムで提供すると、訪問者のCalling線Identity(CLI)と訪問者がダイヤルする番号(DN)をサービスに渡します。 CLI値は、訪問者を特定するのに手広く使用されて、次に何をしたらよいかを決めるのをサービスデータへのインデックスまでテーブルの上に置きます(エージェントの場合で)。 DNへの同等な値が要求されたUniversal Resource Locator(URL)としてウェブベースのトランザクションに通過されている間、CLIを確かに与えることができません。 最も近い同等な訪問者識別子は顧客かエージェントのマシンのIP Addressです。 しかしながら、HTTPプロキシの使用は、この「オリジナル」のインターネット接続装置Addressが利用可能でないかもしれないことを意味します。 プロキシが使用されていると、IP Addressは要求に関連するでしょう。
In providing these Call Center features the customer only has one Web-based transaction; that of providing the initial request for a PSTN telephone callback. To do so he or she will have to fill in a form so as to specify not only the time to be called back, but also the telephone number to be reached. These values can be used if needed to identify the customer, and so the problem of originating Internet Node ambiguity is not relevant.
これらのCallセンターの特徴を提供する際に、顧客は1つのウェブベースのトランザクションしか持っていません。 PSTN電話コールバックを求める初期の要求を提供するもの。 その人が達するようにコールバックされるべき時間だけではなく、電話番号も指定するために書類に必要事項を記入しなければならないようにするために。 顧客を特定するのが必要であるならこれらの値を使用できるので、インターネットNodeのあいまいさを溯源するという問題は関連していません。
With the agents, however, there are sequences of coupled transactions, and the particular sequence must be identified. There will be a number of such transactions being carried out at once, and there needs to be some identifier to show which agent is being handled in each case.
しかしながら、エージェントと共に、結合したトランザクションの系列がいます、そして、特定の系列を特定しなければなりません。 すぐに行われるそのような多くのトランザクションがあるでしょう、そして、どのエージェントがその都度扱われているかを示す何らかの識別子があるのが必要です。
Such an identifier is not part of a sequence of basic Web transactions. In a Web transaction, the HTTP Client/Web Browser makes a request, and the HTTP Server will respond to this, normally including some content in its reply message that will be processed by the browser, after which it closes the TCP connection. That's the end of the transaction; the HTTP client and server cannot normally maintain state information beyond this point. Any sequence is reduced to a set of unrelated transactions.
そのような識別子は基本的なウェブトランザクションの系列の一部ではありません。 ウェブトランザクションでは、HTTP Client/ウェブBrowserは要求をします、そして、HTTP Serverはこれに応じるでしょう、通常、それがTCP接続を終えるブラウザによって処理される応答メッセージの何らかの内容を含んでいて。 それはトランザクションの終わりです。 通常、HTTPクライアントとサーバはこのポイントを超えて州の情報を保守できません。 どんな系列も1セットの関係ないトランザクションに減少します。
A result of this simple pattern is that any state information reflecting longer or more complex interactions must be stored (at least partially) in the client system. One approach is the use of cookies [6]. These can be set by HTTP servers as part of their response to a request, and will be sent back with all subsequent requests for appropriate URLs as extra HTTP headers. These cookies allow the HTTP server to identify the client in the following requests, so that it can continue an extended session with the client.
この簡単なパターンの結果はクライアントシステムにより長いか、より複雑な相互作用を反映するどんな州の情報も保存しなければならないという(少なくとも部分的に)ことです。 1つのアプローチはクッキー[6]の使用です。 これらは、要求への彼らの応答の一部としてHTTPサーバで設定できて、付加的なHTTPヘッダとして適切なURLを求めるすべてのその後の要求で返送されるでしょう。 HTTPサーバは以下の要求でこれらのクッキーでクライアントを特定できます、クライアントとの延ばされたセッションを続けることができるように。
Lu, et. al. Informational [Page 31] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [31ページ]情報のRFC2458プレパイント実装1998年11月
Cookies are used in providing the Internet Call Center. Persistent cookies are installed into the Web Browser on machines that are to be used by call center agents as a service management (pre-service) task. The cookie value is unique to the machine and is used to index into a list of machine IP addresses that is stored as part of the service data.
クッキーはインターネットCallセンターを提供する際に使用されます。 永続的なクッキーはサービス管理(プレサービス)タスクとしてコールセンターのエージェントによって使用されることになっているマシンの上のウェブBrowserにインストールされます。 クッキー値は、マシンにユニークであり、サービスデータの一部として保存されるマシンIPアドレスのリストの中に索引をつけるのに使用されます。
Also, a session cookie is stored onto the agent's machine when the agent registers, and is cleared when he or she de-registers. This is used to identify the agent and so the IP address of the node with which the agent is associated (and from which the agent's subsequent requests should originate). The services that interact with Call Center agents use the agent session cookie value as an identifier; in principle this is unnecessary but it does simplify the session data lookup procedure. The rest of the services use the persistent machine identifier in place of the CLI, indexing into their service data using it. Both cookies are sent with each agent request; if they are not present, then the request is redirected to other services (for example to the agent Logon service).
また、セッションクッキーは、エージェントが登録するとエージェントのマシンとして保存されて、その人が反-登録すると、きれいにされます。 これは、エージェントが関連しているノードのエージェントとIPが演説するそうを特定するのに使用されます(そして、エージェントのその後の要求が起因するべきである)。 Callセンターのエージェントと対話するサービスは識別子としてエージェントセッションクッキー価値を使用します。 原則として、これは不要ですが、それはセッションデータルックアップ手順を簡素化します。 サービスの残りはCLIに代わって永続的なマシン識別子を使用します、それを使用することでそれらのサービスデータに索引をつけて。 それぞれのエージェント要求と共に両方のクッキーを送ります。 それらが存在していないなら、要求は他のサービス(例えば、エージェントLogonサービスへの)に向け直されます。
5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features
5.2.2.5 HTTPトランザクションからベースでのサービスまで特徴を写像します。
All of the client-initiated services require user interaction. With the IN/PSTN-based system, the majority of the services are typified by the callers being connected to an announcement unit that plays them a list of choices and captures their selection. The caller can pre-dial the digits needed; in this case the prompts are not needed and are not made.
クライアントによって開始されたサービスのすべてがユーザ相互作用を必要とします。 PSTN IN/ベースのシステムで、サービスの大部分は彼らをプレーする発表ユニットに接続される訪問者によって代表されて、aが選択について記載するということであり、捕獲は彼らの選択です。 訪問者は必要であるケタにあらかじめダイヤルすることができます。 この場合、プロンプトを必要でなく、またしません。
The pattern of operation is somewhat different in the Internet case, as the initial HTTP request returns a response, after which the Web transaction has ended. Where that initial response returns a form to be filled in by the caller, subsequently submitting the form initiates a new HTTP transaction. This is all part of one instance of service, however. The service consists of two request/response pairs in tandem.
操作のパターンはインターネット場合においていくらか異なっています、初期のHTTP要求が応答を返すとき。(その時、ウェブトランザクションは終わりました後)。 訪問者によって記入されるようにその初期の応答がフォームを返すところでは、次にフォームを提出すると、新しいHTTPトランザクションは開始します。 しかしながら、これはすべてサービスの1つのインスタンスの一部です。サービスは2人乗り自転車で2要求/応答組から成ります。
Although it is possible to design a service to handle this pair of Web transactions as a single unit, it may be better to reconfigure it. The design of a service that deals with two Web exchanges as a single extended transaction is quite complex. It must maintain state across the pair of Web exchanges, and it has to handle a number of failure cases including dealing with time-outs and "out of time" submission of forms. The alternative is to split the service into two sub-features. The first of these reflects the initial request and delivery of the form by return, with the second one dealing with processing of the submitted form and returning any confirmation by reply.
単一の単位としてウェブトランザクションのこの組を扱うようにサービスを設計するのが可能ですが、それを再構成しているほうがよいかもしれません。 ただ一つの拡張トランザクションとして2回のウェブ交換に対処するサービスのデザインはかなり複雑です。 ウェブ交換の組の向こう側に状態を維持しなければなりません、そして、それは形式のタイムアウトと「遅れて」服従に対処するのを含む多くの失敗事件を扱わなければなりません。代替手段はサービスを2つのサブの特徴に分けることです。 これらの1番目は折り返し形式の初期の要求と配送を反映します、2番目のものが提出された形式の処理に対処して、回答でどんな確認も返していて。
Lu, et. al. Informational [Page 32] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [32ページ]情報のRFC2458プレパイント実装1998年11月
The services offered don't all require form-filling, and so can be treated as a single IN feature. There are two cases where forms are required. The first of these is the Customer Request service, while the other one is the "Agent Registration" service. In both cases the initial Web transaction (by which the form is requested and returned to the client) need not involve specific service logic processing; the initial delivery of the form to a customer or agent can be handled by a "normal" Web Server. In both cases the service logic is only triggered when the form is submitted; this means that, again, each of the services can be treated as a single IN feature.
用紙記入をすべて必要としないので、ただ一つのINの特徴として提供されたサービスは、扱うことができます。 2つのケースがフォームが必要であるところにあります。 これらの1番目はCustomer Requestサービスですが、もう片方は「エージェント登録」サービスです。 どちらの場合も、初期のウェブトランザクション(書式がクライアントに要求されていて、返される)は特定のサービス論理処理にかかわる必要はありません。 「正常な」ウェブServerは顧客かエージェントへの形式の初期の配送を扱うことができます。フォームを提出するときだけ、どちらの場合も、サービス論理を引き起こします。 これは、一方、ただ一つのINの特徴としてそれぞれのサービスを扱うことができることを意味します。
The IN service logic that deals with these requests has a general pattern of action. An HTTP request is received, and this triggers the IN service logic into action. The service logic "sees" this as an Initial DP message and starts its processing as if it had been sent from an SSF. The SCF uses what appears to it to be an Intelligent Peripheral to collect the parameters of the request, and then to send back final announcements to the requesting entity.
これらの要求に対処するINサービス論理は動作の一般的な型を持っています。 HTTP要求は受信されています、そして、これはINサービス論理の動作に引き金となります。 サービス論理は、Initial DPメッセージをこれを「見」て、それはまるでSSFからそれを送ったかのように処理し始めます。 SCFは要求のパラメタを集めて、そして、要求実体に最終的な発表を返送するIntelligent Peripheralであるそれに現れることを使用します。
The main difference, from the perspective of the IN service logic running on the SCF, is that the service does not need to instruct the SSF to make a temporary connection to the Intelligent Peripheral. It is as if this connection had already been made. Similarly, there is no need to close the service transaction by sending an explicit "Continue Execution" message to the SSF.
SCFの上で作業するINサービス論理の見解から、主な違いはサービスが、Intelligent Peripheralに一時性結合を作るようSSFに命令する必要はないということです。 まるでこの接続が既に作られたようでした。 同様に、「実行を続けてください」という明白なメッセージをSSFに送ることによってサービス取引を終える必要は全くありません。
The sequence of "prompt/collect" instructions used to collect service parameters from a caller in an IN service maps quite well to a sequence of requests to extract a data value from the HTTP request, based on a tag. This is a fairly standard feature of Web Server CGI or Servlet processing. Using this mapping minimizes the changes to the service design, in that the service logic "sees" an Intelligent Peripheral to which it sends normal "Request Report Prompt & Collect" messages, and from which it receives data values in response.
訪問者からINサービスでサービスパラメタを集めるのに使用される「迅速であるか料金先方払い」の指示の系列はHTTP要求からデータ値を抽出するという要求の系列に全く井戸を写像します、タグに基づいて。 これはウェブServer CGIかServlet処理のかなり標準の特徴です。 このマッピングを使用すると、サービスデザインへの変化は最小にされます、サービス論理が正常な「要求レポート迅速で料金先方払い」のメッセージを送って、応答におけるデータ値を受けるIntelligent Peripheralを「見る」ので。
All services have to fit in with the underlying HTTP interaction pattern, and so will be expected to send a final "Announce" instruction to the Intelligent Peripheral at the end of the service; this is done in many IN services anyway and in all of the service features described here. These announcements form the content returned to the Web Client.
すべてのサービスが、基本的なHTTP相互作用パターンに適応しなければならないので、「発表してください」という最終的な指示をサービスの終わりのIntelligent Peripheralに送ると予想されるでしょう。 これを多くのINサービスでとにかくして、ここでサービス機能のすべてで説明します。 これらの発表はウェブClientに返された内容を形成します。
Lu, et. al. Informational [Page 33] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [33ページ]情報のRFC2458プレパイント実装1998年11月
5.2.2.6 Non-World Wide Web Interactions
5.2.2.6 非WWW相互作用
There are two exceptions to the sole use of the World Wide Web for interaction. The first one occurs in the "Message Waiting"/"Wake Up Call" service by which the selected agent is informed of a callback request. World Wide Web transactions are very simple; the client browser makes a request for content associated with a particular HTTP URL, and the server sends a response, marking the end of the transaction. The server cannot make a spontaneous association with a client; it must be initiated by the client request.
WWWの相互作用の唯一の使用への2つの例外があります。 最初のものは選択されたエージェントがコールバック要求において知識がある「メッセージの待ち」/「航跡Up Call」サービスで起こります。 WWWトランザクションは非常に簡単です。 クライアントブラウザは特定のHTTP URLに関連している内容に関する要求をします、そして、サーバは応答を送ります、トランザクションの終わりを示して。 サーバはクライアントとの自然発生的な仲間を作ることができません。 クライアント要求でそれを開始しなければなりません。
While it would be possible for the server to defer closing an earlier transaction (by not sending back all of the content specified and leaving the TCP connection open) it was decided that an alternative scheme would be more convenient. The "wake up call" was arranged by an "Internet Intelligent Peripheral" sending a request to a daemon process running on the selected agent's machine, using the Finger protocol [7]. The daemon sent back a standard response, but in addition the Web Browser on the agent's machine was triggered into making a further HTTP request of the server. In this way the "Agent Instruction" transaction is started automatically, while still allowing it to use a normal HTTP request/response pattern.
サーバが延期するのにおいてそれが以前のトランザクション(指定されて、TCP接続を開いた状態でおいて、内容のすべてを返送しないのによる)を閉じながら可能であるだろうという間、代替の体系が、より便利であると決められました。 「モーニングコール」は選択されたエージェントのマシンで動くデーモンプロセスに要求を送りながら、「インターネットの知的な周辺機器」によってアレンジされました、Fingerプロトコル[7]を使用して。 デーモンは標準の応答を返送しましたが、さらに、エージェントのマシンの上のウェブBrowserはサーバのさらなるHTTP要求をするのに引き起こされました。通常のHTTP要求/応答パターンを使用するのをまだ許容している間、このように、「エージェント指示」トランザクションは自動的に始められます。
The second exception occurs in the final "Agent/Customer Telephony Callback" service. While this transaction is initiated by the agent selecting a link on the "call instructions page" returned to them, and includes a "confirmation" page being sent back to them in an HTTP response, the purpose of this service is to make a telephone connection via the PSTN between the agent's telephone and the customer's telephone. It is the only service element that involves the PSTN directly. From an IN/PSTN perspective, the resulting telephone connection is different from that provided in the scheme using the IN and PSTN alone. In this case, a PSTN call is made out to the agent's telephone, another call is made out to the customer's telephone, and these calls are bridged. This differs from the earlier scheme, in which the agent originated a call to the voice mail replay system, and this call was redirected to a new destination (the customer's telephone). As this feature differs in purpose from the other services, and it requires a different implementation within the IN and PSTN system, it was organized as a separate service in this case.
2番目の例外は最終的な「エージェント/顧客電話コールバック」サービスで起こります。 このトランザクションがそれらに返された「コール命令ページ」でリンクを選択するエージェントによって開始されて、HTTP応答にそれらが送り返される「確認」ページを含んでいる間、このサービスの目的はエージェントの電話と顧客の電話の間のPSTNを通して電話接続を作ることです。 それは直接PSTNにかかわる唯一のサービス要素です。 IN/PSTN見解と、結果として起こる電話接続は単独でINとPSTNを使用することで体系に提供されたそれと異なっています。 この場合、PSTN呼び出しはエージェントの電話に理解されています、そして、別の呼び出しは顧客の電話に理解されています、そして、これらの呼び出しはブリッジされます。 これは以前の体系と異なりました、そして、この呼び出しは新しい目的地(顧客の電話)に向け直されました。(そこでは、エージェントがボイスメール再生システムに呼び出しを溯源しました)。 この特徴が他のサービスと目的において異なって、INとPSTNシステムの中で異なった実装を必要とするとき、それはこの場合別々のサービスとして組織化されました。
Lu, et. al. Informational [Page 34] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [34ページ]情報のRFC2458プレパイント実装1998年11月
5.2.2.7 Security Considerations
5.2.2.7 セキュリティ問題
In the case of this system, assumptions were made that the interface presented to requesting agents and customers was provided via a fire wall to deal with most attacks on the IN components. The interface appeared as a Web Server, and there was no direct access to the HTTP documents served, nor to the servlets providing the service logic.
このシステムの場合では、INコンポーネントに対するほとんどの攻撃に対処するためにファイアウォールでエージェントと顧客を要求するのに提示されたインタフェースを提供したという仮定はされました。 インタフェースはウェブServerとして現れました、そして、役立たれていて、サービス論理をサーブレットに提供するHTTPドキュメントへの直接アクセスが全くありませんでした。
The Callback service was deemed to have simpler security requirements than other IN services as it was akin to a free phone "1-800" service access number; the agents work for the service subscriber and are not charged directly. Similarly, the requesting customer is not charged for his or her request, nor for the resulting call back. Service subscribers would be willing to pay the costs of telephone calls generated as a result of this cluster of services, and the costs of running the agent services could be charged directly to them. As such the authorization for service is defined by the contract between the service subscriber and the service provider.
それが自由な電話「1-800」サービスアクセス番号と同系であったのでCallbackサービスには他のINサービスより簡単なセキュリティ要件があると考えられました。 エージェントは、サービス加入者のために働いて、直接請求されません。 同様に、要求している顧客はその人の要求、および結果として起こる呼び出し後部を請求されません。 サービス加入者は、このサービスのクラスタの結果、生成された通話のコストを支払っても構わないと思っているでしょう、そして、エージェントサービスを実行するコストは直接彼らに宣言できました。 そういうものとして、サービスのための承認はサービス加入者とサービスプロバイダーとの契約によって定義されます。
Authentication of agents was seen as a problem. As an interim measure, cookies were used, but this scheme delivers the cookie data as a plain text item (a header of the Web request). Secure Socket Layer connections were required for communication with the agent services, and this had an impact on the performance of the IN system.
エージェントの認証は問題と考えられました。 臨時措置として、クッキーは使用されましたが、この体系はプレーンテキスト項目(ウェブ要求のヘッダー)としてクッキーデータを提供します。 Secure Socket Layer接続がエージェントサービスとのコミュニケーションに必要でした、そして、これはINシステムの性能に影響を与えました。
5.2.3 Derived Requirements/Lessons
5.2.3 派生している要件/レッスン
Security is seen as a major issue. A firewall was used to control access to the IN Components. Similarly, SSL was used for communication with the Agents, so as to protect the cookie values that they were sending with their requests.
セキュリティは主要な問題と考えられます。 ファイアウォールは、IN Componentsへのアクセスを制御するのに使用されました。 同様に、SSLはエージェントとのコミュニケーションに使用されました、それらが彼らの要求と共に送ったクッキー値を保護するために。
For other services, it is likely that the entity from which requests appear to originate will be charged for the service to be rendered. This has implications in terms of authentication and authorization of service provision at the time of the request. It is necessary for the service to be authorized in such a way that non-repudiation is ensured; this is likely to mean that a certificate of identity be provided from the person making the request, and that this can be tied in with a financial account that that person has with the service provider. The certificate can then be stored as part of the billing record. While the process of electronic commerce is outside of the scope of this work, the mechanism by which a request for confirmation of identity is passed out to the requesting user and is delivered back to the service logic must be considered.
他のサービスにおいて、要求が起因するように見える実体は、サービスがレンダリングされるために請求されそうでしょう。 これには、要求時点で、サービス支給の認証と承認に関して意味があります。 サービスが非拒否が確実にされるような方法で認可されるのが必要です。 これは要求をしている人からアイデンティティの証明書を提供して、その人がサービスプロバイダーと共に持っている金融勘定でこれを接続できることを意味しそうです。 そして、支払い記録の一部として証明書を保存できます。 電子商取引のプロセスがこの仕事の範囲の外にある間、アイデンティティの確認を求める要求が要求しているユーザに配られて、サービス論理に提供して戻されるメカニズムを考えなければなりません。
Lu, et. al. Informational [Page 35] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [35ページ]情報のRFC2458プレパイント実装1998年11月
When changing from a "pure" IN/PSTN system to one supporting requests via the Internet, the differences in the way that clients interacted with the services meant that the service logic had to be redesigned. It was realized that maintaining the state of a service during its processing was going to be a problem; this problem was side-stepped by re-engineering the services as form processors, allowing them to deal with fully specified requests as a single (Web) transaction. In addition, a "normal" Web Server was used to deliver the forms to the users. This is a change from the IN system, where the equivalent of the form (the prompts) were sent in sequence as part of the same service process.
「純粋な」IN/PSTNシステムからインターネットを通して要求をサポートする1つに変化するとき、クライアントがサービスと対話した方法の違いは、サービス論理が再設計されなければならないことを意味しました。 処理の間、サービスの状態を維持するのが、問題であるつもりであると実感されました。 この問題はリエンジニアリングによってかわされて、フォームプロセッサとしてのサービス、論じ尽くすのを許容するのが要求を指定したということでした。(ウェブ)ただ一つのトランザクションとして。 さらに、「正常な」ウェブServerは、フォームをユーザに提供するのに使用されました。 これはINシステムからの変化です。そこでは、フォーム(プロンプト)の同等物が連続して同じサービス過程の一部として送られました。
The Call Center features provided suited this change. However, this may not be the case for other IN services. It is quite common for services to be designed such that the user is prompted for a response, and the service continues dependent on this response. The Web form presents all of the options at once, so this kind of variant prompt/collect sequence is not possible. From this, it is difficult to see how an IN service could be reused without some degree of modification.
特徴が提供したCallセンターはこの変化に合いました。 しかしながら、これは他のINサービスのためのそうでないかもしれません。 サービスが設計されているのが、全く一般的であるので、ユーザは応答のためにうながされます、そして、サービスはこの応答での扶養家族を続けています。 ウェブフォームがすぐにオプションのすべてを提示するので、この種類の異形の迅速であるか料金先方払いの系列は可能ではありません。 これから、変更なしでいくらかのINサービスをどう再利用できたかを見るのは難しいです。
An intermediate "gateway" system was provided to "cocoon" the service logic as far as possible from the details of the components with which it was working. Where needed, this unit translated calls from the service logic into commands that operated with the Internet (and the Web Server that acted as the interface). Our experience was that an SCP could be "spoofed" into thinking that it was operating with other IN components in the normal way. Within the limits of the service used, this proved simpler than was originally expected.
それが働いていたコンポーネントの詳細からサービス論理をできるだけ「ぴったりくるむ」ために中間的「ゲートウェイ」システムを提供しました。 必要であるところでは、このユニットは呼び出しをサービス論理からインターネット(そして、インタフェースとして機能したウェブServer)で作動したコマンドに翻訳しました。 私たちの経験はそれが他のINコンポーネントで正常な方法で作動していたと思うのにSCPを「偽造することができた」ということでした。 利用されたサービスの限界の中では、これは元々予想されたより簡単であると判明しました。
Selecting this simple approach still allows a considerable range of services to be provided while maintaining any investment in existing IN systems. Modification of existing IN service logic was also easier than feared. All of the services examined provided announcements at the end of the service transaction, and this could be used to trigger a Web response to be sent back to the requesting Internet user. The changes to the Call Center service logic turned out to be minor; it took as long to analyze the service and see how it could be arranged as a sequence of "form processing" transactions as it did to make the changes to the service logic.
この簡潔な解決法を選択するのは、既存のINシステムへのどんな投資も維持している間、かなりの範囲のサービスが提供されるのをまだ許容しています。また、既存のINサービス論理の変更も恐れられるより簡単でした。 サービスのすべてがサービス取引の終わりに提供された発表を調べました、そして、要求しているインターネットユーザに送り返されるべきウェブ応答の引き金となるのにこれは使用できました。 Callセンターサービス論理への変化は小さい方であると判明しました。 それはサービスを分析して、それとしてのトランザクションがサービス論理への変更を行うためにした「フォーム処理」の系列であるとどうそれをアレンジできたかをみなすために長いとしてみなしました。
In the Siemens Web Call Center, the "Internet Intelligent Peripheral" with which the service logic communicated was running as a separate program on the same node. Where more complex behavior is required of it (such as conversion of text to speech data and interface with the PSTN) then it would almost certainly be on a separate node. If data is transferred from the Internet in such a scheme, any intermediate gateway would be involved in relaying the data to this node.
シーメンスウェブCallセンターでは、サービス論理が交信した「インターネットの知的な周辺機器」は同じノードの上の別々のプログラムとして稼働する予定でした。 より複雑であるところでは、それ(スピーチデータへのテキストとPSTNとのインタフェースの変換などの)は振舞いに要求されて、別々のノードの上に次に、ほぼ確実にあるでしょう。 そのような体系におけるインターネットからデータを移すなら、どんな中間ゲートウェイもこのノードにデータをリレーするのにかかわるでしょう。
Lu, et. al. Informational [Page 36] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [36ページ]情報のRFC2458プレパイント実装1998年11月
6. Alternative Solutions
6. 代替のソリューション
6.1 The AT&T System
6.1 AT&Tシステム
AT&T developed a framework for controlling voice and voice-band data (e.g., fax) and for providing PINT services. Key to the framework is CallBroker, a logical entity that acts on behalf of a user to set up sessions and make requests for PSTN resources. The sessions typically include initiation of calls between two or more end points specified by the user. In addition to its interactions with the PSTN for call setup, the CallBroker is responsible for other functions, when necessary, such as authentication and usage recording.
AT&Tは、声と音声帯域データ(例えば、ファックス)を制御して、サービスをPINTに供給するためにフレームワークを開発しました。 フレームワークのキーはCallBroker(セッションをセットアップして、PSTNを求める要求をリソースにするようにユーザを代表して行動する論理的な実体)です。 セッションはユーザによって指定された2つ以上のエンドポイントの間の呼び出しの開始を通常含んでいます。 呼び出しセットアップのためのPSTNとの相互作用に加えて、CallBrokerは他の機能に責任があります、必要であるときに、認証や用法録音のように。
This section briefly discusses the protocol at the two interfaces that need to be defined and the corresponding APIs to provide the above services. The two interfaces are (1) the one between the CallBroker (or Web Server) and the Service Control Function in the Service Node in the PSTN and (2) the one between the IP client and the CallBroker. The latter interface, in particular, will enable service providers to extend the architecture defined here to serve as a platform for other advanced/value-added services (to be identified later). In addition, the view taken here is that the IP client is more general, and implements a protocol for communication with the CallBroker that allows full two-way communications. For example, this is required for the cases where a called party hangs up and an indication may be necessary to be given to the IP Client about this status/progress. This is also necessary when conferencing to give an indication/status of various parties joining the call.
このセクションは、上のサービスを提供するために定義される必要がある2つのインタフェースと対応するAPIで簡潔にプロトコルについて論じます。 2つのインタフェースがそうです。(1) CallBrokerの間のもの(または、ウェブServer)とPSTNのService NodeのService Control Functionと(2) IPクライアントとCallBrokerの間のもの。 後者のインタフェースは、サービスプロバイダーが他の高度であるか付加価値が付いたサービス(後で特定される)のためのプラットホームとして機能するようにここで定義されたアーキテクチャを広げるのを特に可能にするでしょう。 さらに、ここに取られた意見はIPクライアントが、より一般的であり、完全な双方向通信を許容するCallBrokerとのコミュニケーションのためにプロトコルを実装するということです。 例えば、これが被呼者がハングアップして、指示がこの状態/進歩に関してIP Clientに与えるのに必要であるかもしれないケースに必要です。 また、呼び出しに参加する様々なパーティーの指示/状態を与える会議であるときに、これも必要です。
Lu, et. al. Informational [Page 37] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [37ページ]情報のRFC2458プレパイント実装1998年11月
6.1.1 High Level Architecture
6.1.1 高い平らなアーキテクチャ
A high level architecture depicting various logical entities and the Interfaces among these logical Entities and the IP Client is shown in Figure 12.
これらの論理的なEntitiesとIP Clientの中に様々な論理的な実体とInterfacesについて表現する高い平らなアーキテクチャは図12に示されます。
________________
/
1 _____ / 2 _____
/|________________| |________| | PSTN
|____| \ |____|
Call \ / SCF\
Broker \ / SN \
\_____________
/ \
/ \
/ \
__ __
/\ /\
________________ / 1 _____ / 2 _____ /|________________| |________| | PSTN|____| \ |____| ブローカー\/SN\\に\/SCF\に電話をしてください。_____________ / \ / \ / \ __ __ /\ /\
Calling Participant
Party (Called Party)
関与しているパーティと呼びます。(被呼者)
Figure 12: The CallBroker Architecture
図12: CallBrokerアーキテクチャ
The CallBroker, in addition to the initiation and control of calls on behalf of the user, performs additional functions. These functions include authenticating the IP Client, usage recording, and management of the session for the IP Client for the telephony call. The notion of the session requires that a client state machine be maintained in the CallBroker. This also helps in notifying the IP Client about the status/progress of the requests generated from the IP Client.
ユーザを代表した呼び出しの開始とコントロールに加えて、CallBrokerは追加機能を実行します。 これらの機能は、電話呼び出しのためにIP ClientのためのセッションのIP Client、用法録音、および管理を認証するのを含んでいます。 セッションの概念は、属国マシンがCallBrokerで維持されるのを必要とします。 また、これは、IP Clientから生成された要求の状態/進歩に関してIP Clientに通知するのを手伝います。
From the perspective of the IP Client, the logical entities needed for the above functions are within the CallBroker and are as shown in Figure 13 below. These correspond to the functions already discussed: Usage Recording Function, Session Management Function, Voice Bridge, and the Authentication Function. The fact that some of these functions may be physically separate from the CallBroker (such as the Voice Bridge being in the PSTN) is not inconsistent with the general view adopted here. Thus, the CallBroker Model mediates requests for network services and enables us to define various value added services in the future.
IP Clientの見解から、上の機能に必要である論理的な実体は、CallBrokerの中にあって、以下の図13に示されるように来ています。 これらは既に議論した機能に対応しています: 用法記録機能、セッション管理機能、声のブリッジ、および認証は機能します。 これらの機能のいくつかがCallBroker(PSTNにあるVoice Bridgeなどの)から肉体的に別々であるかもしれないという事実はここに採用される概観に反していません。 したがって、CallBroker Modelは、ネットワーク・サービスを求める要求を伝えて、私たちが将来様々な付加価値が付いたサービスを定義するのを可能にします。
Lu, et. al. Informational [Page 38] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [38ページ]情報のRFC2458プレパイント実装1998年11月
llllllllllllllll
l l
l Call Broker l Authentication
l Server l Function
l ______ l Interface 2a ______
l | |x x xlx x x x x x x x x | |
l |______|x l |____|
l x x l
l x xl Interface 2b
lSession State lx
l Mnmgt. x l x Usage Recording
l Function l x Function
l _______ x l x ______
l | | l x x x | |
l |_____| xl |____|
llllllllllllllll
x
x Interface 2c
x
_______
| |
|_____|
llllllllllllllll l l l Call Broker l Authentication l Server l Function l______ lインタフェース2a______ l| |x x xlx x x x x x x x x| | l|______|x l|____| Mnmgt l x x l l x xl Interface 2b lSession州lx l x l x Usage Recording l Function l x Function l_______ x l x______ l| | l x x x| | l|_____| xl|____| llllllllllllllll x x Interface 2c x_______ | | |_____|
Bridge
ブリッジ
Figure 13: Functional Entities in the Call Broker
図13: 呼び出しブローカーの機能的な実体
Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different functional entities in the CallBroker may also be standardized. The Session State Management Function may be physically realized as part of the CallBroker Server.
また、CallBrokerの異なった機能的な実体の間の様々なインタフェース(すなわち、2a、2b、図13の2c)は標準化されるかもしれません。 Session州Management FunctionはCallBroker Serverの一部として物理的に実感されるかもしれません。
6.1.2 IP Client to CallBroker Interface
6.1.2 CallBrokerインタフェースへのIPクライアント
Communication on the IP Client to CallBroker Interface (Interface 1 in Figure 12) is a simple ASCII based protocol running directly on TCP. The messages on this interface are primarily requests from the client to the CallBroker, responses from the CallBroker to the IP client responding to the requests and unsolicited events from the CallBroker to the IP client. Since the communication is not strictly transaction oriented, traditional encapsulation protocols like HTTP cannot be used. There has been some ongoing work attempting to use multiple concurrent HTTP POST requests to support event delivery but, without too much difficulty, the ASCII protocol specified here can easily be mapped to the POST payload of the HTTP protocol.
CallBroker Interface(図12のインタフェース1)へのIP Clientに関するコミュニケーションは直接TCPの上で作業する簡単なASCIIベースのプロトコルです。 クライアントからCallBroker(CallBrokerからCallBrokerからIPクライアントまで要求と求められていないイベントに応じているIPクライアントまでの応答)までこのインタフェースに関するメッセージは主として要求です。 以来、コミュニケーションはHTTPを使用できないように厳密にトランザクション指向の、そして、伝統的なカプセル化プロトコルではありません。 イベント配送をサポートするという複数の同時発生のHTTPポストの要求を使用するのを試みるいくらかの進行中の仕事がありましたが、あまりに多くの困難がなければ、ここで指定されたASCIIプロトコルはHTTPプロトコルのポストペイロードに容易に写像できます。
Lu, et. al. Informational [Page 39] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [39ページ]情報のRFC2458プレパイント実装1998年11月
6.1.3 Protocol
6.1.3 プロトコル
Basic Format
基本形式
The basic format of the protocol is as follows:
プロトコルの基本形式は以下の通りです:
[header]<<LF> <<LF> [body]<<LF> <<LF> <<LF>
[ヘッダー]<<LF><<LF>[ボディー]<<LF><<LF><<LF>。
The header and body of the protocol are separated by 2 line feed characters. The format of the header and the body is described below. Line feed characters in the header or body will be escaped using simple URL encoding.
プロトコルのヘッダーとボディーは2つの改行文字によって切り離されます。 ヘッダーとボディーの形式は以下で説明されます。 ヘッダーかボディーの改行文字、簡単なURLコード化を使用することで逃げられるでしょう。
Header
ヘッダー
[session-id | 0]<<LF> [message-id]<<LF> [version-info]<<LF>
[セッションイド| 0] <<LF>[メッセージイド]<<LF>[バージョンインフォメーション]<<LF>。
All CallBroker transactions are identified by sessions. A session does not necessarily correspond one-to-one to a TCP session. If the IP client is attempting to initiate a new session with the CallBroker the session-id field is populated with '0' to indicate session creation request. Every session request needs to be accompanied by sufficient information regarding authentication for the CallBroker to create the session.
すべてのCallBrokerトランザクションがセッションで特定されます。 セッションは必ず1〜1にTCPセッションと食い違っています。 IPクライアントが、CallBrokerとの新しいセッションを開始するのを試みているならセッションイド分野は'0'で居住されて、セッション作成要求を示します。 あらゆるセッション要求が、認証に関する十分な情報によって伴われて、CallBrokerがセッションを作成する必要があります。
Message-id represents the operation of the message.
メッセージイドはメッセージの操作を表します。
Version-info contains optional version information of the protocol. This is to aid possible version mismatch detection and graceful error recovery.
バージョンインフォメーションはプロトコルの任意のバージョン情報を含んでいます。 これは、可能なバージョンミスマッチ検出と優雅なエラー回復を支援するためのものです。
Body
ボディー
The body of the protocol messages consists of name value pairs. These name-value pairs are interpreted with reference to the message-id which signifies the operation to be performed by the CallBroker.
プロトコルメッセージのボディーは名前値の組から成ります。 これらの名前価値の組はCallBrokerによって実行されるべき操作を意味するメッセージイドに関して解釈されます。
Lu, et. al. Informational [Page 40] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [40ページ]情報のRFC2458プレパイント実装1998年11月
6.1.4 APIs Exposed to the IP Client
6.1.4 IPクライアントに暴露されたAPI
The APIs of the CallBroker exposed to the IP client are distinct and different from the APIs that the CallBroker uses from the different supporting subsystems including the authentication subsystem and the usage recording subsystem. The IP client APIs enable clients to effectively control voice conferencing.
IPクライアントに暴露されたCallBrokerのAPIは、CallBrokerが認証サブシステムと用法録音サブシステムを含む異なったサポートサブシステムから使用するAPIと異なって異なっています。 IPクライアントAPIは、事実上、クライアントが音声会議を制御するのを可能にします。
6.1.5 Voice-Bridge Control API
6.1.5 音声船橋操縦API
The Voice Bridge Control API is used by CallBroker applications to access voice bridging functionality. The API distinguishes between sessions and calls. Calls represent actual voice calls placed from/to the voice bridge. These calls can be grouped together in sessions. All the calls that belong to a session are bridged. Calls have a significance outside the scope of sessions. Every call can be associated with multiple sessions with different weights at the same time. The advantage of this approach is the ability to support concepts like whispering in a conference call. Calls can also be dropped from a conference session and bridged together in a new session to give the notion of a sub-conference. These calls can later be re-added to the main conference session.
Voice Bridge Control APIは、機能性をブリッジする声にアクセスするのにCallBrokerアプリケーションで使用されます。 APIは、セッションを見分けて、呼びます。 呼び出しは/から声のブリッジまで置かれた実際の音声通話を表します。 セッションのときにこれらの呼び出しを一緒に分類できます。 セッションに属するすべての呼び出しがブリッジされます。 呼び出しはセッションの範囲の外に意味を持っています。 同時に、異なった重りとの複数のセッションにあらゆる呼び出しを関連づけることができます。 このアプローチの利点は電話会議でささやくような概念をサポートする能力です。 また、サブ会議の概念を与えるために呼び出しを会議の話し合いから下げて、新しいセッションのときに一緒にブリッジすることができます。 後で主な会議の話し合いにこれらの呼び出しを再加えることができます。
6.2 Simple Computer Telephony Protocol
6.2 簡単なコンピュータ・テレフォニプロトコル
6.2.1 Overview
6.2.1 概要
The Simple Computer Telephony Protocol (SCTP) is a third party call control protocol and as such does not comply with the PINT charter. SCTP is described in this section to show how PINT services could be implemented using SCTP, and where SCTP fits into the PINT architecture.
SimpleコンピュータTelephonyプロトコル(SCTP)は、第三者呼び出し制御プロトコルであり、そういうものとしてPINT特許に従いません。 SCTPは、SCTPを使用することでどうしたらPINTサービスを実装することができるだろうか、そして、SCTPがどこにPINTアーキテクチャに収まるかを示すためにこのセクションで説明されます。
In addition to third party call control, SCTP also provides subscriber (i.e., user) feature management (e.g., allows a user to set do not disturb, call forwarding parameters), and subscriber monitoring of terminal, line and address status. SCTP is strictly client/server-based. It has no provisions for peer to peer communications. SCTP runs as a TCP application protocol. It is ASCII-based and uses sockets. The SCTP Server is usually connected to a switch via a CTI (Computer-Telephony Integration) connection. Because of this, feature interactions are limited to those within the context of a single call, and not between PSTN services. The SCTP Server within a PINT Gateway could also be connected to an SN, or an SCP. See figures below. SCTP does NOT carry media.
In addition to third party call control, SCTP also provides subscriber (i.e., user) feature management (e.g., allows a user to set do not disturb, call forwarding parameters), and subscriber monitoring of terminal, line and address status. SCTP is strictly client/server-based. It has no provisions for peer to peer communications. SCTP runs as a TCP application protocol. It is ASCII-based and uses sockets. The SCTP Server is usually connected to a switch via a CTI (Computer-Telephony Integration) connection. Because of this, feature interactions are limited to those within the context of a single call, and not between PSTN services. The SCTP Server within a PINT Gateway could also be connected to an SN, or an SCP. See figures below. SCTP does NOT carry media.
Lu, et. al. Informational [Page 41] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 41] RFC 2458 Pre-PINT Implementations November 1998
6.2.2 How SCTP Fits in with the Reference PINT Services
6.2.2 How SCTP Fits in with the Reference PINT Services
SCTP Client as Part of a Web Server
SCTP Client as Part of a Web Server
+------+ +--------+ +--------+ +------+
| | | | SCTP | | | |
| |----| |-------| |----| |
| | | | | | | |
+------+ +--------+ +--------+ +------+
User's PC Web Server/ PINT Gateway SN/SCP/Switch
CGI
+------+ +--------+ +--------+ +------+ | | | | SCTP | | | | | |----| |-------| |----| | | | | | | | | | +------+ +--------+ +--------+ +------+ User's PC Web Server/ PINT Gateway SN/SCP/Switch CGI
Figure 14: SCTP Client as Part of a Web Server
Figure 14: SCTP Client as Part of a Web Server
In this architecture, the SCTP Client is embedded in the Web Server. It is there for the specific purpose of initiating calls to the PSTN based on user requests. The SCTP Server is within the PINT Gateway. We go through the classic PINT examples:
In this architecture, the SCTP Client is embedded in the Web Server. It is there for the specific purpose of initiating calls to the PSTN based on user requests. The SCTP Server is within the PINT Gateway. We go through the classic PINT examples:
Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the SCTP Server with the calling number supplied by Web page, and called number supplied by the user.
Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the SCTP Server with the calling number supplied by Web page, and called number supplied by the user.
Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP Server with called number set to user's fax machine, and calling number set to Web Server's fax machine, and treatment set to the URI for the file to be faxed. The SCTP Server takes the file and feeds it into the call just as a fax machine would.
Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP Server with called number set to user's fax machine, and calling number set to Web Server's fax machine, and treatment set to the URI for the file to be faxed. The SCTP Server takes the file and feeds it into the call just as a fax machine would.
Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number set to user's fax machine, and called number set to Web Server's fax machine. How the file is supplied to the user's fax machine is outside the scope of SCTP.
Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number set to user's fax machine, and called number set to Web Server's fax machine. How the file is supplied to the user's fax machine is outside the scope of SCTP.
Voice-access-to-content: SCTP Client issues an SCTP MakeCall with called number set to user's telephone number, and calling number set to Web Server and treatment set to a URI for the file of the particular Web page to be read to the called number. The SCTP Server takes care of the file to voice conversion and this is fed into the call as if it were voice.
Voice-access-to-content: SCTP Client issues an SCTP MakeCall with called number set to user's telephone number, and calling number set to Web Server and treatment set to a URI for the file of the particular Web page to be read to the called number. The SCTP Server takes care of the file to voice conversion and this is fed into the call as if it were voice.
In all of the above cases, the SCTP Client can generate a variety of different Web pages to send to the Web Server via CGI (Common Gateway Interface). The content of these pages is based on the call completion status of the CallMake SCTP action.
In all of the above cases, the SCTP Client can generate a variety of different Web pages to send to the Web Server via CGI (Common Gateway Interface). The content of these pages is based on the call completion status of the CallMake SCTP action.
Lu, et. al. Informational [Page 42] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 42] RFC 2458 Pre-PINT Implementations November 1998
SCTP Client Running on the User's PC
SCTP Client Running on the User's PC
+------+
HTML | | INTERNET
+-----+ /--------------| |
| |---/ +------+
| | Web Server
| |---\
+-----+ \
User's PC \ SCTP +------+ +------+
\------------| |-------| | PSTN
| | | |
+------+ +------+
PINT Gateway SN/SCP/Switch
+------+ HTML | | INTERNET +-----+ /--------------| | | |---/ +------+ | | Web Server | |---\ +-----+ \ User's PC \ SCTP +------+ +------+ \------------| |-------| | PSTN | | | | +------+ +------+ PINT Gateway SN/SCP/Switch
Figure 15: SCTP Client Running on the User's PC
Figure 15: SCTP Client Running on the User's PC
In this architecture, the user has an SCTP Client co-located with it. If the user is using the telephone line for connection to a Web Server and there is an incoming call, then the SCTP Server in the PINT Gateway will post this event to the SCTP Client. A window will pop up on the user's screen with options available to the user for handling of the incoming call. The user can choose to take the call, send it to voice mail, or send it to another number.
In this architecture, the user has an SCTP Client co-located with it. If the user is using the telephone line for connection to a Web Server and there is an incoming call, then the SCTP Server in the PINT Gateway will post this event to the SCTP Client. A window will pop up on the user's screen with options available to the user for handling of the incoming call. The user can choose to take the call, send it to voice mail, or send it to another number.
For the Fax back service, for example, if the user had a separate fax machine from his or her PC, then the SCTP Server would tell the SCTP Client there is an incoming fax. The user would end or suspend his or her Internet connection, the fax would come in, and the user could then resume the Internet connection.
For the Fax back service, for example, if the user had a separate fax machine from his or her PC, then the SCTP Server would tell the SCTP Client there is an incoming fax. The user would end or suspend his or her Internet connection, the fax would come in, and the user could then resume the Internet connection.
7. Session Initiation Protocol--An Emerging Standard
7. Session Initiation Protocol--An Emerging Standard
7.1 Overview
7.1 Overview
SIP, the Session Initiation Protocol, is a simple signaling protocol for Internet conferencing and telephony. It is currently under development within the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group.
SIP, the Session Initiation Protocol, is a simple signaling protocol for Internet conferencing and telephony. It is currently under development within the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group.
SIP provides the necessary mechanisms to support the following services:
SIP provides the necessary mechanisms to support the following services:
- call forwarding, including the equivalent of 700-, 800- and 900-
type calls;
- call-forwarding no answer;
- call forwarding, including the equivalent of 700-, 800- and 900- type calls; - call-forwarding no answer;
Lu, et. al. Informational [Page 43] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 43] RFC 2458 Pre-PINT Implementations November 1998
- call-forwarding busy;
- call-forwarding unconditional;
- other address-translation services;
- callee and calling "numbers" delivery, where the numbers can be of
any (preferably unique) naming scheme;
- personal mobility, i.e., the ability to reach a called party under
a single, location-independent address, even when the user changes
terminals;
- terminal-type negotiation and selection: a caller can be given a
choice of how to reach a party, e.g., via Internet telephony,
mobile, phone, and an answering service;
- caller and callee authentication;
- blind and supervised call transfer;
- user location; and
- invitation to multicast conferences.
- call-forwarding busy; - call-forwarding unconditional; - other address-translation services; - callee and calling "numbers" delivery, where the numbers can be of any (preferably unique) naming scheme; - personal mobility, i.e., the ability to reach a called party under a single, location-independent address, even when the user changes terminals; - terminal-type negotiation and selection: a caller can be given a choice of how to reach a party, e.g., via Internet telephony, mobile, phone, and an answering service; - caller and callee authentication; - blind and supervised call transfer; - user location; and - invitation to multicast conferences.
Extensions of SIP to allow third-party signaling (e.g., for click- to-dial-back services, fully meshed conferences and connections to Multipoint Control Units (MCUs), as well as mixed modes and the transition between those) have been specified.
Extensions of SIP to allow third-party signaling (e.g., for click- to-dial-back services, fully meshed conferences and connections to Multipoint Control Units (MCUs), as well as mixed modes and the transition between those) have been specified.
SIP addresses (URLs) can be embedded in Web pages. SIP is addressing-neutral, with addresses expressed as URLs of various types such as SIP, H.323 or telephone (E.164). A purely representational example of a SIP URL might be sip:+12125551212@foo.example.com, where foo.example.com is the host serving as a gateway into the PSTN.
SIP addresses (URLs) can be embedded in Web pages. SIP is addressing-neutral, with addresses expressed as URLs of various types such as SIP, H.323 or telephone (E.164). A purely representational example of a SIP URL might be sip:+12125551212@foo.example.com, where foo.example.com is the host serving as a gateway into the PSTN.
SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, ATM AAL5 or X.25, in rough order of desirability.
SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, ATM AAL5 or X.25, in rough order of desirability.
SIP can set up calls "out-of-band". For example, while the SIP protocol exchanges use IP, plus UDP or TCP, the actual data transport can take place via the PSTN. This feature makes it possible to use SIP to control a PBX or send requests to a Service Control Point. The PINT services make use of this flexibility.
SIP can set up calls "out-of-band". For example, while the SIP protocol exchanges use IP, plus UDP or TCP, the actual data transport can take place via the PSTN. This feature makes it possible to use SIP to control a PBX or send requests to a Service Control Point. The PINT services make use of this flexibility.
7.2 SIP Protocol
7.2 SIP Protocol
SIP is a textual client-server protocol, similar in syntax to HTTP and RTSP. Requests consist of a method (INVITE, BYE, ACK, or REGISTER), a list of parameter-value pairs describing the request and an optional request body. Parameters include the origin and destination of the call and a unique call identifier. They may indicate the caller's organization as well as the call's subject and priority. The request body contains a description of the call to be
SIP is a textual client-server protocol, similar in syntax to HTTP and RTSP. Requests consist of a method (INVITE, BYE, ACK, or REGISTER), a list of parameter-value pairs describing the request and an optional request body. Parameters include the origin and destination of the call and a unique call identifier. They may indicate the caller's organization as well as the call's subject and priority. The request body contains a description of the call to be
Lu, et. al. Informational [Page 44] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 44] RFC 2458 Pre-PINT Implementations November 1998
established or the conference to be joined. The description format is not prescribed by SIP; SDP is one possibility being standardized within the IETF. For the purposes of providing PINT services, an additional phone number address format is to be added to SDP.
established or the conference to be joined. The description format is not prescribed by SIP; SDP is one possibility being standardized within the IETF. For the purposes of providing PINT services, an additional phone number address format is to be added to SDP.
Responses indicate whether a request is still being processed, was successful, can possibly be satisfied by another node or failed. When a call is redirected, the response indicates the name of the node to be tried. Unsuccessful calls may also return a better time to try again.
Responses indicate whether a request is still being processed, was successful, can possibly be satisfied by another node or failed. When a call is redirected, the response indicates the name of the node to be tried. Unsuccessful calls may also return a better time to try again.
In a typical successful call, the caller sends an INVITE request to the callee. The callee accepts the call by returning a response code to the callee, which then confirms the receipt of that acceptance with an ACK request. Either side can terminate the call by sending a BYE request.
In a typical successful call, the caller sends an INVITE request to the callee. The callee accepts the call by returning a response code to the callee, which then confirms the receipt of that acceptance with an ACK request. Either side can terminate the call by sending a BYE request.
Requests can be authenticated using standard HTTP password and challenge-response mechanisms. Requests and responses may also be signed and encrypted.
Requests can be authenticated using standard HTTP password and challenge-response mechanisms. Requests and responses may also be signed and encrypted.
7.3 SIP entities
7.3 SIP entities
SIP distinguishes three kinds of entities:
SIP distinguishes three kinds of entities:
User agents receive and initiate calls and may forward the call.
User agents receive and initiate calls and may forward the call.
A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. A proxy server may, for example, locate a user and then attempt one or more possible network addresses.
A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. A proxy server may, for example, locate a user and then attempt one or more possible network addresses.
Redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls.
Redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls.
Proxy and redirect servers may make use of location servers that determine the current likely location of the callee.
Proxy and redirect servers may make use of location servers that determine the current likely location of the callee.
A PSTN gateway initiates phone calls between two parties. This may be a server that sends requests to an SCP in an IN environment or it may be a CTI-controlled PBX.
A PSTN gateway initiates phone calls between two parties. This may be a server that sends requests to an SCP in an IN environment or it may be a CTI-controlled PBX.
A SIP call may traverse one or more proxy servers.
A SIP call may traverse one or more proxy servers.
Lu, et. al. Informational [Page 45] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 45] RFC 2458 Pre-PINT Implementations November 1998
The servers that control a PBX or an SCP act as user agents. A Web server may also act as a SIP user agent.
The servers that control a PBX or an SCP act as user agents. A Web server may also act as a SIP user agent.
7.4 Providing Call Control Functionality
7.4 Providing Call Control Functionality
The SIP for PINT specification provides details on how to use SIP to initiate phone calls between two PSTN end points. (SIP can also initiate calls between Internet end points and between an Internet and PSTN end point, but this is beyond the scope of this document.)
The SIP for PINT specification provides details on how to use SIP to initiate phone calls between two PSTN end points. (SIP can also initiate calls between Internet end points and between an Internet and PSTN end point, but this is beyond the scope of this document.)
It should be noted that the SIP client for initiating such phone calls can be either at the user's location (his/her workstation) or can be a Web server that calls up a SIP client via a CGI program. There is no difference in operation or functionality, except that the owner of the Web server may be legally responsible for the calls made.
It should be noted that the SIP client for initiating such phone calls can be either at the user's location (his/her workstation) or can be a Web server that calls up a SIP client via a CGI program. There is no difference in operation or functionality, except that the owner of the Web server may be legally responsible for the calls made.
A SIP client needs to convey two addresses to the PSTN gateway: the party making the call and the party to be called. (The party to be billed also needs to be identified; this can either be done by a SIP header or by having the server look up the appropriate party based on the two parties. This aspect is for further study.)
A SIP client needs to convey two addresses to the PSTN gateway: the party making the call and the party to be called. (The party to be billed also needs to be identified; this can either be done by a SIP header or by having the server look up the appropriate party based on the two parties. This aspect is for further study.)
Described below are three ways these addresses can be conveyed in SIP. In the example, the address of party A is +1-212-555-1234 and that of party B is +1-415-555-1200. (The URL types in this and other examples are representational; they may but do not have to exist.)
Described below are three ways these addresses can be conveyed in SIP. In the example, the address of party A is +1-212-555-1234 and that of party B is +1-415-555-1200. (The URL types in this and other examples are representational; they may but do not have to exist.)
(1) The two PSTN addresses are contained in the To header (and request-URI) and an Also header. For example:
(1) The two PSTN addresses are contained in the To header (and request-URI) and an Also header. For example:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
Also: phone:+1-415-555-1200
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 To: phone:1-212-555-1234 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com Also: phone:+1-415-555-1200
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
v=0 o=user1 53655765 2353687637 IN IP4 128.3.4.5 c=PSTN E.164 +1-415-555-1200 t=0 0 m=audio 0 RTP/AVP 0
In that case, the gateway first connects to party A and then party B, but without waiting for A to accept the call before calling B.
In that case, the gateway first connects to party A and then party B, but without waiting for A to accept the call before calling B.
Lu, et. al. Informational [Page 46] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 46] RFC 2458 Pre-PINT Implementations November 1998
(2) Parties A and B are indicated by separate invitations. This allows the gateway to make sure that party A is indeed available before calling party B. After calling party A, the gateway could play an announcement indicating that the call is being connected using, for example, RTSP with appropriate Conference header indicating the call.
(2) Parties A and B are indicated by separate invitations. This allows the gateway to make sure that party A is indeed available before calling party B. After calling party A, the gateway could play an announcement indicating that the call is being connected using, for example, RTSP with appropriate Conference header indicating the call.
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0
To: phone:+1-415-555-1200
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 To: phone:1-212-555-1234 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com ... INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0 To: phone:+1-415-555-1200 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com ...
(3) The two PSTN addresses are conveyed in the To header of the SIP request and the address in the SDP media description. Thus, a request may look as follows:
(3) The two PSTN addresses are conveyed in the To header of the SIP request and the address in the SDP media description. Thus, a request may look as follows:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 To: phone:1-212-555-1234 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
v=0 o=user1 53655765 2353687637 IN IP4 128.3.4.5 c=PSTN E.164 +1-415-555-1200 t=0 0 m=audio 0 RTP/AVP 0
Here, pbx.example.com is the name of the PSTN gateway; the call will be established between 1-212-555-1234 and +1-415-555-1200.
Here, pbx.example.com is the name of the PSTN gateway; the call will be established between 1-212-555-1234 and +1-415-555-1200.
Users can be added to an existing call by method (1) or (2).
Users can be added to an existing call by method (1) or (2).
8. Overall Security Considerations
8. Overall Security Considerations
Inter-networking of the Internet and PSTN necessitates the introduction of new interfaces (e.g., the A, B and E interfaces in Figure 6). To ensure that their use does not put the networks, in particular the PSTN, at additional security risk, these interfaces need to be designed with proper security considerations. Sections
Inter-networking of the Internet and PSTN necessitates the introduction of new interfaces (e.g., the A, B and E interfaces in Figure 6). To ensure that their use does not put the networks, in particular the PSTN, at additional security risk, these interfaces need to be designed with proper security considerations. Sections
Lu, et. al. Informational [Page 47] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 47] RFC 2458 Pre-PINT Implementations November 1998
5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, the Lucent and Siemens systems, handle the security aspect, respectively.
5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, the Lucent and Siemens systems, handle the security aspect, respectively.
Worth noting are the security requirements suggested by pre-PINT experiences. They are:
Worth noting are the security requirements suggested by pre-PINT experiences. They are:
+Peer entity authentication to allow a communicating entity to prove its identity to another in the network (e.g., the requesting IP-host to the PINT gateway, and the PINT gateway to the PSTN node providing the service control function).
+Peer entity authentication to allow a communicating entity to prove its identity to another in the network (e.g., the requesting IP-host to the PINT gateway, and the PINT gateway to the PSTN node providing the service control function).
+Authorization and access control to verify if a network entity (e.g., the requesting IP-host) is allowed to use a network resource (e.g., requesting services from the PINT gateway).
+Authorization and access control to verify if a network entity (e.g., the requesting IP-host) is allowed to use a network resource (e.g., requesting services from the PINT gateway).
+Non-repudiation to account for all operations in case of doubt or dispute.
+Non-repudiation to account for all operations in case of doubt or dispute.
+Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner.
+Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner.
In the course of the PINT interface development, additional requirements are likely to arise. It is imperative that the resultant interfaces include specific means to meet all the security requirements.
In the course of the PINT interface development, additional requirements are likely to arise. It is imperative that the resultant interfaces include specific means to meet all the security requirements.
9. Conclusion
9. Conclusion
This document has provided the information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting PINT services. Specifically, it addressed technologies, architectures, and several existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.
This document has provided the information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting PINT services. Specifically, it addressed technologies, architectures, and several existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.
10. Acknowledgments
10. Acknowledgments
The authors would like to acknowledge Scott Bradner, Igor Faynberg, Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments presented to the discussions in the PINT Working Group that lead to the creation of this document.
The authors would like to acknowledge Scott Bradner, Igor Faynberg, Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments presented to the discussions in the PINT Working Group that lead to the creation of this document.
Lu, et. al. Informational [Page 48] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 48] RFC 2458 Pre-PINT Implementations November 1998
11. Appendix
11. Appendix
11.1 PSTN/IN 101
11.1 PSTN/IN 101
11.1.1 Public Switched Telephone Network
11.1.1 Public Switched Telephone Network
What is normally considered as "the Telephone Network" consists of a set of interconnected networks. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs with which it is interconnected. Calls on the PSTN are circuit switched; that is, a bi-directional connection is made between the calling and called terminals for the duration of the call. In PSTNs the connection is usually carried through the network in digital format occupying a fixed bandwidth; this is usually 56 or 64 Kbps. The overall configuration of the PSTN is shown in Figure 16.
What is normally considered as "the Telephone Network" consists of a set of interconnected networks. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs with which it is interconnected. Calls on the PSTN are circuit switched; that is, a bi-directional connection is made between the calling and called terminals for the duration of the call. In PSTNs the connection is usually carried through the network in digital format occupying a fixed bandwidth; this is usually 56 or 64 Kbps. The overall configuration of the PSTN is shown in Figure 16.
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
/--\ ()/\()__ /__\ \ ................................. \ ! ! ! /--\ __ \ [-!-] [-!-] ! ()/\() \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ [Fax]________[---] [---] \\ [-!-] / __ \\=======[CO ]____/ \ \ [---]________[Fax] Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links
Figure 16
Figure 16
Messages are sent between the Switches to make and dissolve connections through the network on demand and to indicate the status of terminals involved in a call; these "signaling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signaling network is also known as the Common Channel Signaling (CCS) or Signaling System Number 7 (or SS7) network after the names of the signaling protocol suite used.
Messages are sent between the Switches to make and dissolve connections through the network on demand and to indicate the status of terminals involved in a call; these "signaling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signaling network is also known as the Common Channel Signaling (CCS) or Signaling System Number 7 (or SS7) network after the names of the signaling protocol suite used.
As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones or Facsimile machines as terminals. Call requests are indicated to the Central Office to which
As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones or Facsimile machines as terminals. Call requests are indicated to the Central Office to which
Lu, et. al. Informational [Page 49] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 49] RFC 2458 Pre-PINT Implementations November 1998
a telephone is connected either by a sequence of pulses or tone pairs being sent. Notifications on the status of the request are sent back to the telephone in the form of tones. Indication from a Central Office that a call is being offered to a telephone is arranged by sending an alternating voltage down the access connection which in turn causes the ringer in the telephone to sound. These access lines have a unique address associated with them and can support a single call.
a telephone is connected either by a sequence of pulses or tone pairs being sent. Notifications on the status of the request are sent back to the telephone in the form of tones. Indication from a Central Office that a call is being offered to a telephone is arranged by sending an alternating voltage down the access connection which in turn causes the ringer in the telephone to sound. These access lines have a unique address associated with them and can support a single call.
However, with analogue or digital multi-line connections, or Integrated Service Digital Network (ISDN) Basic or Primary Rate Interfaces (BRI or PRI), several concurrent calls are possible and a set of addresses are associated with them. The new ISDN access connections are designed so that data exchanged with the network is in multiplexed digital form, and there is an individual channel for each of the potential connections, together with a separate channel dedicated to sending and receiving call request and call alert data as well as carrying packet switched user data. These call request and call alert messages act as the equivalent of the pulses or tones that are sent when dialing, and the ringing signal that is sent to a telephone when a call is being made to it.
However, with analogue or digital multi-line connections, or Integrated Service Digital Network (ISDN) Basic or Primary Rate Interfaces (BRI or PRI), several concurrent calls are possible and a set of addresses are associated with them. The new ISDN access connections are designed so that data exchanged with the network is in multiplexed digital form, and there is an individual channel for each of the potential connections, together with a separate channel dedicated to sending and receiving call request and call alert data as well as carrying packet switched user data. These call request and call alert messages act as the equivalent of the pulses or tones that are sent when dialing, and the ringing signal that is sent to a telephone when a call is being made to it.
The operation of the call request is fairly simple in most cases and is shown in Figure 17.
The operation of the call request is fairly simple in most cases and is shown in Figure 17.
/--\
() ()
--____
/++\ \ ................................. /--\
/----\ \ ^ v ! () ()
A \ [-!-] [-!-] ! --
\->[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B
[---]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
/--\ () () --____ /++\ \ ................................. /--\ /----\ \ ^ v ! () () A \ [-!-] [-!-] ! -- \->[CO ]=========[CO ]==\\ v ->-/ \ [---] [---] \\ [-!-] / /----\ \\=======[CO ]____/ B [---] Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links CO Central Office (Telephone Exchange)
Figure 17
Figure 17
The user presses a sequence of numbers on a telephone handset (labeled A), and the telephone passes a sequence of digits (either as pulses or tone pairs) to the Central Office via the access line. The Central Office contains a processor that will be notified that the user has made a request and the digit string that is the sole parameter of the request. This digit string is taken to be the unique
The user presses a sequence of numbers on a telephone handset (labeled A), and the telephone passes a sequence of digits (either as pulses or tone pairs) to the Central Office via the access line. The Central Office contains a processor that will be notified that the user has made a request and the digit string that is the sole parameter of the request. This digit string is taken to be the unique
Lu, et. al. Informational [Page 50] RFC 2458 Pre-PINT Implementations November 1998
Lu, et. al. Informational [Page 50] RFC 2458 Pre-PINT Implementations November 1998
address of an access line connected either to itself or to another Central Office. There is a hierarchical addressing scheme, so that the digit string can be parsed easily. A call request to a terminal (labeled B) connected to a remote Central Office can be routed by examining the digit string passed; the Central Office will extract the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-Switch call request and passing it via the signaling network. At the same time it will allocate one of its available transmission channels towards the remote Central Office.
address of an access line connected either to itself or to another Central Office. There is a hierarchical addressing scheme, so that the digit string can be parsed easily. A call request to a terminal (labeled B) connected to a remote Central Office can be routed by examining the digit string passed; the Central Office will extract the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-Switch call request and passing it via the signaling network. At the same time it will allocate one of its available transmission channels towards the remote Central Office.
11.1.2 Intelligent Network
11.1.2 Intelligent Network
This scheme has been used since the 1950s, and suffices for the majority of calls. However, there are a range of other services that can be (and have been) provided, enhancing this basic call processing. Freephone or Premium Rate services (1-800 or 1-900 services) are good examples of the supplementary services that have been introduced. Apart from the important feature that the cost of these calls is varied so that the caller does not pay for a free- phone call, or pays an extra charge for a premium rate call, they have the similarity that the number dialed must be translated to arrive at the "real" address of the destination terminal. They are known as number translation services, and make up the bulk of all supplementary services delivered today.
This scheme has been used since the 1950s, and suffices for the majority of calls. However, there are a range of other services that can be (and have been) provided, enhancing this basic call processing. Freephone or Premium Rate services (1-800 or 1-900 services) are good examples of the supplementary services that have been introduced. Apart from the important feature that the cost of these calls is varied so that the caller does not pay for a free- phone call, or pays an extra charge for a premium rate call, they have the similarity that the number dialed must be translated to arrive at the "real" address of the destination terminal. They are known as number translation services, and make up the bulk of all supplementary services delivered today.
These were originally programmed into each Central Office, but the complexity of maintaining the data tables on each processor grew cumbersome, so a more general solution was sought. After a considerable gestation period, the eventual solution was the Intelligent Network. This takes the separation of Central Offices and the network links interconnecting them a stage further.
These were originally programmed into each Central Office, but the complexity of maintaining the data tables on each processor grew cumbersome, so a more general solution was sought. After a considerable gestation period, the eventual solution was the Intelligent Network. This takes the separation of Central Offices and the network links interconnecting them a stage further.
The Central Offices are considered to provide the Call Control Function (CCF). In addition, the Service Switching Function (SSF) is provided to "enhance" the operation of these Switches by detecting when a particular request has been made (such as by dialing 1-800). If this pattern is detected, the equipment implementing the SSF will send a specialized request message over the signaling network to a separate computer that implements the Service Control Function (SCF). This entity is responsible for querying service specific data (held in a unit providing the Service Data Function, or SDF), performing any digit translations necessary, and sending the details of how to proceed back to the SSF, where they are obeyed and the call is put through to the "real" destination. In many implementations, the SDF is closely coupled to the SCF. This configuration is shown in Figure 18.
セントラルオフィスがCall Control Function(CCF)を提供すると考えられます。 さらに、いつ特定の要求をしたかを(1-800にダイヤルすることなどの)検出することによってこれらのSwitchesの操作を「高める」ために、Service Switching Function(SSF)を提供します。 このパターンが検出されると、SSFを実行する設備はService Control Function(SCF)を実行する別々のコンピュータへのシグナル伝達ネットワークの上に専門化している要求メッセージを送るでしょう。 この実体はサービス詳細データ(ユニットでは、Service Data Function、またはSDFを提供しながら、成立する)について質問するのに原因となります、どんなケタ翻訳も実行して必要である、そして、どう続くかに関する詳細をSSFに送り返すこと。そこでは、それらが従われて、呼び出しは「本当」の目的地に成功します。 多くの実現では、SDFは密接にSCFと結合されます。 この構成は図18に示されます。
Lu, et. al. Informational [Page 51] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [51ページ]情報のRFC2458プレパイント実現1998年11月
[---] [---] [---]
/--\ [SRF] [SCF] [SDF]
()/\()__ [|-!] [-!-] [-!-]
/__\ \ || \.............!......!........
\ || / ! ! /--\
__ \ [|-!] [-!-] ! ()/\()
\ \ \__[SSF] [CCF] ! ___/__\
[Fax]________[CCF]=========[---]==\\ [!--] / __
\\========[CCF]__/ \ \
[---]_______[Fax]
Key: ___ access relationship
=== trunk relationship
... signaling relationship
[---] [---][---]/--\[SRF][SCF][SDF]()/\()__、[|、-、]! [-!-] [-!-] /__\ \ || \.............!......!........ \ || / ! ! /--\ __ \ [|-!] [-!-] ! ()/\() \ \ \__[SSF] [CCF] ! ___/__\[ファックス]________[CCF]=========[---]==\\ [!--] / __ \\========[CCF]__/\\[---]_______[ファックス]キー: ___ アクセス関係=== トランク関係…シグナリング関係
Figure 18
図18
The advantage is that there can be a much smaller number of physical units dedicated to the SCF, and as they are connected to the signaling network they can be contacted by, and can send instructions back to, all of the units providing the SSF and thus the CCF.
利点はSCF、それらが連絡できて、指示を送り返すことができるシグナル伝達ネットワークに接続されるので捧げられたはるかに少ない数の物理装置があることができるということです、SSFとその結果CCFを提供するユニットのすべて。
In another enhancement, a separate entity called the Special Resource Function (SRF) was defined. Equipment implementing this function includes announcement units to play recorded messages (for example, prompts to enter digits) to callers. It will also include the tone decoders needed to capture any digits pressed by the caller in response to the prompts. It is connected to the rest of the PSTN usually via trunk data links. It will also include a signaling connection (directly or indirectly) back to the SCF, via the PSTN's core signaling network.
別の増進では、Special Resource Function(SRF)と呼ばれる別々の実体は定義されました。 この機能を実行する設備は、録音メッセージ(例えば、ケタを入れるプロンプト)を訪問者にプレーするために発表ユニットを含んでいます。 また、それはプロンプトに対応して訪問者によって押されたどんなケタも得るのに必要であるトーンデコーダを含むでしょう。 それは通常トランクデータ・リンクを通してPSTNの残りに接続されます。 また、それはPSTNのコアシグナル伝達ネットワークを通してシグナリング接続(直接か間接的である)をSCFに含めて戻すでしょう。
As an example of the way that these different functional entities interact, the SCF can ask an SSF handling a call to route the caller temporarily through to an SRF. In response to instructions sent to it from the SCF over the signaling network, the SRF can play announcements and can collect digits that the user presses on their terminal in response to prompts they are played. Once these digits have been collected they can be passed on to the SCF via a signaling message for further processing. In normal operation, the SCF would then ask the SSF to dissolve the temporary connection between the user's terminal and the SRF. This allows the collection of account numbers or passwords (or PINs) and forms the heart of many "Calling Card" services.
これらの異なった機能的な実体が相互作用する方法に関する例として、SCFは一時SRFに終えた訪問者を発送するという要求をSSF取り扱いに尋ねることができます。 シグナル伝達ネットワークの上でSCFからそれに送られた指示に対応して、SRFは発表をプレーできて、プレーされて、ユーザがそれらの端末でプロンプトに対応して押すケタを集めることができます。 これらのケタがいったん集められると、さらなる処理へのシグナリングメッセージでそれらをSCFに通過できます。 そして、通常の操作では、SCFは、ユーザの端末とSRFとの一時性結合を溶かすようにSSFに頼むでしょう。 これは、口座番号かパスワード(または、暗証番号)の収集を許して、多くの「テレホンカード」サービスの心を形成します。
Lu, et. al. Informational [Page 52] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [52ページ]情報のRFC2458プレパイント実現1998年11月
This pattern of user interaction is also used in a wide variety of other services where extra account information and PINs are needed. They are collected as just described and can be checked against the correct values stored in the service database prior to allowing the call to proceed.
また、ユーザ相互作用のこのパターンは余分な会計情報と暗証番号が必要である他のサービスの広いバラエティーに使用されます。 それらをただ説明されているとして集めて、続くという要求を許す前にサービスデータベースに格納された正しい値に対してチェックできます。
The Intelligent Network functional entities can be realized as physical units in a number of different combinations. A common configuration is shown in Figure 19.
物理装置として多くの異なった組み合わせでIntelligent Networkの機能的な実体を実現できます。 一般的な構成は図19に示されます。
[---] [---] [---] [---]
/--\ [I.P] [SCP] [SDP] [SN ]
()/\()__ [|-!] [-!-] [-!-] [--|]
/__\ \ || \.............!.....!..... |
\ || / ! \ | /--\
__ \ [|-!] [-!-] \ | ()/\()
\ \ \__[SSP]=========[CO ]==\\ \ | ___/__\
[Fax]________[---] [---] \\ [!-|] / __
\\=======[CO ]__/ \ \
[---]_______[Fax]
[---] [---][---][---]/--\[I.P][SCP][SDP][SN]()/\()__、[|、-、]! [-!-] [-!-] [--|] /__\ \ || \.............!.....!..... | \ || / ! \ | /--\ __ \ [|-!] [-!-] \ | ()/\() \ \ \__[SSP]=========[CO]=\\\| ___/__\[ファックス]________[---] [---] \\ [!-|] / __ \\=======[CO]__/\\[---]_______[ファックス]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
SSP Service Switching Point - a unit that implements the
Service Switching Function
CCP Call Control Point - a unit that performs call control
functions.
This is normally a kind of Central Office (shown as CO
above)
SCP Service Control Point - a unit implementing the Service
Control Function. NOTE that this is connected to the SS7
Network and uses this connection for all of its
communications.
I.P Intelligent Peripheral - a unit that contains specialized
resources (like announcement units, tone decoders).
In effect, it implements Special Resource Functions.
SN Service Node
キー: ___ アクセス回線=== Trunkリンクス(相互COユーザデータ・リンク)… 相互COシグナル伝達ネットワークはSSP Service Switching Point--Service Switching Function CCP Call Control Pointを実行するユニット--呼び出しコントロール機能を実行するユニットをリンクします。 通常、これは一種のセントラルオフィス(上のCOとして、目立つ)SCP Service Control Pointです--Service Control Functionを実行するユニット。 注意、これは、SS7 Networkに接続されて、コミュニケーションのすべてにこの接続を使用します。 I.のP知的なPeripheral--それが含むユニットはリソースを専門にしました(発表ユニットのように、デコーダに調子を変えさせてください)。 事実上、それはSpecial Resource Functionsを実行します。 SNサービスノード
Figure 19
図19
This diagram also shows a unit called a Service Node, or SN. This contains components that realize all of the operational Intelligent Network functions (SSF, SCF, SDF, and SRF). It is sometimes more convenient to have all of these elements in one node (for example, for operations and maintenance reasons), particularly within smaller PSTNs or where there is a relatively low level of requests for
また、このダイヤグラムはService Node、またはSNと呼ばれるユニットを示しています。 これは操作上のIntelligent Network機能(SSF、SCF、SDF、およびSRF)のすべてがわかるコンポーネントを含んでいます。 それは時々特により小さいPSTNsかそれとも比較的低いレベルの要求がどこにあるかの中の1つのノード(例えば操作と維持理由で)にこれらの要素のすべてを持つのに便利な状態で、より多いです。
Lu, et. al. Informational [Page 53] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [53ページ]情報のRFC2458プレパイント実現1998年11月
particular services. Another difference is that, as they are all co- located, proprietary protocols can be used for internal communication, rather than the full Intelligent Network Application Part (INAP) protocol used over the core signaling network between discrete units. It also differs from the "unbundled" approach in that it is connected to the COs within a PSTN as a peripheral, having only an access connection to a Central Office; there is no connection to the core signaling network. Other than this, it operates in a similar way, and can provide the same kinds of services. Information on the specification of the Intelligent Network can be found in the ITU recommendations [1], while two books ([2] and [3]) describe the system, its history, operation, and the philosophy behind it.
特定のサービス。 別の違いはそれらがすべて共同見つけられているとき離散的なユニットの間のコアシグナル伝達ネットワークの上で使用される完全なIntelligent Network Application Part(INAP)プロトコルよりむしろ内部のコミュニケーションに固有のプロトコルを使用できるということです。 また、それはそれが周辺機器としてPSTNの中のCOsに接続されるという点において"「非-束ね」"のアプローチと異なっています、セントラルオフィスにはアクセス接続しかなくて。 コアシグナル伝達ネットワークとの接続が全くありません。 これを除いて、それは、同様の方法で作動して、同じ種類のサービスを提供できます。 ITU推薦[1]でIntelligent Networkの仕様に関する情報を見つけることができます、2冊の本([2]と[3])がそれの後ろでシステム、歴史、操作、および哲学について説明しますが。
11.2 Call Center Features
11.2 コールセンターの特徴
A Call Center is a system that allows a company to be organized with a group of similar individuals (agents), all of whom can either make calls to, or take calls from, customers. The system distributes incoming calls to the agents based on their availability and automates the placement of outgoing calls, selecting an agent to handle the call and routing the call to them only once the call request has been made of the PSTN.
Callセンターは会社がそのすべてが顧客から電話をかけるか、または呼び出しを取ることができる同様の個人(エージェント)のグループと共に組織化されるのを許容するシステムです。 システムは、彼らの有用性に基づくエージェントにかかってきた電話を広げて、発信電話のプレースメントを自動化します、PSTNで発呼要求をいったんするとだけ、エージェントが呼び出しを扱うのを選択して、呼び出しをそれらに発送して。
The incoming call distribution feature ("automatic call
distribution", or ACD) is usually coupled with a call queuing scheme.
In this scheme, the callers are connected temporarily with an
announcement unit that normally plays music. The calls are treated in
sequence so that (once the caller is at the front of the queue) the
ACD system selects the next available agent and routes the call
through to them.
通常、かかってきた電話分配機能(「自動呼び出し分配」、またはACD)は呼び出し列を作り計画に結びつけられます。 この計画では、訪問者は一時通常、音楽を演奏する発表ユニットに接続されます。 呼び出しは、連続して、(訪問者が待ち行列の前部にいったんいると)ACDシステムが次期手があいているエージェントを選んで、それらにおいて終えた呼び出しを発送するように、扱われます。
Another feature connects a customer making an incoming call to a unit that asks them for some information on the purpose of their call, selecting the agent to handle the call based on the particular area of expertise needed; to do this, the agents are further categorized by their knowledge (or "Skill Set"). If this skill set categorization is used then by implication there will be separate queues for each of the skill sets. This user selection scheme can be used independently of the others. For example these so-called "voice navigation systems" can be used to select a particular department extension number, based on the function required by the customer; as such, they can automate the job of company telephone receptionist in routing incoming calls.
別の特徴はかかってきた電話を彼らの呼び出しの目的の何らかの情報をそれらに求めるユニットまでしている顧客に接します、エージェントが必要である専門的技術の特定の領域に基づく呼び出しを扱うのを選択して。 これをするために、エージェントは彼らの知識(または、「スキルセット」)によってさらに分類されます。 このスキルセット分類がその時含意によって使用されると、それぞれのスキルセットのための別々の待ち行列があるでしょう。 他のものの如何にかかわらずこのユーザ選択計画を使用できます。 特定の部の内線電話番号を選択するのに例えば、これらのいわゆる「声のナビゲーションシステム」を使用できます、顧客によって必要とされた機能に基づいて。 そういうものとして、彼らはかかってきた電話を発送することにおける、会社の電話受付係の仕事を自動化できます。
Where possible, the information gleaned from the customer can be provided to the selected agent, usually via a separate networked computer connection. Similarly, if an outgoing call is being made to one of a list of customers, information on the customer and the purpose of the call can be provided to the agent selected to handle
可能であるところでは、顧客から収集された情報は選択されたエージェントに提供できます、通常別々のネットワーク・コンピュータ接続で。 同様に、ハンドルには顧客リストの1つまで作られていて、顧客の情報と呼び出しの目的を選ばれたエージェントに提供できるということであることが発信電話であるならありますか?
Lu, et. al. Informational [Page 54] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [54ページ]情報のRFC2458プレパイント実現1998年11月
the call. Such configurations are generally called "Computer Telephony Integration" or CTI systems. Strictly, a CTI system can be arranged to handle routing of incoming calls and automation of outgoing calls only (also known as computer integrated telephony features), without the agents having access to a network of computers. However, the business case for combining the telephony functions of the call center with provision to the agents of computers with customer information can be compelling.
呼び出し。 一般に、そのような構成は「コンピュータ・テレフォニー・インテグレーション」かCTIシステムと呼ばれます。厳密に、かかってきた電話のルーティングと発信電話のオートメーションだけを扱うためにCTIシステムをアレンジできます、エージェントがコンピュータのネットワークに近づく手段を持っていなくて。 しかしながら、顧客情報でコールセンターの電話機能をコンピュータのエージェントへの支給に結合するためのビジネスケースは無視できない場合があります。
This is often further combined with a company's order and service processing computer system. In this case, a call is treated as part of a business transaction, with the information to be exchanged captured as fields of a computer form. While such a computer system is not, strictly, part of a call center, integrating the company computer system with the call center is very common. This allows the details of the call to be stored on a centralized database, allowing further automated order processing, for example. It also allows the call to be transferred from one agent to another where needed, ensuring that the new agent has the information already captured. This might be useful if someone with a different area of expertise were to be needed to handle the customer's requirements.
これはさらに会社の注文とサービス処理コンピュータ・システムにしばしば結合されます。 この場合、呼び出しは情報で商取引の一部として扱われて、コンピュータフォームの分野として捕らわれた状態で交換します。 そのようなコンピュータ・システムは厳密にコールセンターの一部ではありませんが、会社のコンピュータ・システムをコールセンターと統合するのは非常に一般的です。 これは集中データベースに格納されるという要求の詳細を許容します、例えばさらなる自動化された注文処理を許容して また、それは必要であるところで1人のエージェントから別のエージェントまで移されるという要求を許します、新しいエージェントが情報を既に得させるのを確実にして。 専門的技術の異なった領域をもっているだれかが顧客の要求を扱うのが必要であることになっているなら、これは役に立つでしょうに。
Traditionally, Call Centers have been used to support teams of agents working at a single site (or a small number of sites, with private telephony trunks interconnecting them). The site Private Automatic Branch eXchange (PABX) was integrated with a computer system to provide these features to people at that site. There can be a business case for provision of such features to distributed teams of workers as well. In particular, the possibility of providing support for people working from home has been seen as important. Some of the Call Center features have been incorporated into public telephone exchanges or Central Offices (COs) from many manufacturers as part of their "Centrex" service offerings.
伝統的に、Callセンターズは、ただ一つのサイト(または、個人的な電話本体がそれらとインタコネクトしている少ない数のサイト)で働いているエージェントのチームを支持するのに使用されました。 サイト兵士のAutomatic支店eXchange(PABX)は、そのサイトの人々にこれらの特徴を提供するためにコンピュータ・システムと統合されました。 また、労働者の分配されたチームへのそのような特徴の支給のためのビジネスケースがあることができます。 特に、家から働いている人々のサポートを提供する可能性は重要であるとみなされました。 彼らの「セントレックス」サービス提供の一部としてCallセンターの特徴のいくつかを多くのメーカーから公衆電話交換かセントラルオフィス(COs)に組み入れてあります。
There are practical limitations in providing such features on COs. Apart from the procedures needed to configure these features for any telephone line that is to use them, the basic requirement that every agent must have a connection to the supporting CO can limit its usefulness. Another approach is to provide Call Center features via the Intelligent Network. The features might thus be provided over a Telephone Operator's entire network, and would mean that the Call Center could be configured centrally while still allowing agents to be located anywhere within the telephone network. It also means that the supported company can pay for the Call Center features "as they go" rather than having a high "up front" cost.
COsに関するそのような特徴を提供するのにおいて実用的な制限があります。 それらを使用することになっているどんな電話回線のためのこれらの特徴も構成するのに必要である手順は別として、サポートCOにはすべてのエージェントが接続がいなければならないという基本的な要件は有用性を制限できます。 別のアプローチはIntelligent Networkを通してセンターの特徴をCallに供給することです。 特徴は、その結果、Telephone Operatorの全体のネットワークの上に前提とされるかもしれなくて、エージェントが電話網の中でどこでも位置するのをまだ許容している間中心でCallセンターを構成できたことを意味するでしょう。 また、それは、支持された会社が高値を「前払いで」かからせるよりむしろ「彼らは行く」ときセンターが特集するCallの対価を支払うことができることを意味します。
Lu, et. al. Informational [Page 55] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [55ページ]情報のRFC2458プレパイント実現1998年11月
12. References
12. 参照
[1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[1] ITU-T Q.12xx推薦シリーズ、ジュネーブ、1995。
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
Intelligent Network Standards, their Application to Services",
McGraw-Hill, 1996.
[2]I.FaynbergとL.R.Gabuzda、M.P.キャプランとN.J.シャー、「Intelligent Network Standards、Servicesへの彼らのApplication」マグロウヒル、1996。
[3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic
Technology, Standards and Evolution", Intl. Thomson Computer
Press, 1996.
[3] T.MagedanzとR.Popesku-Zeletin、「インテリジェントネットワーク:」 「基礎技術、規格、および発展」、Intl。 トムソンコンピュータプレス、1996。
[4] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December, 1987.
[4] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構国際規格8824(1987年12月)の仕様。
[5] McCloghrie, K., Editor, "Structure of Management Information for
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1902, January 1996.
[5]McCloghrie、K.、エディタ、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2109, February 1997.
[6] クリストルとD.とL.Montulli、「HTTP国家管理メカニズム」、RFC2109、1997年2月。
[7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288
December 1991.
[7] ジンマーマン、D.、「指のユーザー情報プロトコル」、RFC1288 1991年12月。
Lu, et. al. Informational [Page 56] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [56ページ]情報のRFC2458プレパイント実現1998年11月
Authors' Addresses
作者のアドレス
Steve Bellovin AT&T Labs Room E-215 180 Park Ave. Bldg. 103 Florham Park, NJ 07932-0000 USA
スティーブBellovin AT&T研究室Room E-215 180はAveを駐車します。 ビルディング 103Florham公園、ニュージャージー07932-0000米国
Phone: +1 973 360 8656 Fax: +1 973 360 8077 EMail: smb@research.att.com
以下に電話をしてください。 +1 973 360、8656Fax: +1 8077年の973 360メール: smb@research.att.com
Fred M. Burg AT&T Labs Room 1N-117 307 Middletown Lincroft Road Lincroft, NJ 07738 USA
フレッドM.町のAT&T研究室部屋1N-117 307ミドルタウンLincroft道路Lincroft、ニュージャージー07738米国
Phone: +1 732 576 4322 Fax: +1 732 576 4317 EMail: fburg@hogpb.att.com
以下に電話をしてください。 +1 732 576、4322Fax: +1 4317年の732 576メール: fburg@hogpb.att.com
Lawrence Conroy Roke Manor Research Limited IT&N-INIA Group Roke Manor, Old Salisbury Lane, Romsey, Hampshire SO51 0ZN U.K.
ローレンスコンロイRoke荘園研究はそれとN-INIAグループRoke荘園、古いソールズベリーレイン、ロムジー、ハンプシャーSO51 0ZNイギリスを制限しました。
Phone: +44 1794 833666 Fax: +44 1794 833434 EMail: lwc@roke.co.uk
以下に電話をしてください。 +44 1794 833666、Fax: +44 1794 833434はメールされます: lwc@roke.co.uk
Paul Davidson Nortel P.O.Box 3511 Station "C" Mail Stop 242 Ottawa, Ontario, Canada K1Y 4H7
ポールディヴィッドソンノーテルP.O.Box3511駅「C」はオタワ、オンタリオ、停止242カナダK1Y 4H7に郵送します。
Phone: +1 613 763 4234 EMail: pauldav@nortel.ca
以下に電話をしてください。 +1 4234年の613 763メール: pauldav@nortel.ca
Lu, et. al. Informational [Page 57] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [57ページ]情報のRFC2458プレパイント実現1998年11月
A. DeSimone Lucent Technologies Room 6H510 600-700 Mountain Avenue Murray Hill, NJ 07974-0636 USA
A.DeSimoneルーセントテクノロジーズの余地の6H510 600-700山のAvenueニュージャージー07974-0636マリー・ヒル(米国)
Phone: +1 908 582 2382 Fax: +1 908 582 1086 E-Mail:tds@lucent.com
以下に電話をしてください。 +1 908 582、2382Fax: +1 1086年の908 582メール: tds@lucent.com
Murali Krishnaswamy Bell Laboratories Lucent Technologies Room 2G-527a 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Crawfordsコーナー道路Holmdel、Murali Krishnaswamyベル研究所ルーセントテクノロジーズ余地の2G-527a101ニュージャージー07733-3030米国
Phone: +1 732 949 3611 Fax: +1 732 949 3210 EMail: murali@bell-labs.com
以下に電話をしてください。 +1 732 949、3611Fax: +1 3210年の732 949メール: murali@bell-labs.com
Hui-Lan Lu Bell Laboratories Lucent Technologies Room 4K-309 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
ホイ-ランLuベル研究所ルーセントテクノロジーズ余地の4K-309 101Crawfordsコーナー道路Holmdel、ニュージャージー07733-3030米国
Phone: +1 732 949 0321 Fax: +1 732 949 1196 EMail: hui-lan.lu@bell-labs.com
以下に電話をしてください。 +1 732 949、0321Fax: +1 1196年の732 949メール: hui-lan.lu@bell-labs.com
Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY 10027 USA
ニューヨーク、コンピュータサイエンスコロンビア大学ニューヨーク10027米国のヘニングSchulzrinne部
Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344) Fax: +1 212 666 0140 EMail: schulzrinne@cs.columbia.edu
以下に電話をしてください。 +1 212 939、7042、(@Bell Labs: 732 949、8344)Fax: +1 0140年の212 666メール: schulzrinne@cs.columbia.edu
Lu, et. al. Informational [Page 58] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [58ページ]情報のRFC2458プレパイント実現1998年11月
Kamlesh T. Tewani AT&T Labs Room 1K-334 101, Crawfords Corner Rd. Holmdel, NJ 07733 USA
Kamlesh T.Tewani AT&T研究室は1K-334 101同居して、Crawfordsは通りを追い詰めます。 Holmdel、ニュージャージー07733米国
Phone: +1 732 949 5369 Fax: +1 732 949 8569 EMail: tewani@att.com
以下に電話をしてください。 +1 732 949、5369Fax: +1 8569年の732 949メール: tewani@att.com
Kumar Vishwanathan Isochrone EMail: kumar@isochrone.com
クマーウィシュワナタン同時線メール: kumar@isochrone.com
Lu, et. al. Informational [Page 59] RFC 2458 Pre-PINT Implementations November 1998
et Lu、アル。 [59ページ]情報のRFC2458プレパイント実現1998年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Lu, et. al. Informational [Page 60]
et Lu、アル。 情報[60ページ]
一覧
スポンサーリンク
