File: rfc2995.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2467 lines) | stat: -rw-r--r-- 96,427 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467






Network Working Group                                      H. Lu, Editor
Request for Comments: 2995                                   I. Faynberg
Category: Informational                                       J. Voelker
                                                             M. Weissman
                                                                W. Zhang
                                                     Lucent Technologies
                                                                 S. Rhim
                                                                J. Hwang
                                                           Korea Telecom
                                                                  S. Ago
                                                           S. Moeenuddin
                                                              S. Hadvani
                                                                     NEC
                                                           S. Nyckelgard
                                                                   Telia
                                                               J. Yoakum
                                                               L. Robart
                                                         Nortel Networks
                                                           November 2000


         Pre-SPIRITS Implementations of PSTN-initiated Services

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.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document contains information relevant to the work underway in
   The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
   Working Group.  It describes four existing implementations of
   SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC,
   and Telia in cooperation with Nortel Networks.  SPIRITS-like services
   are those originating in the Public Switched Telephone Network (PSTN)
   and necessitating the interactions of the Internet and PSTN.









Lu, et al.                   Informational                      [Page 1]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   Surveying the implementations, we can make the following
   observations:

      o  The ICW service plays the role of a benchmark service.  All
         four implementations can support ICW, with three specifically
         designed for it.

      o  Session Initiation Protocol (SIP) is used in most of the
         implementations as the base communications protocol between the
         PSTN and Internet.  (NEC's implementation is the only exception
         that uses a proprietary protocol.  Nevertheless, NEC has a plan
         to support SIP together with the extensions for SPIRITS
         services.)

      o  All implementations use IN-based solutions for the PSTN part.

   It is clear that not all pre-SPIRITS implementations inter-operate
   with each other.  It is also clear that not all SIP-based
   implementations inter-operate with each other given that they do not
   support the same version of SIP.  It is a task of the SPIRITS Working
   Group to define the inter-networking interfaces that will support
   interoperation of the future implementations of SPIRITS services.

Table of Contents

   1. Introduction ................................................  3
   2. Service Description of Internet Call Waiting ................  4
   3. Korea Telecom's ICW Implementation ..........................  5
   3.1. Overview ..................................................  5
   3.2. Network Architecture ......................................  6
   3.3. Network Entities ..........................................  7
   3.3.1. SSP .....................................................  7
   3.3.2. SCP .....................................................  7
   3.3.3. IP ......................................................  7
   3.3.4. ICW Server System .......................................  7
   3.3.5. ICW Client System .......................................  8
   3.3.6. Firewall ................................................  9
   3.4. Network Interfaces ........................................  9
   3.5. Protocols .................................................  9
   3.5.1. Intelligent Network Application Part Protocol (INAP) ....  9
   3.5.2. PINT Protocol ...........................................  9
   3.6.  Example Scenarios ........................................ 11
   3.6.1. ICW Service Subscription ................................ 11
   3.6.2. ICW Client Installation ................................. 11
   3.6.3. ICW Service Activation .................................. 12
   3.6.4. Incoming Call Notification .............................. 14
   3.6.5. Incoming Call Processing ................................ 15
   3.6.5.1. Accept the Call ....................................... 16



Lu, et al.                   Informational                      [Page 2]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   3.6.5.2. Forward the Call to Another Number .................... 18
   3.6.6. ICW service De-activation ............................... 20
   4. The Lucent Technologies Online Communications Center ........ 21
   4.1 Overview ................................................... 21
   4.2. Architecture .............................................. 22
   4.3. Protocol and Operations Considerations .................... 25
   5. NEC's Implementation ........................................ 28
   5.1. Overview .................................................. 28
   5.2. Architecture and Overall Call Flow ........................ 29
   5.3. Interfaces and Protocols .................................. 31
   5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31
   5.3.1.1. Connecting to SPIRITS Services ........................ 31
   5.3.1.2. Message Types ......................................... 31
   5.3.1.2.1 Connection Management Message Type ................... 31
   5.3.1.2.2. Data Message Type ................................... 33
   5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34
   5.3.3. Secure Reliable Hybrid Datagram Session Protocol
   (SRHDSP) for Use  .............................................. 35
   5.3.3.1. Overview .............................................. 35
   5.3.3.2. Session Initiation .................................... 35
   5.3.3.3. Secure Reliable Datagram Transport .................... 36
   5.3.3.4. Session closure ....................................... 36
   6. Telia/Nortel's Implementation ............................... 36
   6.1. Overview .................................................. 36
   6.2. Architecture and Protocols ................................ 37
   6.3. Security .................................................. 39
   7. Security Considerations ..................................... 40
   8. Conclusion .................................................. 40
   9. References .................................................. 41
   10. Authors' Addresses ......................................... 41
   11. Full Copyright Statement ................................... 44

1. Introduction

   This document contains information relevant to the work underway in
   The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
   Working Group.  It describes four existing implementations of
   SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC,
   and Telia in cooperation with Nortel Networks.  SPIRITS-like services
   are those originating in the Public Switched Telephone Network (PSTN)
   and necessitating the interactions of the Internet and PSTN.

   Invariably supported by the implementations examined in this document
   is the Internet Call Waiting (ICW) service.  With ICW, service
   subscribers, while using their telephone lines for Internet access,
   can be notified of incoming voice calls and specify how to handle the
   calls over the same telephone lines.




Lu, et al.                   Informational                      [Page 3]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   The document first gives a detailed description of the ICW service.
   Then it proceeds to discuss each of the four implementations.  The
   final sections of the document contains security considerations, the
   conclusion and references.

   It is important to note that even though the term "SPIRITS server" is
   used throughout the document, it has no universal meaning.  Its
   connotation depends on the context and varies from implementation to
   implementation.

2. Service Description of Internet Call Waiting

   Internet call waiting is the single service that is specifically
   supported by all the implementations in question.  In a nutshell, the
   service enables a subscriber engaged in an Internet dial-up session
   to

   o  be notified of an incoming call to the very same telephone line
      that is being used for the Internet connection;

   o  specify the desirable treatment of the call; and

   o  have the call handled as specified.

   The details of the ICW service lie in the ways that a waiting call
   can be treated, which vary from implementation to implementation.  In
   this section, we describe the features that are supported by at least
   one of the implementations.  They are as follows:

   o  Incoming Call Notification - The subscriber is notified of an
      incoming call over the Internet, without having any effect on the
      telephone line that is being used by the modem.  When a call comes
      in, the subscriber is presented with a pop-up dialog box on the
      PC.  The dialog box may display any combination of the calling
      party number, calling party name, and calling time.  Note that the
      display of the calling party name (or number) requires the
      availability of the caller name (or number) delivery feature.

   o  Online Incoming Call Disposition - Once informed of the incoming
      call, the subscriber has various options (indicated in the pop-up
      window) for handling the call.  Possible options are:

    + Accepting the call over the PSTN line, thus terminating the
      Internet (modem) connection

    + Accepting the call over the Internet using Voice over IP (VoIP)

    + Rejecting the call



Lu, et al.                   Informational                      [Page 4]

RFC 2995              Pre-SPIRITS Implementations          November 2000


    + Playing a pre-recorded message to the calling party and
      disconnecting the call

    + Forwarding the call to voice mail

    + Forwarding the call to another number

    + Rejecting (or Forwarding) on no Response - If the subscriber fails
      to respond within a certain period time after the dialog box has
      been displayed, the incoming call can be either rejected or
      handled based on the treatment pre-defined by the subscriber.

   o  Automatic Incoming Call Disposition - Incoming calls are
      automatically handled based on dispositions pre-defined by the
      subscriber without his or her real-time intervention.  The
      subscriber can pre-define the default disposition (e.g., re-
      directed to voice mail) for general calls as well as customized
      dispositions for calls from specific numbers.  In the latter case,
      the subscriber selects a particular disposition for each
      originating number and stores this information in a profile.  When
      a call comes in, the subscriber won't be presented the call but
      can examine the treatment and outcome of the call from the caller
      log (as described in the call logging bullet).  Naturally, this
      feature also allows the subscriber to specify the desired
      treatment for calls originating from private or unpublished
      numbers.

   o  Multiple Call Handling - Multiple calls can arrive during call
      disposition processing.  With multiple call handling, the
      subscriber is notified of the multiple calls one by one.

   o  Call Logging - A detailed log of the incoming calls processed
      during the ICW service is kept.  Typical information recorded in
      the log include the incoming call date and time, calling party
      number, calling party name, and call disposition.

3. Korea Telecom's ICW Implementation

3.1. Overview

   Korea Telecom's ICW implementation supports most of the features
   described in Section 2.  (The major exception is the feature of
   receiving the incoming call over the Internet using voice over IP.)
   In addition, the Korea Telecom implementation supports flexible
   activation and de-activation of the ICW service:






Lu, et al.                   Informational                      [Page 5]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   o  Automatic Activation/De-activation - When Internet dial-up
      connection is set up, the ICW service is activated or de-activated
      automatically.

   o  Manual Activation/De-activation - The subscriber can de-activate
      the ICW service manually when call notification is not desired
      during the Internet dial-up session and activate it when needed.

3.2. Network Architecture

   Figure 1 depicts the network architecture of the Korea Telecom ICW
   service.  The Service Switching Point (SSP), Service Control Point
   (SCP), and Intelligent Peripheral (IP) are legacy PSTN IN elements
   based on IN CS-1.  In contrast, both the ICW Server System and the
   ICW Client System are new network elements that are installed in the
   Internet domain to support of the ICW service.

     +---------------------------+      |     +--------------+
     |+--------+propr-+---------+| PINT |     |(Proxy Server)|  PINT
     ||(ICW SL)|ietary|(UAC/UAS)||--- -||-----|     ICW      |----+
     ||SCF/SDF |------|  SCGF   ||   firewall |Server System |    |
     |+--------+ i/f  +---------+|      |     +------------- +    |
     |           SCP             |      |                         |
     +------+--------------+-----+      |                         |
            |INAP          |INAP        |              firewall=====
            |              |            |                         |
        +---+---+      +---+---+                                  |
        |  IP   |      |  SSP  |                                  |
        +-------+      +---+---+                        +-------------+
                           |                   +---+    |  (UAC/UAS)  |
                       +---+---+              ||   ||   |    ICW      |
             |---------|  LEX  |--------------  + +     |Client System|
           +---+       +-------+               +++++----+-------------+
          ||   ||                             (callee)
            + +                           ICW Subscriber's Phone and PC
           +++++
         (caller)

                INAP : Intelligent Network Application Protocol
                PINT : PSTN/Internet Interworking Protocol
                SL   : Service Logic
                UAS  : User Agent Server
                UAC  : User Agent Client

     Figure 1: Network Architecture of the Korea Telecom ICW Service






Lu, et al.                   Informational                      [Page 6]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.3. Network Entities

3.3.1. SSP

   The SSP performs the Service Switching Function (SSF) and Call
   Control Function (CCF).  When detecting that the called party is busy
   (T_Busy), the SSP sends a query to the SCP and processes the call
   under the control of the SCP.

3.3.2. SCP

   The SCP performs the Service Control Function (SCF) and Service Data
   Function (SDF).  It, when queried, instructs the SSP to process the
   call based on the service logic.  In the case of the ICW service, the
   service logic ultimately governs the notification of a waiting call
   to an online ICW subscriber and the disposition of the call.  In
   addition, the SCP performs the Service Control Gateway Function
   (SCGF) for protocol inter-working between the PSTN/IN and Internet.
   It translates the SIP message from the ICW Server to the service
   control interface message and vise versa.  The SCGF is an IP end
   point and behaves as a UAS (User Agent server) or UAC (User Agent
   client).

3.3.3. IP

   The IP contains Service Resource Function (SRF).  It, when necessary,
   plays announcements to the calling party during the ICW service
   before/after receiving the response from the ICW subscriber and
   records the calling party number or voice message from the calling
   party when the call is forwarded to the Voice Mail System (VMS).

3.3.4. ICW Server System

   The ICW Server system serves as a SIP proxy or a redirect server for
   message routing between the ICW Client and SCGF.  The ICW Server is
   also responsible for managing the ICW Clients that are connected to
   it.  When an ICW Client (subscriber) sends a registration request for
   the ICW service, the ICW Server relays that request to the SCP, waits
   for the result of authorization from the SCP, and registers the
   authorized subscriber in its data base.  In addition, the ICW Server
   monitors the connection status of the registered ICW Clients.  As
   soon as a client deactivates the ICW service or terminates the
   Internet connection, the ICW Server detects the status change and
   deactivates the ICW service for the client.  Finally, the ICW Server
   manages profiles for each ICW subscribers as well as logs all the
   call processing results.





Lu, et al.                   Informational                      [Page 7]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.3.5. ICW Client System

   The ICW Client System is an application program running on the
   subscriber's PC.  Launched as soon as the subscriber powers on the
   PC, it monitors the Internet connection status of the PC (or
   subscriber).  Upon the subscriber's connection to the Internet, the
   ICW Client sends a REGISTRATION request to the SCGF via the ICW
   Server and then eventually to the SCP.  In this capacity, the ICW
   Client acts as a UAC to the SCGF, which acts as a UAS.  Thereafter it
   notifies the ICW Server periodically of the connection status of the
   subscriber.

   The ICW Client is also responsible for popping up a dialog box on the
   subscriber's PC to announce an incoming call.  The dialog box
   displays the number and name of calling party, calling time, and the
   call processing options (including Accept, Reject, Forward to another
   number or VMS).  After the subscriber selects the option, the ICW
   Client sends it to the SCP.  In this capacity, the ICW Client acts as
   a UAS.

   Depending on the pre-defined ICW Service Profile, the ICW Client may
   screen the incoming call before notifying the subscriber.

   The ICW Client manages the ICW Service Profile, which contains the
   following fields:

   o  Subscriber Information (including, Name, Directory Number,
      Password)

   o  Service Status (Activation/De-activation)

   o  Automatic Call Processing Method

    + Call Processing Method on No Answer (Reject/Forward/VMS) - The
      call is automatically handled by the method if the subscriber
      doesn't respond after a pre-defined period of time.

    + Do Not Disturb Mode (On/Off) - When this is set on, the subscriber
      won't be notified of the incoming calls.

    + Call Processing Method on Do Not Disturb (Reject/Forward/VMS)

    + Call Processing List by Calling Party Numbers
      (Accept/Reject/Forward/VMS) - Calls originated from a number on
      the list are handled by the associated call processing method.

   o  The ICW Client records the call processing method and the result
      for each incoming call in a log file on the subscriber's PC.  The



Lu, et al.                   Informational                      [Page 8]

RFC 2995              Pre-SPIRITS Implementations          November 2000


      call record in the call log contains the following information:

   - Calling Time
   - Calling Party Number
   - Calling Party Name (optional)
   - Call Processing Method (Accept/Reject/Forward/Forward to VMS)
   - Result (Success/Fail)

3.3.6. Firewall

   Packet Filtering Firewall Systems are between the ICW server and
   clients as well as between the SCGF and ICW server for accessing the
   Korea Telecom IN Nodes.

3.4. Network Interfaces

   o  The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as
      existing PSTN IN Interfaces based on the KT INAP CS-1.

   o  The SCGF-SCF interface relays requests either from the IN or the
      Internet and is implemented based on the internal API of the SCP.

   o  The SCGF-ICW Server and ICW Server-ICW Client interfaces are
      implemented based on the PINT Service Protocol V.1.  We adopted
      UAS-Proxy-UAC relationships as shown in Figure 2.

           +---------+        +-------------+        +---------+
           |(UAC/UAS)|PINT 1.0|   (Proxy)   |PINT 1.0|(UAC/UAS)|
           |         |--------|     ICW     |--------|   ICW   |
           |  SCGF   |        |    Server   |        |  Client |
           +---------+        +-------------+        +---------+

                  Figure 2: PINT Protocol Architecture

3.5. Protocols

3.5.1. Intelligent Network Application Part Protocol (INAP)

   The SCP, SSP, and IP support the KT INAP V1.0, which is based on
   ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM
   (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the
   voice message.

3.5.2. PINT Protocol

   The ICW service uses the PINT Service Protocol 1.0 [1] for
   communications between the SCP and the ICW Server System, and between
   the ICW Server System and the ICW Client System.  Developed in the



Lu, et al.                   Informational                      [Page 9]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   IETF PINT Working Group for invoking telephone services from an IP
   network, the PINT Service Protocol 1.0 specifies a set of
   enhancements to SIP 2.0 and SDP.

   Summarized below are the elements of the PINT Service Protocol 1.0
   relevant to the Korea Telecom ICW implementation:

      o REGISTER

      The REGISTER method is used to inform the SCP of the connection
      status of an ICW subscriber.  With this method, the ICW Client
      sends to the ICW Server the IP address (of the PC) and phone
      number of the subscriber when the subscriber is first connected to
      the Internet.  The ICW server relays the information to the SCP,
      which updates the data base (if the subscriber is authorized), and
      in the end sends a registration acknowledgment to the ICW Server
      and then the Client.  After the subscriber is connected to the
      Internet, the ICW Client sends a REGISTER request to the ICW
      Server periodically at a pre-defined interval (e.g., 20 seconds)
      to indicate its connection status.  The request is not relayed to
      the SCP.  The ICW Server only checks if it is from the authorized
      subscriber.  Finally, when the subscriber terminates the Internet
      connection, the Client sends the last REGISTER request to the SCP
      via the ICW Server.  If the REGISTER request does not arrive
      during the pre-defined interval, the ICW Server can also detect
      the change of the connection status of the ICW Client.

      o INVITE

      The SCP uses the INVITE method to notify the ICW Client, via the
      ICW Server, of an incoming call.

      o ACK

      Both the SCP and the ICW Server use the ACK method to confirm the
      receipt of the final responses to their requests.

      o BYE

      The BYE method terminates a service session.  In addition to this
      original usage, we use the value (success or failure) of the
      Subject header to indicate the result of the desired disposition
      of an incoming call in the PSTN.








Lu, et al.                   Informational                     [Page 10]

RFC 2995              Pre-SPIRITS Implementations          November 2000


      o CANCEL

      When the calling party releases the call before the called party
      responds, the SCP sends a CANCEL request to the ICW Client to
      cancel the INVITE request that it sent previously.

      o OPTION

      This method is not used in the KT implementation.

      o Responses

      The SCP responds to a REGISTER request with one of the status
      codes and associated comments below:

      . 100 Trying: Trying
      . 200 OK: Registered

      The ICW Client responds to an INVITE request with one of the
      status codes and associated comments below:

      . 100 Trying: Trying
      . 200 OK: Accept the Call
      . 303 see other: Forward the Call to Another Number
      . 380 alternative service: Forward the Call to the VMS
      . 603 decline: Reject the Call

3.6.  Example Scenarios

3.6.1. ICW Service Subscription

   Access to the Korea Telecom ICW service is by subscription.  Here
   Korea Telecom serves as both the PSTN operator and IN-based ICW
   service provider.  Note that the subscription data need to be loaded
   onto the relevant SSPs, including the local ones that may not be
   operated by Korea Telecom.

3.6.2. ICW Client Installation

   An ICW subscriber should install the ICW Client program in his or her
   PC.  The ICW Client is automatically activated to run as a daemon
   process when the subscriber's PC is turned on.  The Client monitors
   the Internet connection status of the subscriber.








Lu, et al.                   Informational                     [Page 11]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.6.3. ICW Service Activation

   When the subscriber initiates the Internet connection or activates
   the ICW service manually, the ICW service is activated.  That is done
   by sending a REGISTER request with the directory number and IP
   address from the ICW Client to the SCP through the ICW Server.

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                 (DN2)
     |            |            |            |            |            |
    0A            |            |            |            |            |
    0BREG(DN1,IP1)|            |            |            |            |
  1  |----------->|REG(DN1,IP1)|            |            |            |
  2  |            |----------->|            |            |            |
     |            |           2A            |            |            |
     |            |            |reg(DN1,IP1)|            |            |
  3  |            |            |-.-.-.-.-.->|            |            |
     |            |            |           3A            |            |
     |            |            |   reg ok  3B            |            |
  4  |            |            |<-.-.-.-.-.-|            |            |
     |            |   200 OK  4A            |            |            |
  5  |            |<-----------|            |            |            |
     |   200 OK  5A            |            |            |            |
  6  |<-----------|            |            |            |            |
    6A            |            |            |            |            |
     |            |            |            |            |            |

    -----> PINT Protocol          -.-.-> SCP Internal API
    --.--> INAP Protocol          +++++> ISUP Protocol
    =====> Bearer

                  Figure 3: ICW Service Activation

   As depicted in Figure 3, the relevant information flows are as
   follows:

   (0A) The ICW subscriber dials the ISP access number and establishes a
   PPP connection.

   (0B) The ICW Client detects the PPP connection.

   1. The ICW Client sends a registration request to the ICW Server in
   order to register the IP address-DN relationship for the dial-up
   connection.

   2. The ICW Server relays registration request to the SCGF.




Lu, et al.                   Informational                     [Page 12]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2A. The SCGF translates the user registration information from the
   SIP message to the SCP internal API message.

   3. The SCGF relays the user registration message to the SCF/SDF.

   3A. The SCF/SDF authorizes the subscriber with the directory number
   based on the user registration information.

   3B. The SCF/SDF stores the IP address of the ICW Client and sets the
   status to "Internet on-line."

   4. The SCF/SDF sends the result of registration to the SCF/SCGF.

   4A. The SCGF translates the user registration response of the SCP
   internal API message to the PINT message.

   5. The SCGF relays the user registration response to the ICW Server.

   5A. The ICW Server records the user registration information and the
   Internet on-line status for the subscriber in the data base.

   6. The ICW Server sends the user registration response to the ICW
   Client.

   6A. The ICW Client notifies the subscriber that the registration is
   completed successfully and the ICW service is in the active state.

























Lu, et al.                   Informational                     [Page 13]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.5.4. Incoming Call Notification

   When a calling party makes a call to the ICW subscriber, the SCP
   notifies the ICW Client of the incoming call and waits for the
   subscriber's response.

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                 (DN2)
     |            |            |            |            |            |
     |            |            |            |           setup(DN1,DN2)|
  1  |            |            |            |            |<+++++++++++|
     |            |            |            |           1A            |
     |            |            |          IDP(T-busy,DN1)|            |
  2  |            |            |            |<--.--.--.--|            |
     |            |            |           2A            |            |
     |            |            |           2B            |            |
     |            |            |           2C            |            |
     |            |        noti(DN1,IP1,DN2)|            |            |
  3  |            |            |<-.-.-.-.-.-|            |            |
     |            |           3A            |            |            |
     |         INV(DN1,IP1,DN2)|            |            |            |
  4  |            |<-----------|            |            |            |
     |           4A            |            |            |            |
     |            | 100 Trying |            |            |            |
  5  |            |----------->|            |            |            |
  INV(DN1,IP1,DN2)|            |            |            |            |
  6  |<-----------|            |            |            |            |
    6A            |            |            |            |            |
     | 100 Trying |            |            |            |            |
  7  |----------->|            |            |            |            |
     |            |            |            |            |            |

       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

                  Figure 4: Incoming Call Notification

   As depicted in Figure 4, the relevant information flows are as
   follows:

   1. The calling party at DN2 (a telephone user) makes a call to the
   ICW subscriber (PC user) at DN1.  The connection is set up using the
   existing ISDN signaling.

   1A. The SSF/CCF detects that the callee (the ICW subscriber) is busy.




Lu, et al.                   Informational                     [Page 14]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF.

   2A. The SCF/SDF determines whether the user at DN1 is PSTN on-line or
   Internet on-line.  (The SCF/SDF executes the KT Telephone Mail
   Service logic in the PSTN on-line case and the ICW service Logic in
   the Internet on-line case.)

   2B. The SCF/SDF retrieves the IP address corresponding to DN1.

   2C. The SCF/SDF may play an announcement to the calling party, while
   waiting for the response of the called party.

   3. The SCF sends an incoming call notification to the SCGF.

   3A. The SCGF translates the incoming call notification from the SCP
   internal format to the PINT format.

   4. The SCGF relays the notification to the ICW Server.

   4A. The ICW Server double-checks the subscriber's status using the
   ICW subscribers profile in its own data base.

   5. The ICW Server sends trying message to the SCGF.

   6. The ICW Server relays the notification to the ICW Client.

   6A. The ICW Client consults the ICW service profile to see if there
   is a pre-defined call disposition for the incoming call.  If so, then
   the procedure for automatic call processing is performed.

   6B. If there is no pre-defined call disposition for the incoming
   call, the subscriber is notified of the call via a pop-up dialog box.

   7. The ICW Client sends trying message to the ICW Server.

3.6.5. Incoming Call Processing

   The incoming call can be accepted, rejected, forwarded to another
   number, or forwarded to the VMS depending on the on-the-fly or pre-
   defined choice of the subscriber.  This section describes the
   information flows for the cases of "Accept the call" and "Forward the
   call to another number."









Lu, et al.                   Informational                     [Page 15]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.5.5.1. Accept the Call

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                 (DN2)
     |            |            |            |            |            |
    0A   200 OK   |            |            |            |            |
  1  |----------->|            |            |            |            |
    1A            |            |            |            |            |
    1B            |   200 OK   |            |            |            |
  2  |            |----------->|            |            |            |
     |            |    ACK    2A            |            |            |
  3  |            |<-----------|            |            |            |
     |            |            |Accept(DN1,IP1,DN2)      |            |
  4  |            |            |-.-.-.-.-.->|            |            |
     |            |            |            |Connect(DN1,DN2)         |
  5  |            |            |            |--.--.--.-->|            |
     |            |            |           Setup(DN1,DN2)|            |
  6  |<++++++++++++++++++++++++++++++++++++++++++++++++++|            |
     |<==============================6A==============================>|
     |            |            |            |    ERB     |            |
  7  |            |            |            |<--.--.--.--|            |
     |            |            |     ok     |            |            |
  8  |            |            |<-.-.-.-.-.-|            |            |
     |            |           8A            |            |            |
     |            |    BYE     |            |            |            |
  9  |            |<-----------|            |            |            |
     |           9A            |            |            |            |
     |            |            |            |            |            |



       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

           Figure 5: Incoming Call Processing - Accept the Call

   As depicted in Figure 5, the relevant information flows are as
   follows:

   0A. The ICW subscriber chooses to "Accept" the incoming call.

   1. The ICW Client sends the "Accept" indication to the ICW Server.

   1A. The ICW Client records the subscriber's selection for the
   incoming call in the call log.




Lu, et al.                   Informational                     [Page 16]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   1B. The ICW Client terminates the subscriber's Internet connection.

   2. The ICW Server sends an "Accept" message to the SCGF.

   2A. The SCGF translates the "Accept" message to an SCP internal API
   message.

   3. The SCGF sends an "ACK" message to the ICW Server.

   4. The SCGF sends the "Accept" message to the SCF.

   5. The SCF instructs the SSF/CCF to route the call to DN1.

   6. The SSF/CCF initiates the connection setup to DN1.

   6A. The bearer connection between the calling party (DN2) and the ICW
   subscriber(DN1) is set up.

   7. The connection result is returned to the SCF through ERB.

   8. The SCF sends a call completion message to the SCGF.

   8A. The SCGF translates the call completion message to a PINT
   message.

   9. The SCGF sends a "BYE" message to the ICW Server.

   9A. The ICW Server records the call completion result in the log
   file.






















Lu, et al.                   Informational                     [Page 17]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.5.5.2. Forward the Call to Another Number

ICW Subscriber ICW Server SCGF     SCF/SDF    SSF/CCF    Calling Another
ICW Client                                                party   Phone
 (DN1/IP1)     (IP2)      (IP3)                           (DN2)    (DN3)
     |          |          |          |          |          |         |
    0A          |          |          |          |          |         |
     |303 SeeOther         |          |          |          |         |
  1  |--------->|          |          |          |          |         |
    1A    ACK   |          |          |          |          |         |
  2  |<---------|303 SeeOther         |          |          |         |
  3  |          |--------->|          |          |          |         |
     |          |    ACK  3A          |          |          |         |
  4  |          |<---------|Connect(DN2,DN3)     |          |         |
  5  |          |          |-.-.-.-.->|          |          |         |
     |          |          |          |Connect(DN2,DN3)     |         |
  6  |          |          |          |.--.--.-->|          |         |
     |          |          |          |          |Setup(DN2,DN3)      |
  7  |          |          |          |          ++++++++++++++++++++>|
  8  |          |          |          |   ERB    |          |<===5A==>|
     |          |          |          |<--.--.--.|          |         |
     |          |          |    ok    |          |          |         |
  9  |          |          |<-.-.-.-.-|          |          |         |
     |          |   BYE   9A          |          |          |         |
 10  |          |<---------|          |          |          |         |
     |  BYE    10A         |          |          |          |         |
 11  |<---------|          |          |          |          |         |
    11A         |          |          |          |          |         |
     |          |          |          |          |          |         |

       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

  Figure 6: Incoming Call Processing - Forward the Call to Another

   As depicted in Figure 6, the relevant information flows are as
   follows:

   0A. The ICW subscriber chooses to "Forward to another number (DN3)"
   for the incoming call.

   1. The ICW Client sends the "Forward to another number" indication to
   the ICW Server.

   1A. The ICW Client records the subscriber's selection for the
   incoming call in the call log.




Lu, et al.                   Informational                     [Page 18]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2. The ICW Server sends an "ACK" message to the ICW Client.

   3. The ICW Server relays the "Forward to another number" message to
   the SCGF.

   3A. The SCGF translates the "Forward to another number" message to an
   SCP internal API message.

   4. The SCGF sends an "ACK" message to the ICW Server.

   5. The SCGF sends the "Forward to another number" message to the SCF.

   6. The SCF instructs the SSF/CCF to route the call to DN3.

   7. The SSF/CCF initiates the connection setup to DN3.

   7A. The bearer connection between the calling party (DN2) and the new
   termination number (DN3) is set up.

   8. The connection result is returned to the SCF through ERB.

   9. The SCF sends a call completion message to the SCGF.

   9A. The SCGF translates the call completion message to a PINT
   message.

   10. The SCGF sends the call completion message to the ICW Server.

   10A. The ICW Server records the call completion result in the log
   file.

   11. The ICW Server sends the success of "Forwarding to another
   number" to the ICW Client.

   11A. The ICW Client records the call completion result in the log
   file.















Lu, et al.                   Informational                     [Page 19]

RFC 2995              Pre-SPIRITS Implementations          November 2000


3.6.6. ICW service De-activation

   The SCP de-activates the ICW service for a subscriber either upon the
   termination of the subscriber's Internet connection or upon the
   subscriber's manual request.  In this section, we illustrate the
   former scenario.

ICW Subscriber ICW Server    SCGF        SCF/SDF     SSF/CCF    Calling
ICW Client                                                        party
 (DN1/IP1)      (IP2)        (IP3)                                (DN2)
     |            |            |            |            |            |
    0A            |            |            |            |            |
     |           0B            |            |            |            |
     |            |Unreg(DN1,IP1)           |            |            |
  1  |            |----------->|            |            |            |
     |            |           1A            |            |            |
     |            |            |Unreg(DN1,IP1)           |            |
  2  |            |            |-.-.-.-.-.->|            |            |
     |            |            |           2A            |            |
     |            |            |     ok    2B            |            |
  3  |            |            |<-.-.-.-.-.-|            |            |
     |            |           3A            |            |            |
     |            |   200 OK   |            |            |            |
  4  |            |<-----------|            |            |            |
     |           4A            |            |            |            |
     |            |            |            |            |            |


       -----> PINT Protocol             -.-.-> SCP Internal API
       --.--> INAP Protocol             +++++> ISUP Protocol
       =====> Bearer

                 Figure 7: ICW Service De-activation

   As depicted in Figure 7, the relevant information flows are as
   follows:

   0A. The ICW subscriber terminates the Internet connection.

   0B. The ICW Server determines that the Internet connection has been
   terminated when it does not receive the periodic on-line notification
   from the ICW Client.

   1. The ICW Server sends an un-register message to the SCGF.

   1A. The SCGF translates the un-register message to an SCP internal
   API message.




Lu, et al.                   Informational                     [Page 20]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2. The SCGF sends the un-register message to the SCF.

   2A. The SCF/SDF authorizes the subscriber with the directory number
   based on the un-registration information.

   2B. The SCF/SDF records the Internet off-line status for that ICW
   Client.

   3. The SCF/SDF sends a user un-registration response to the SCF/SCGF.

   3B. The SCGF translates the user un-registration response to a PINT
   message.

   4. The SCGF relays the user un-registration response to the ICW
   Server.

   4A. The ICW Server records the Internet off-line status for the ICW
   Client (subscriber) in the data base.

4. The Lucent Technologies Online Communications Center

4.1 Overview

   The Lucent Technologies Online Communications Center (OCC) is an
   Intelligent Network (IN)-based platform that supports the Internet
   call waiting service.  Its basic components are the OCC Server and
   OCC Client, which are described in detail in the Architecture
   section.  The OCC Server interacts with the PSTN entities over the
   secure intranet via plain-text Session Initiation Protocol (SIP)
   messages [2].  With the PC Client, the OCC Server interacts via
   encrypted SIP messages.

   The OCC Server run-time environment effectively consists of two
   multi-threaded processes responsible for Call Registration and Call
   Notification services, respectively.

   OCC call registration services are initiated from an end-user's PC
   (or Internet appliance).  With those, a subscriber registers his or
   her end-points and activates the notification services.  (The
   registration services are not, strictly speaking, SPIRITS services
   but rather have a flavor of PINT services.)

   All OCC call notification services are PSTN-initiated.  One common
   feature of these services is that of informing the user of the
   incoming telephone call via the Internet, without having any effect
   on the line already used by the modem.  (A typical call waiting tone
   would interrupt the Internet connection, and it is a standard
   practice to disable the  "old" PSTN call waiting service for the



Lu, et al.                   Informational                     [Page 21]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   duration of the call in support of the Internet connection between
   the end-user and the ISP.)

   When a call comes in, the user is presented with a pop-up dialog box,
   which displays the caller's number (if available), name (again, if
   available), as well as the time of the call.  If the called party
   does not initiate an action within a specified period of time the
   call is rejected.

   As far as the disposition of the call is concerned, OCC supports all
   the features described in Section 2.

4.2. Architecture

               +------------+
               | Compact    |            +-------------+
               | Service    |            | Service     |
         +-----| Node (CSN) |            | Management  |
         |     | OCC Server |            | System (SMS)|
         |     | OCC CSN SPA|            +-------------+
         |     +-------:--|-+                   |
         |             |  +-------------[ IP INTRANET ]---------+
       ===== firewall  :                                        |
         |             |                                        |
         |          +-------+                               +-------+
         |          |Central|-..-..-..-..-..-..-..-..-..-..-|Service|
         |      +-%-|Office |-..-..-:                       |Control|
         |      |   +---|---+       |                       |Point  |
         |      %       |           :                       | (SCP) |
         |      |    +--|---+   +-------+    +----------+   |OCC SCP|
         |      %    |  PC  |   | VoIP  |    | VoIP     |   |  SPA  |
         |      |    |OCC Cl|   |Gateway|    |Gatekeeper|   +-------+
         |      %    +------+   +---|---+    +-----|----+
         |      |                 ===== firewall =====
         |      %                   |              |
         |      |   +---------------|---+          |
         |      +-%-|                   |----------+
         +----------|  I N T E R N E T  |
                    |                   |
                    +-------------------+

               Figure 8: The Lucent OCC Physical Architecture

   Figure 8 depicts the joint PSTN/Internet physical architecture
   relevant to the OCC operation.  The Compact Service Node (CSN) and
   SCP are Lucent's implementations of the ITU-T IN Recommendations (in
   particular, the Recommendation Q.1205 where these entities are
   defined) augmented by the requirements of Bellcore's Advanced



Lu, et al.                   Informational                     [Page 22]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   Intelligent Network (AIN) Release 1.0) and equipped with other
   features.  The Central Office (CO) may be any switch supporting the
   Integrated Services Digital Network (ISDN) Primary Rate Interface
   (PRI) and the call forwarding feature that would allow it to
   interwork with the CSN.  Alternatively, in order to interwork with
   the SCP, it needs to be an IN Service Switching Point (SSP).  In the
   latter case, the central office is connected to the SCP via the
   signaling system No. 7 (SS7) and INAP at the application layer.

   The Service Management System (SMS) is responsible for provisioning
   of the SCPs, CSNs, and central offices.  In particular, for IN
   support of the Internet Call Waiting, it must provision the Central
   Office to direct a terminating attempt query to the subsystem number
   corresponding to the OCC SCP SPA based on the Termination Attempt
   Trigger (TAT).  In addition, the Subscriber Directory Number (DN),
   Personal Identification Number (PIN) and Language ID are provisioned
   for each subscriber into the OCC Subscriber entry of the SCP Real
   Time Data Base (RTDB).  Figure 9 shows the structure of an RTDB
   entry.

      +-------------------------------------------------------+
      |DN | PIN | IP Address | Session Key | CNF | Language ID|
      +-------------------------------------------------------+

      Field Descriptions:

      (DN) Directory Number - the subscriber's telephone number

      (PIN) Personal Identification Number - the subscriber's password

      IP Address - Internet Protocol Address of the subscriber

      (CNF) Call Notification In Progress Flag (boolean) - the flag
      indicating if an attempt to notify the subscriber of a call is
      currently in progress

      Session Key - unique identifier for the current registration session
      of the subscriber

      Language ID - language identifier for the subscriber

          Figure 9: Structure of the RTDB Subscriber Record

   The Central Office, SMS, CSN, and SCP are the only PSTN elements of
   the architecture.  The other elements are VoIP Gateway and Gatekeeper
   defined in the ITU-T Recommendation H.323, whose roles are to
   establish and provide the part of the voice path over IP.  The
   Central Office is explicitly connected to the VoIP Gateway via the



Lu, et al.                   Informational                     [Page 23]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   ISDN PRI connection.  In this architecture, CSN, VoIP Gateway, and
   VoIP Gatekeeper are the only entities connected to the Internet, with
   each respective connection protected by a firewall.  The CSN and SCP
   are interconnected via a secure IP Intranet.  There may be more than
   one CSN or SCP (or both) (and the SCPs come in mated pairs
   interconnected by X.25, anyway) in a network, but these details are
   not essential to the level of description chosen for this document.
   However, we note that load balancing and adaptation to failures by
   the use of alternative nodes is incorporated into the architecture.

   When someone attempts to call the subscriber, the central office
   serving that subscriber interrupts normal termination processing and
   notifies the SCP which, in turn, can check whether that subscriber
   has registered that he (or she) is logged onto the Internet.
   Exploiting the standardized layering of service logic that
   characterizes the intelligent network, the central office will do
   this without requiring the installation or development of any central
   office software specific to OCC.  The central office is simply
   provisioned to query the SCP when there is a termination attempt
   (i.e., TAT) directed to the subscriber's directory number.  (Note
   that the Central Office has no bearer circuit connection to the SCP,
   only a signaling one over SS7).

   TCP/IP communication between the SCP and CSN utilizes a secure
   intranet.  The subscriber, of course, is assumed to have access only
   to the Internet.

   The intelligent network entities, the SCP and CSN, do have OCC
   related software.  The OCC server is implemented on the CSN.  In
   addition, one service package application (SPA) is installed on the
   SCP.  Another SPA is located in the CSN and is needed only when the
   subscriber elects to accept an incoming call using voice over IP.

   The OCC Server is a collection of Java servers on the CSN whose
   responsibilities include:

   o  Listening for incoming Call Notification (TCP/IP) messages from
      the SCP SPA.

   o  De-multiplexing/multiplexing incoming Call Notification messages
      sent from the SCP SPA.

   o  Relaying messages between the OCC Client and the SCP SPA.

   o  Listening for and authentication of OCC Client requests for
      service registration.





Lu, et al.                   Informational                     [Page 24]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   o  Handling encryption/decryption of messages exchanged with the OCC
      Client, and generating session-specific encryption/decryption
      keys.

   The OCC Client is a collection of software components that run on the
   Subscriber's PC.  Its components include the SIP User Agent Server
   (which handles the exchange of SIP messages with the OCC Server and
   invokes the Call Notification pop-up window) and a daemon process
   that monitors the Point-to-Point Protocol (PPP) actions and is
   responsible for starting and stopping the SIP User Agent Server.

4.3. Protocol and Operations Considerations

   The OCC Server uses distinct TCP/IP ports configured on the CSN to

   o  Listen for incoming SIP REGISTER messages (in support of
      registration service) sent from the OCC Client.

   o  Listen for incoming SIP INVITE messages (in support of call
      notification service) sent from the SCP.

   During call notification, the SCP SPA is the client and thus is
   started after the OCC Server has been started.  The SCP SPA and OCC
   Server exchange SIP messages over TCP/IP (via the Secure Intranet)
   using a "nailed-up" connection which is initiated by the SCP SPA.
   This connection is initiated at the time the SCP SPA receives the
   very first SIP REGISTER request from the OCC Server, and must prevail
   for as long as the SPA is in the in-service state.  The SCP SPA also
   supports restarting the connection after any failure condition.

   The OCC Server supports multithreading.  For each Call
   Notification/Call Disposition event, a separate thread is used to
   handle the call.  This model supports multi-threading on a "per
   message" basis where every start message (SIP INVITE) received from
   the SCP SPA uses a separate thread of control to handle the call.
   Subsequent messages containing the same session Call-ID (which
   includes the SPA's instance known as "call_index" and the SCP
   hostname) as the original start message is routed to the same thread
   that previously handled the respective initiating message.

   The OCC Server dynamically opens a new TCP/IP socket with the OCC
   Client for each Call Notification/Call Disposition session.  This
   socket connection uses the IP address and a pre-configured port on
   the PC running the OCC Client software.

   For session registration, the OCC Server dynamically opens TCP/IP
   sessions with the SCP SPA.  The SCP SPA listens at a pre-configured
   port to incoming SIP REGISTER messages sent by OCC Clients via the



Lu, et al.                   Informational                     [Page 25]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   OCC Server.  To exchange SIP messages with the OCC Server, the OCC
   Client dynamically opens a TCP/IP socket connection with the OCC
   Server using a pre-configured port number on the CSN and the CSN's IP
   address.

   For the VoIP Scenario, the CSN SPA, acting as a client, dynamically
   opens TCP/IP sessions with the SCP that handled the initial TAT
   query.  As soon as the CSN SPA has successfully made the correlation
   and connected the two incoming call legs pertaining to a VoIP call
   back, the SIP 180 RINGING message will be sent back to the SCP SPA
   running on the actual SCP that instructed the SSP to forward the
   Caller to the CSN.  This SIP message, which contains the VoIP Call
   Back DN dialed by one of the bridged call legs, is an indication to
   the SCP SPA that the VoIP Call Back DN is freed up.

   A typical subscription scenario works like as follows:

   1. Each VoIP Gateway is provisioned with a list of authorized VoIP
      Call Back DNs, each terminating on a particular CSN.  These
      special DNs are used when an on-line subscriber elects to receive
      an incoming call via VoIP.  In particular, they assist in routing
      an outgoing call from the subscriber's NetMeeting to the
      particular CSN to which the SCP is (roughly concurrently)
      forwarding the incoming call.  (These two calls are joined in the
      CSN to connect the incoming call to the subscriber's Netmeeting
      client.)  Furthermore, these special DNs permits that CSN to
      associate, and hence bridge, the correct pair of call legs to join
      the party calling the subscriber to the call from the subscriber's
      NetMeeting client.

   2. The subscriber calls a PSTN service provider and signs up for the
      service.

   3. An active Terminating Attempt Trigger (TAT) is assigned to the
      subscriber's DN at the subscriber's central office.

   4. The PSTN service provider uses the SMS to create a record for the
      subscriber and provision the Subscriber DN and PIN in the OCC RTDB
      table in the SCP.

   5. The subscriber is provided with the OCC Client software, a PIN and
      a file containing the OCC Server IP Addresses.

   Finally, we describe the particular scenario of the OCC Call
   Disposition that involves voice over IP, which proceeds as follows:

   1. The OCC subscriber clicks on "Accept VoIP".




Lu, et al.                   Informational                     [Page 26]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   2.  The OCC Client sends a "SIP 380 Alternative Service" message to
       the OCC Server.  This message includes a reference to the Call
       Back DN which will ultimately be used by the CSN to associate the
       call leg (soon to be initiated by the subscriber's NetMeeting)
       connecting to the subscriber (via the VoIP gateway) with the PSTN
       call leg connecting to the calling party.

   3.  The OCC Server closes the TCP/IP session with the OCC Client and
       sends to the SCP SPA the "SIP 380 Alternative Service" message
       which includes the Call Back DN.

   4.  The SCP SPA instructs the Central Office to forward the call
       incoming to the subscriber to the CSN.  This instruction includes
       the Call Back DN.

   5.  The SSP forwards the Caller to the CSN referencing the Call Back
       DN.  Note that the Call Back DN, originally assigned to the OCC
       client by the SCP when the subscriber was alerted to the presence
       of an incoming call attempt, flowed next to the OCC server when
       the client elected to receive the call via VoIP, then to the SCP,
       then to the central office in association with a SCP command to
       forward the incoming call to the CSN, then to the OCC server on
       the CSN in association with that forwarded call.

   6.  Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from
       the SIP INVITE message received during Call Notification and 2)
       the H323UID and H323PIN values from its properties file and
       updates the 'netmtg.cnf' file.

   7.  The NetMeeting application is launched and sets up a connection
       with the VoIP Gateway.

   8.  Once a connection is established between NetMeeting and the VoIP
       Gateway, NetMeeting initiates a phone call - passing to the VoIP
       Gateway the Call Back DN as the destination DN.

   9.  The VoIP Gateway consults the VoIP Gatekeeper and authenticates
       the NetMeeting call by verifying the H323UID and H323PIN values,
       and by ensuring the called DN (i.e., Call Back DN) is authorized
       for use.

   10. After passing the authentication step, the VoIP Gateway dials
       (via PSTN) the Call Back DN and gets connected to the CSN.  The
       CSN notes that it was reached by the particular Call Back DN.

   11. The CSN bridges the Calling and Called parties together by
       matching on the basis of the Call Back DN.




Lu, et al.                   Informational                     [Page 27]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   12. The CSN notifies the SCP (SIP 180 Ringing) of status and
       references the Call Back DN so that the SCP can reuse it for
       other calls.

   13. If the central office supports that two B-channel transfer
       (Lucent, Nortel, and perhaps other central office vender's do),
       an optimization is possible.  The CSN can have the central office
       rearrange the topology of the newly connected call in such a way
       that it flows only through the central office and no longer
       through the CSN.

5. NEC's Implementation

5.1. Overview

   The NEC implementation of the ICW service is based on IN.  Via a
   SPIRITS server and an ICW client, incoming calls will be presented to
   the user via a pop-up screen dialogue box.  This dialogue box informs
   the user of the call arrival time and the calling party's number and
   name (if available).  The arrival of the call is also indicated with
   an accompanied audible indication.

   The pop-up dialogue box offers the user various call management
   options.  Selecting a call management option allows the user to
   answer the call, forward it to another destination or to  voice mail,
   or ignore it.

   The user will be able to customize their service through various
   service set-up options.  All calls presented to the user during an
   Internet session will be recorded in a call log.

   Other features include Multiple call arrival management with which
   each new call arrival will generate its own pop-up dialogue box and
   audible indication.

















Lu, et al.                   Informational                     [Page 28]

RFC 2995              Pre-SPIRITS Implementations          November 2000


5.2. Architecture and Overall Call Flow

   Figure 10 depicts the NEC ICW system.

                    ====================================
                    ||         I n t e r n e t         ||
                    ||                                 ||
                    ====================================
                     /                    |        \
                    : (p1)                :         : (p2)
                   /                      |          \
                +-------+             +------------+   +-----+
                |SPIRITS|             |    ISP     |   | W3S |
                |Server |             |    ISP     |   | W3S |
                +-------+             +------------+   +-----+
                   :                      :
   Internet        |                      :
   PSTN/IN         |(p0)                  :
                   :                      :
                   |          ============:======
                +------+ (p3) ||  +-----+ :     ||
                |  SCP |-..-..-..-| SSP | :     ||
                +------+      ||  +-----+ :     ||
                              || (p4)|    :     ||
   +-------+                  ||     :    :     ||
   | ICW   | (p1)+-----+      ||     |    :     ||
   |Client |.....| M/D |............+------+    ||
   +-------+ (p2)+-----+      ||    |  CO  |    ||
                --------------------|      |-------
               /              ||    +------+    || \
     /--\     /               ||     P S T N    ||  \        /--\
    ()/\()   /                ===================    \      ()/\()
    _/__\___/                                         \______/__\_

   ICW Subscriber                                     Calling Party

   Legend:
             ISP :  Internet Service Provider
             W3S :  WWW Server
             SCP :  Service Control Point(acts as SPIRITS Client)
             SSP :  Service Switching Point
             CO :  Central Office
             M/D :  Modem

   Traffic:
             --- : PSTN Voice Traffic
             ... : PPP(IP traffic)
             -..-: Signaling Traffic



Lu, et al.                   Informational                     [Page 29]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   Interfaces:
              p0 : SPIRITS Server-SCP(SPIRITS Client) interface
              p1 : SPIRITS Server-ICW Client interface
              p2 : ICW Client-W3S interface
                   (Web access through HTTP)
              p3 : SCP-SSP interface(INAP)
              p4 : SSP-CO interface(ISUP)

                    Figure 10: the NEC ICW system

   The description below provides the necessary steps to initiate the
   ICW service on a CO line, and how the ICW service is applied to an
   incoming call based on the above architecture:

   1.  The CO line is primed for the ICW service when the customer
      connects to their ISP by inserting a special activation code
      (e.g., *54) prefix in front of the ISP Directory Number.

   2.  The ICW service is activated when the user opens a secured
      session from an ICW client to the SPIRITS server.  Once a session
      is open, the SPIRITS server will know the relationship between the
      line and the PC (i.e., it will know the Directory Number of the
      user's Internet line and the user's IP Address).

   3.  When a call arrives at a busy Internet line, the SSP will trigger
      the ICW service.  The SCP which acts as the SPIRITS client will
      inform the SPIRITS server that a call is terminating to a busy
      Internet line.  The message will include the Caller ID and Calling
      Line Identify Restriction (CLIR) Status of the calling party, and
      DN of the busy line.

   4.  The SPIRITS server will verify that if an ICW session has been
      established for the busy line.  If so, the SPIRITS server will
      communicate with the user's ICW client application.  The user will
      receive a real-time pop-up dialogue box including the Calling Name
      and Number of the Calling Party if available.  The user will then
      select one of the following call management options:

      - Answer the call (the Internet connection will be automatically
        dropped and the phone will ring)
      - Send the call to Voice Mail
      - Forward the call to another destination
      - Ignore the call

   5.  When the Internet user has made a selection, the ICW client
      application will transmit this to the SPIRITS server.  The SPIRITS
      server will instruct the PSTN via the SCP how to handle the call.




Lu, et al.                   Informational                     [Page 30]

RFC 2995              Pre-SPIRITS Implementations          November 2000


5.3. Interfaces and Protocols

5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface

5.3.1.1. Connecting to SPIRITS Services

   The physical connection between the SCP and the SPIRITS server will
   be via a LAN/WAN.  The logical connection will use the UDP/IP
   communications as defined in RFC 768 and RFC 1122.

   If a socket connection is not currently established, the SCP will
   periodically try to open a connection.  The SCP routing tables will
   be configured so that all available connections to a SPIRITS server
   are used.

5.3.1.2. Message Types

   Two different types of message are used between the SCP and the
   SPIRITS server: "Connection Management Message Type" and the "Data
   Message Type".  These messages will carry the remote operation
   messages which are based on ITU-T Q.1228 SCF-SCF interface with some
   NEC proprietary extensions.

   NEC also has a plan to support SIP/SDP-based protocols for the SPIR-
   ITS client-server interface in the near future.

5.3.1.2.1 Connection Management Message Type

   Connection management messages are to support functions related to
   the opening and closing of connections and monitoring connections to
   ensure reliable communications are maintained between the SCP and a
   SPIRITS server.  The SCP is responsible for establishing a connection
   to a SPIRITS server.  A connection can be closed by either the SCP or
   the SPIRITS server.

   The "Connection Management Message Type" includes the following
   operations:

   - scfBind - scfUnbind - activitytest

   Opening a Connection

   If a connection is not open to an SPIRITS server, the SCP will
   periodically try to open a connection until it is opened.  If after a
   pre-determined number of attempts the connection is not opened, the
   socket connection will be released and then re-established and then
   the attempt to open the connection will be repeated.




Lu, et al.                   Informational                     [Page 31]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   The sequence for opening a connection is:

   1. SCP will transmit a scfBind invokation message to the SPIRITS
   server.  This message also carries the version information and
   activity test interval.

   2. The SPIRITS server, upon receiving an invokation of the scfBind
   from a particular SCP, will reset all the data concerning the
   connection and then responds with either a return result containing
   the Web Server Identification number or a return error with a reason.

   3. When the SCP receives a return result, if the ID number does not
   match the number configured in the SCP, then a scfUnbind will be sent
   indicating the wrong ID number.  If the SCP receives nothing or a
   return error is received, then the scfBind will be retried after a
   pre-determined period of time.

   4. Once the SCP has received a return result, the SCP will send
   Handling Information Request or Activity Test.

   Upon receiving an invokation of activityTest, the SPIRITS server
   should reply with a return result of activityTest.  If the SPIRITS
   server does not receive any invokation messages of Handling
   Information Request or Activity Test from the SCP for four times the
   Activity Test Interval value in milliseconds, the SPIRITS server
   should then close the connection.

   To close a connection an invokation of the scfUnbind is sent by
   either the SCP or SPIRITS server to the remote end.  When an
   invokation message of the scfUnbind is received, the receiving end
   should terminate the connection.

   scfBind

   The scfBind operation is used to open the connection between the SCP
   and the SPIRITS server.  The SCP will send the SPIRITS server an
   invokation of the scfBind to establish an association.  If the
   SPIRITS server is ready to handle the request then it should respond
   with a return result.

   The return result of scfBind contains the identifier of the SPIRITS
   server.  If the SCP receives the return result where the
   identification of the SPIRITS server does not match that registered
   against the SPIRITS server, then the SCP will send an invokation of
   the scfUnbind indicating an incorrect identifier was received.

   If the SPIRITS server is not ready to handle the request or cannot
   handle the version, then it should respond with a return error.



Lu, et al.                   Informational                     [Page 32]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   scfUnbind

   The scfUnbind operation is used to close the connection between the
   SCP and the SPIRITS server.  Either the SCP or the SPIRITS server can
   invoke this operation.

   Upon receiving an invokation message the receiving end should
   terminate the connection.

   activityTest

   If the SCP has not sent a Data Message for the time period specified
   by the "Activity Test Interval", it will send an invokation message
   of activityTest.  When the SPIRITS server receives such an
   invokation, it will reply with a return result message of
   activityTest.

   Its contents should be retained by the SPIRITS server.  They are to
   be echoed back in the return result so that the message reply time
   can be calculated.

5.3.1.2.2. Data Message Type

   SCPs use the following operations, which are sent to the SPIRITS
   server via a Data-Message-Type message, to request execution of some
   service procedure or notification of an event that takes place at the
   SCPs:

   o handlingInformationRequest

     The handlingInformationRequest message will request a SPIRITS
     server the execution of some service procedure.

   o handlingInformationResult

     The handlingInformationResult message will show the SCP the result
     of the execution, which was carried out by the SPIRITS server.

   o confirmedNotificationProvided

     The confirmedNotificationProvided message will indicate to the
     SPIRITS server of an event, which takes place at the SCP.  If the
     confirmedNotificationProvided indicating 'caller abandon' is
     received, the SPIRITS server will inform the client of the caller
     abandon and send the SCP a return result for the
     confirmedNotificationProvided.





Lu, et al.                   Informational                     [Page 33]

RFC 2995              Pre-SPIRITS Implementations          November 2000


     The invoked operation has always a response which is either a
     return result of the operation or an invokation of another
     operation.

     If a Data Message is not replied to within a pre-determined time
     out period then the message will be resent a number of specified
     times.  Once the number of times has been exceeded, if another node
     exists, the message will be sent to another node if it is
     available.  If all available SPIRITS servers have been queried then
     Message Time out will be returned to the calling process.

     If an invokation of the handlingInformationResult is received with
     the cause=63 (Service not available), the
     handlingInformationRequest will be sent to another node if it is
     available.  If all available SPIRITS severs have been queried then
     cause=63 will be returned to the calling process.

5.3.2. SPIRITS Server-ICW Client Application Interface

   The following is a list of the application messages that are sent via
   the secure protocol (refer to section 5.3.3):

   o VersionInfo (ICW client -> SPIRITS server)

     Indicate the current version of ICW client software.  The SPIRITS
     server uses this information to determine if the client software is
     out of date.

   o VersionInfoAck (SPIRITS server -> ICW client)

     If the VersionInfo message from an ICW client indicates to a
     SPIRITS server that it is an out of date version, the URL
     information is returned within the VersionInfoAck message for use
     in downloading the newer version.  If the client software is up to
     date, the message simply indicates so and does not include any URL
     information.

   o CallArrival (SPIRITS server -> ICW client)

     Sent by the server to tell the client someone has called the DN.

   o CallID

     An identifier for this call.  Unique in the domain of this
     client/server session.






Lu, et al.                   Informational                     [Page 34]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   o CallingNumber

   o CallingName

     The name of the calling party is sent to the Client Application
     from the SPIRITS server.  When available, the name is sent as a
     15-character string.  If the name is unavailable it is sent as
     "Name Unavailable".  If the calling party has CLIR set, it is sent
     as empty (" ").

   o CallConnect (ICW client -> SPIRITS server)

     If a corresponding CallConnect is not received within a certain
     period after sending a CallArrival, the SPIRITS server will behave
     as though a CallConnect, Handling=Ignore had been received.

   o CallLost (SPIRITS server -> ICW client)

     Sent by server to cancel a CallArrival before a CallConnect is
     received by the server.

5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use
       Between ICW Client Application and SPIRITS Server

5.3.3.1. Overview

   In principle the solution involves session initiation over SSL
   (meeting requirements for standards based security) after which the
   SSL session is closed, thereby reducing the number of simultaneous
   TCP/IP sessions.  The rest of the session is communicated over
   UDP/IP, secured using keys and other parameters exchanged securely
   during the SSL session.

5.3.3.2. Session Initiation

   The ICW client initiates an SRHDSP session, by reserving a UDP/IP
   port, and opening an SSL session with the service (e.g., ICW) on the
   service's well known SSL/TCP port.  After establishing the SSL
   Session, the ICW client sends the server its IP address, the reserved
   UDP port number, and the set of supported symmetric key algorithms.

   The server responds with a symmetric key algorithm chosen from the
   set, the server's UDP port for further communication, heartbeat
   period, and the value to use for the sequencing window.







Lu, et al.                   Informational                     [Page 35]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   The client then generates a symmetric key using the selected
   algorithm and transmits this to the server.  The SSL session is then
   closed and the SRHDSP session is considered open.

5.3.3.3. Secure Reliable Datagram Transport

   Application, and subsequent session management messages use symmetric
   signaling.  That is, the signaling is the same whether the client is
   sending a message or the server is sending a message.

   The message packets are transmitted securely.  The protocol corrects
   for lost, duplicated and out of sequence packets.

5.3.3.4. Session closure

   The client or server may close the session.

   A session is closed using a Close message including the next sequence
   number, and encrypted with the agreed key.

   The receiver, on processing (as opposed to receiving) a Close
   message, should set a timer, when the timer expires all details of
   the session should be forgotten.  The timer is to allow for
   retransmission of the close if the Ack gets lost, we still need to be
   able to decrypt the subsequent retransmission and re-acknowledgment.

   If any message other than a close is received after a close is
   processed, it is ignored.

6. Telia/Nortel's Implementation

6.1. Overview

   The system implemented by Telia in cooperation with Nortel Networks
   is designed to support services that execute before the end-to-end
   media sessions are established.  These services include, for example:

   - call transfer and number portability for redirecting calls
   - call waiting and call offering for announcing a pending call
   - call screening and don't disturb for filtering incoming calls
   - automatic call distribution and 800-services for selecting
     termination point

   The Telia/Nortel system aims to allow service providers to develop
   the services mentioned above.  Presently, prototypes for online
   incoming call disposition and automatic incoming call disposition
   (described in Section 2) have been developed to prove the concept.




Lu, et al.                   Informational                     [Page 36]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   In the Telia/Nortel architecture, services run on top of SIP Redirect
   Servers.  The distributed nature of SIP enables these servers to be
   hosted, for example, by an enterprise server, a Service Provider's
   server cluster, a user's desktop PC, or even by a hand-held cordless
   device.

   The SIP Redirect Server receives a SIP INVITE message for each call
   regardless of which network the call is being set up in.  The server
   MAY apply any kind of service logic in order to decide on how to
   respond to the invitation.  Service logic may interact with the user
   to allow the user to specify how to handle a call such as described
   in Section 2.  This, however, is not the focus of the Telia/Nortel
   system.

6.2. Architecture and Protocols

   The general idea behind the architecture is to create services as if
   all communication was based on IP and all clients and servers were
   SIP enabled.  This of cause is not true in existing
   telecommunications networks.  Hence, a new type of network element,
   the Service Control Gateways (SCG) hides the true situation from the
   services.

   SCGs convert network-specific call control signaling to SIP messages
   and vice versa.  A SCG behaves as a regular SIP User Agent (UA)
   towards the services and as a network-specific service control node
   in the network where the call is being set up.  For example, when
   connecting to a GSM network, the SCG can play the role of an SCP or a
   MAP or an ISUP proxy.  The specific role depends on what service
   triggers are being used in the GSM network.

   SCGs handle protocol conversions but not address translation, such as
   telephone number to SIP URL, which is handled by a regular SIP Server
   to keep the SCG as simple as possible.

   Consider a service example of number portability.  A conventional
   number portability implementation in a mobile Circuit Switched
   Network (CSN) uses INAP messages to carry number queries to a
   network-internal data base application.  Here, a SCG and a high-
   performance SIP Redirect Server, referred to as the Number Server
   (NS), have replaced the data base typically located in an SCP.  (See
   Figure 11.)









Lu, et al.                   Informational                     [Page 37]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   +-----------+  INAP  +-----+  SIP  +--------------------------+
   |  CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
   +-----------+        +-----+       +--------------------------+

             Figure 11: An Architecture for Number Portability

   The INAP IDP message that carries the number query is converted to a
   SIP INVITE message by the SCG and is then forwarded to the NS (SIP
   Redirect Server).

   If the called number is not registered, then the NS will return "404
   Not Found".  The SCG interprets this as "non ported number" and
   returns a CON message to the CSN network, making it connect the call
   to the called number.

   If the number is ported and hence registered, then the NS will return
   "301 Moved Permanently" with a TEL URL (routing number) in the
   contact field.  The SCG then returns a CON message to the CSN
   network, making it connect the call to the number that was conveyed
   in the contact field.

   The solution above enables the same Number Server to provide Number
   Portability to multiple networks by means of using multiple SCGs.

   If we make the SIP server in the number portability example operate
   in proxy mode for selected numbers, then it will become a kind of
   service router, able to relay number queries to any SIP-Redirect-
   Server-based service anywhere, provided there is an IP connection to
   the host in concern. Figure 12 shows the arrangement.

   +------+ INAP +-----+ SIP +----------------+ SIP +----------+
   |  CSN |------| SCG |-----|       NS       |-----| Service  |
   | node |      |     |     |(redirect/proxy)|     |(redirect)|
   +------+      +-----+     +----------------+     +----------+

             Figure 12: SIP-Based Service Router

   Suppose that we connect a value-added service, such as a Personal
   Call Filtering service hosted by a user's desktop PC, to a certain
   telephone number.  The INAP IDP message is converted to a SIP INVITE
   message by the SCG and is then forwarded to the NS, just as in the
   previous example.  However, in this case, the number is registered
   with a reference to a SIP URL.  This makes the Number Server proxy
   the SIP INVITE message to the registered URL, which is the address of
   the service.






Lu, et al.                   Informational                     [Page 38]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   The service responds as a SIP Redirect Server and the Personal Call
   Filtering service logic determines the response.  The NS sends the
   response back to the SCG which converts the response to an
   appropriate INAP message.  The response from the service is typically
   "302 Moved Temporarily" with a telephone number in the Contact field.

   If the response is 301 or 302, as the examples above suggest, then a
   telephone number is carried in the contact field.  If the user can be
   reached via several different addresses, then all of them SHOULD be
   added to the response by means of multiple contact fields.  The SCG
   then selects an address that is valid for the node or application
   that issued the number query.

   As illustrated by the service examples, the Telia/Nortel system aims
   to allow the introduction of multi-network services without requiring
   multi-protocol support.  The services hence operate in the same way
   regardless of in which network the call is made and common IP
   services can be shared across heterogeneous networks.

   +-----------+   +-------+ SIP +----+    ......  SIP +-----------+
   | Network 1 |---| SCG 1 |-----|    |---:      :-----| Service A |
   +-----------+   +-------+     |    |   :      :     +-----------+
                                 |    |   :      :
   +-----------+   +-------+ SIP |    |   :      : SIP +-----------+
   | Network 2 |---| SCG 2 |-----| NS |---:      :-----| Service B |
   +-----------+   +-------+     |    |   : Any  :     +-----------+
                                 |    |   :  IP  :
   +-----------+   +-------+ SIP |    |   : net- : SIP +-----------+
   | Network n |---| SCG n |-----|    |---: work :-----| Service C |
   +-----------+   +-------+     +----+   :      :     +-----------+
                                          :      :
   +--------+                SIP          :      : SIP +-----------+
   | SIP UA |-----------------------------:      :-----| Service x |
   +--------+                             '......'     +-----------+

   Figure 13: Interconnecting Heterogeneous Networks via SIP

6.3. Security

   The Telia/Nortel architecture uses security mechanisms available to
   ordinary SIP services, implemented as they would be in a pure SIP
   network.  The architecture described here does not impose any
   additional security considerations.

   General security issues that must be considered include
   interconnection of two different networks.  SCGs must therefore
   include mechanisms that prevent destructive service control signaling
   from one network to the other.  For example, a firewall-type



Lu, et al.                   Informational                     [Page 39]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   mechanism that can block a denial-of- service attack from an Internet
   user toward the PSTN.

7. Security Considerations

   Overall, the SPIRITS security requirements are essentially the same
   as those for PINT [3, 4], which include, for example:

      + Protection of the PSTN from attacks from the Internet.

      + Peer entity authentication to allow a communicating entity to
      prove its identity to another in the network.

      + Authorization and access control to verify if a network entity
      is allowed to use a network resource.

      + Confidentiality to avoid disclosure of information (e.g., the
      end user profile information and data) without the permission of
      its owner.

      + Non-repudiation to account for all operations in case of doubt
      or dispute.

   As seen in the previous sections, most implementations examined in
   this document have employed means (e.g., firewalls and encryption) to
   meet these requirements.  The means are, however, different from
   implementation to implementation.

8. Conclusion

   This document has provided information relevant to the development of
   inter-networking interfaces between the PSTN and Internet for
   supporting SPIRITS services.  Specifically, it described four
   existing implementations of SPIRITS-like services.  Surveying these
   implementations, we can make the following observations:

   o  The ICW service plays the role of a benchmark service.  All four
      implementations can support ICW, with three specifically designed
      for it.

   o  SIP is used in most of the implementations as the based
      communications protocol between the PSTN and Internet.  (NEC's
      implementation is the only exception that uses a proprietary
      protocol.  Nevertheless, NEC has a plan to support SIP together
      with the extensions for SPIRITS services.)

   o  All implementations use IN-based solutions for the PSTN part.




Lu, et al.                   Informational                     [Page 40]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   It is clear that not all pre-SPIRITS implementations inter-operate
   with each other.  It is also clear that not all SIP-based
   implementations inter-operate with each other given that they do not
   support the same version of SIP.  It is a task of the SPIRITS Working
   Group to define the inter-networking interfaces that will support
   inter-operation of the future implementations of SPIRITS services.

9. References

   [1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
       to SIP and SDP for IP Access to Telephone Call Services", RFC
       2848, June 2000.

   [2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
       "SIP:  Session Initiation Protocol", RFC 2543, March 1999.

   [3] Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg,
       F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and
       K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking--
       Pre-PINT Implementations", RFC 2458, November 1998.

10. Authors' Addresses

   Igor Faynberg
   Lucent Technologies
   Room 4L-334
   101 Crawfords Corner Road
   Holmdel, NJ,  USA 07733-3030

   Phone: +1 732 949 0137
   EMail: faynberg@lucent.com

   Hui-Lan Lu
   Lucent Technologies
   Room 4L-317
   101 Crawfords Corner Road
   Holmdel, NJ,  USA 07733-3030

   Phone: +1 732 949 0321
   EMail: huilanlu@lucent.com











Lu, et al.                   Informational                     [Page 41]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   John Voelker
   Lucent Technologies
   Room 1A-417
   263 Shuman Blvd PO Box 3050
   Naperville, IL,  USA 60566-7050

   Phone: +1 630 713 5538
   EMail: jvoelker@lucent.com

   Mark Weissman
   Lucent Technologies
   Room NE406B
   200 Lucent Lane
   Cary, NC, USA 27511-6035

   Phone: +1 919 463 3258
   EMail: maw1@lucent.com

   Weizhong Zhang
   Lucent Technologies
   Room 01-A5-17
   2000 Regency Parkway
   Cary, NC,  USA 27511-8506

   Phone: +1 919 380-6638
   EMail: wzz@lucent.com

   Sung-Yurn Rhim
   Korea Telecom
   17 Woomyun-dong
   Seocho-gu, Seoul, Korea

   Phone: +82 2 526 6172
   EMail: syrhim@kt.co.kr

   Jinkyung Hwang
   Korea Telecom
   17 Woomyun-dong
   Seocho-gu, Seoul, Korea

   Phone: +82 2 526 6830
   EMail: jkhwang@kt.co.kr









Lu, et al.                   Informational                     [Page 42]

RFC 2995              Pre-SPIRITS Implementations          November 2000


   Shinji. Ago
   NEC Corporation
   1131, Hinode, Abiko,
   Chiba, 270-1198, Japan

   Phone: +81 471 85 7412
   EMail: ago@ssf.abk.nec.co.jp

   S. Moeenuddin
   NEC America, Inc
   1525 Walnut Hill Lane,
   Irving, TX,  USA 75038

   Phone: +1 972 518 5102
   EMail: moeen@asl.dl.nec.com

   S. Hadvani
   NEC America, Inc
   1525 Walnut Hill Lane,
   Irving, TX,  USA 75038

   Phone: +1 972 518 3628
   EMail: hadvani@asl.dl.nec.com

   Soren Nyckelgard
   Telia Research
   Chalmers Teknikpark
   41288 Gothenburg
   Sweden

   EMail: soren.m.nyckelgard@telia.se

   John Yoakum
   Nortel Networks
   507 Airport Blvd, Suite 115,
   Morrisville, NC, USA  27560

   EMail: yoakum@nortelnetworks.com

   Lewis Robart
   Nortel Networks
   P.O. Box 402
   Ogdensburg, NY, USA  13669

   EMail: robart@nortelnetworks.com






Lu, et al.                   Informational                     [Page 43]

RFC 2995              Pre-SPIRITS Implementations          November 2000


11. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Lu, et al.                   Informational                     [Page 44]