KR20010006455A - 교환 전화 통신용 시스템, 방법 및 그 제조물 - Google Patents
교환 전화 통신용 시스템, 방법 및 그 제조물 Download PDFInfo
- Publication number
- KR20010006455A KR20010006455A KR1019997009545A KR19997009545A KR20010006455A KR 20010006455 A KR20010006455 A KR 20010006455A KR 1019997009545 A KR1019997009545 A KR 1019997009545A KR 19997009545 A KR19997009545 A KR 19997009545A KR 20010006455 A KR20010006455 A KR 20010006455A
- Authority
- KR
- South Korea
- Prior art keywords
- network
- call
- service
- data
- management
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims abstract description 184
- 238000000034 method Methods 0.000 title claims description 440
- 238000004519 manufacturing process Methods 0.000 title description 20
- 238000012360 testing method Methods 0.000 claims abstract description 82
- 238000004458 analytical method Methods 0.000 claims abstract description 25
- 230000005540 biological transmission Effects 0.000 claims description 103
- 238000012546 transfer Methods 0.000 claims description 62
- 238000012544 monitoring process Methods 0.000 claims description 47
- 238000001514 detection method Methods 0.000 claims description 35
- 230000000977 initiatory effect Effects 0.000 claims description 25
- 238000004590 computer program Methods 0.000 claims description 13
- 230000009977 dual effect Effects 0.000 claims description 7
- 238000012545 processing Methods 0.000 abstract description 101
- 238000007726 management method Methods 0.000 description 264
- 230000008569 process Effects 0.000 description 214
- 230000006870 function Effects 0.000 description 202
- 230000004044 response Effects 0.000 description 154
- 230000008859 change Effects 0.000 description 89
- 238000010586 diagram Methods 0.000 description 78
- 239000003795 chemical substances by application Substances 0.000 description 73
- 238000012384 transportation and delivery Methods 0.000 description 69
- 230000000903 blocking effect Effects 0.000 description 65
- 108091006146 Channels Proteins 0.000 description 63
- 238000003860 storage Methods 0.000 description 57
- 239000002585 base Substances 0.000 description 53
- 239000011800 void material Substances 0.000 description 52
- 230000011664 signaling Effects 0.000 description 46
- 238000004578 scanning tunneling potentiometry Methods 0.000 description 45
- 238000012216 screening Methods 0.000 description 45
- 235000019832 sodium triphosphate Nutrition 0.000 description 45
- 238000013523 data management Methods 0.000 description 44
- 230000003993 interaction Effects 0.000 description 40
- 238000005516 engineering process Methods 0.000 description 38
- 238000012423 maintenance Methods 0.000 description 35
- 238000009826 distribution Methods 0.000 description 34
- 238000004422 calculation algorithm Methods 0.000 description 33
- 238000012790 confirmation Methods 0.000 description 31
- 238000013519 translation Methods 0.000 description 31
- 230000014616 translation Effects 0.000 description 31
- 230000032258 transport Effects 0.000 description 30
- 230000007246 mechanism Effects 0.000 description 27
- 238000012795 verification Methods 0.000 description 27
- 230000000007 visual effect Effects 0.000 description 27
- 238000006243 chemical reaction Methods 0.000 description 26
- 230000009471 action Effects 0.000 description 24
- 238000013459 approach Methods 0.000 description 23
- 230000000694 effects Effects 0.000 description 22
- 230000010354 integration Effects 0.000 description 22
- 230000007704 transition Effects 0.000 description 21
- 230000006835 compression Effects 0.000 description 19
- 238000007906 compression Methods 0.000 description 19
- 239000000047 product Substances 0.000 description 19
- 230000003068 static effect Effects 0.000 description 17
- 238000013461 design Methods 0.000 description 15
- 238000013515 script Methods 0.000 description 15
- 238000013468 resource allocation Methods 0.000 description 14
- 238000009825 accumulation Methods 0.000 description 13
- 230000008901 benefit Effects 0.000 description 13
- 238000003825 pressing Methods 0.000 description 13
- 230000001934 delay Effects 0.000 description 12
- 238000009434 installation Methods 0.000 description 12
- 230000008520 organization Effects 0.000 description 12
- 230000002452 interceptive effect Effects 0.000 description 11
- 238000005259 measurement Methods 0.000 description 11
- 230000008093 supporting effect Effects 0.000 description 11
- 239000000969 carrier Substances 0.000 description 10
- 230000002093 peripheral effect Effects 0.000 description 10
- 238000010200 validation analysis Methods 0.000 description 10
- 239000000919 ceramic Substances 0.000 description 9
- 238000011161 development Methods 0.000 description 9
- 230000018109 developmental process Effects 0.000 description 9
- 239000000835 fiber Substances 0.000 description 9
- 238000013507 mapping Methods 0.000 description 9
- 101150029755 park gene Proteins 0.000 description 9
- 238000002360 preparation method Methods 0.000 description 9
- 239000000243 solution Substances 0.000 description 9
- KQPKMEYBZUPZGK-UHFFFAOYSA-N 4-[(4-azido-2-nitroanilino)methyl]-5-(hydroxymethyl)-2-methylpyridin-3-ol Chemical compound CC1=NC=C(CO)C(CNC=2C(=CC(=CC=2)N=[N+]=[N-])[N+]([O-])=O)=C1O KQPKMEYBZUPZGK-UHFFFAOYSA-N 0.000 description 8
- 101001111984 Homo sapiens N-acylneuraminate-9-phosphatase Proteins 0.000 description 8
- 102100023906 N-acylneuraminate-9-phosphatase Human genes 0.000 description 8
- 230000006399 behavior Effects 0.000 description 8
- 210000003879 microtubule-organizing center Anatomy 0.000 description 8
- 230000036961 partial effect Effects 0.000 description 8
- 230000004913 activation Effects 0.000 description 7
- 238000001994 activation Methods 0.000 description 7
- 238000013500 data storage Methods 0.000 description 7
- 238000012217 deletion Methods 0.000 description 7
- 230000037430 deletion Effects 0.000 description 7
- 239000011159 matrix material Substances 0.000 description 7
- 102100023245 Asparagine-tRNA ligase, cytoplasmic Human genes 0.000 description 6
- 101000624939 Homo sapiens Asparagine-tRNA ligase, cytoplasmic Proteins 0.000 description 6
- RDYMFSUJUZBWLH-UHFFFAOYSA-N endosulfan Chemical compound C12COS(=O)OCC2C2(Cl)C(Cl)=C(Cl)C1(Cl)C2(Cl)Cl RDYMFSUJUZBWLH-UHFFFAOYSA-N 0.000 description 6
- 238000013439 planning Methods 0.000 description 6
- 238000012549 training Methods 0.000 description 6
- XIYOPDCBBDCGOE-IWVLMIASSA-N (4s,4ar,5s,5ar,12ar)-4-(dimethylamino)-1,5,10,11,12a-pentahydroxy-6-methylidene-3,12-dioxo-4,4a,5,5a-tetrahydrotetracene-2-carboxamide Chemical compound C=C1C2=CC=CC(O)=C2C(O)=C2[C@@H]1[C@H](O)[C@H]1[C@H](N(C)C)C(=O)C(C(N)=O)=C(O)[C@@]1(O)C2=O XIYOPDCBBDCGOE-IWVLMIASSA-N 0.000 description 5
- 238000013475 authorization Methods 0.000 description 5
- 210000004027 cell Anatomy 0.000 description 5
- 230000001976 improved effect Effects 0.000 description 5
- 238000002955 isolation Methods 0.000 description 5
- 238000012913 prioritisation Methods 0.000 description 5
- 230000002829 reductive effect Effects 0.000 description 5
- 230000010076 replication Effects 0.000 description 5
- 238000012552 review Methods 0.000 description 5
- 238000000638 solvent extraction Methods 0.000 description 5
- 238000013024 troubleshooting Methods 0.000 description 5
- 235000008694 Humulus lupulus Nutrition 0.000 description 4
- 241000699666 Mus <mouse, genus> Species 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 4
- 238000012508 change request Methods 0.000 description 4
- 238000010276 construction Methods 0.000 description 4
- 230000001276 controlling effect Effects 0.000 description 4
- 235000014510 cooky Nutrition 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 230000008676 import Effects 0.000 description 4
- 230000014759 maintenance of location Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- ORILYTVJVMAKLC-UHFFFAOYSA-N Adamantane Natural products C1C(C2)CC3CC1CC2C3 ORILYTVJVMAKLC-UHFFFAOYSA-N 0.000 description 3
- 241001522296 Erithacus rubecula Species 0.000 description 3
- 238000013474 audit trail Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000009349 indirect transmission Effects 0.000 description 3
- 238000007689 inspection Methods 0.000 description 3
- 238000011068 loading method Methods 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 239000013307 optical fiber Substances 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 239000013589 supplement Substances 0.000 description 3
- 230000009466 transformation Effects 0.000 description 3
- 208000025760 Benign familial haematuria Diseases 0.000 description 2
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 2
- 101001094649 Homo sapiens Popeye domain-containing protein 3 Proteins 0.000 description 2
- 101000608234 Homo sapiens Pyrin domain-containing protein 5 Proteins 0.000 description 2
- 101000578693 Homo sapiens Target of rapamycin complex subunit LST8 Proteins 0.000 description 2
- 102100027802 Target of rapamycin complex subunit LST8 Human genes 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000032683 aging Effects 0.000 description 2
- 238000012550 audit Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 244000309464 bull Species 0.000 description 2
- 238000005266 casting Methods 0.000 description 2
- 229910052802 copper Inorganic materials 0.000 description 2
- 239000010949 copper Substances 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 230000007123 defense Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000009365 direct transmission Effects 0.000 description 2
- 239000006185 dispersion Substances 0.000 description 2
- MAUQAXOHCVNUMX-BUHFOSPRSA-N ethyl (e)-7-[2-cyclopropyl-4-(4-fluorophenyl)quinolin-3-yl]-3,5-dihydroxyhept-6-enoate Chemical compound CCOC(=O)CC(O)CC(O)\C=C\C1=C(C2CC2)N=C2C=CC=CC2=C1C1=CC=C(F)C=C1 MAUQAXOHCVNUMX-BUHFOSPRSA-N 0.000 description 2
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 2
- 238000002474 experimental method Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000011049 filling Methods 0.000 description 2
- ZXQYGBMAQZUVMI-GCMPRSNUSA-N gamma-cyhalothrin Chemical compound CC1(C)[C@@H](\C=C(/Cl)C(F)(F)F)[C@H]1C(=O)O[C@H](C#N)C1=CC=CC(OC=2C=CC=CC=2)=C1 ZXQYGBMAQZUVMI-GCMPRSNUSA-N 0.000 description 2
- 230000012010 growth Effects 0.000 description 2
- 238000003384 imaging method Methods 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 230000033001 locomotion Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 239000010813 municipal solid waste Substances 0.000 description 2
- 230000008447 perception Effects 0.000 description 2
- 239000000843 powder Substances 0.000 description 2
- 239000010970 precious metal Substances 0.000 description 2
- 230000001737 promoting effect Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000003362 replicative effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 230000007781 signaling event Effects 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 238000010561 standard procedure Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000011282 treatment Methods 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 101100293603 Caenorhabditis elegans nas-7 gene Proteins 0.000 description 1
- 101100065885 Caenorhabditis elegans sec-15 gene Proteins 0.000 description 1
- 241000282412 Homo Species 0.000 description 1
- 108700010388 MIBs Proteins 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 102100022670 Nuclear receptor subfamily 6 group A member 1 Human genes 0.000 description 1
- 101710093927 Nuclear receptor subfamily 6 group A member 1 Proteins 0.000 description 1
- RJKFOVLPORLFTN-LEKSSAKUSA-N Progesterone Chemical compound C1CC2=CC(=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H](C(=O)C)[C@@]1(C)CC2 RJKFOVLPORLFTN-LEKSSAKUSA-N 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 239000003637 basic solution Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 238000005034 decoration Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- FAXIJTUDSBIMHY-UHFFFAOYSA-N diethoxy-(2-ethylsulfanylethoxy)-sulfanylidene-$l^{5}-phosphane;1-diethoxyphosphorylsulfanyl-2-ethylsulfanylethane Chemical compound CCOP(=O)(OCC)SCCSCC.CCOP(=S)(OCC)OCCSCC FAXIJTUDSBIMHY-UHFFFAOYSA-N 0.000 description 1
- 230000003292 diminished effect Effects 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000004941 influx Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000000314 lubricant Substances 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 229910052751 metal Inorganic materials 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 239000012782 phase change material Substances 0.000 description 1
- 238000002135 phase contrast microscopy Methods 0.000 description 1
- 238000002367 polarised neutron reflectometry Methods 0.000 description 1
- 229920000636 poly(norbornene) polymer Polymers 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012419 revalidation Methods 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000004936 stimulating effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 239000000454 talc Substances 0.000 description 1
- 229910052623 talc Inorganic materials 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2254—Arrangements for supervision, monitoring or testing in networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/26—Arrangements for supervision, monitoring or testing with means for applying test signals or for measuring
- H04M3/28—Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor
- H04M3/30—Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for subscriber's lines, for the local loop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0024—Services and arrangements where telephone services are combined with data services
- H04M7/0036—Services and arrangements where telephone services are combined with data services where the data service is an information service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0024—Services and arrangements where telephone services are combined with data services
- H04M7/0054—Services and arrangements where telephone services are combined with data services where the data service is an electronic mail service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/1225—Details of core network interconnection arrangements
- H04M7/1235—Details of core network interconnection arrangements where one of the core networks is a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/125—Details of gateway equipment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/126—Interworking of session control protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/128—Details of addressing, directories or routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/1295—Details of dual tone multiple frequency signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/32—Involving wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/4228—Systems providing special services or facilities to subscribers in networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/48—Arrangements for recalling a calling subscriber when the wanted subscriber ceases to be busy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/72—Finding out and indicating number of calling subscriber
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Monitoring And Testing Of Exchanges (AREA)
Abstract
하이브리드 통신 시스템은 다중 라우팅 및 다중차원의 콜백 처리를 제공하기위해, 인터넷을 통해 정보를 전송하는 교환 네트워크를 포함한다. 이 하이브리드 네트워크는 하나 이상의 패킷 전송 네트워크에 연결된 하나 이상의 교환 통신 네트워크을 포함하며, 상기 패킷전송 네트워크는 정보를 적절한 교환 전화 장치 또는 인터넷 장치에 라우팅한다. 디스플레이가 부착된 컴퓨터가 패킷 전송 네트워크와 통신한다. 컴퓨터는 하이브리드 네트워크의 테스트를 비롯한 하이브리드 네트워크의 원격 관리를 동작시키는데 이용된다. 이 테스트는 루프 스타트, 그라운드 스타트가 될 수 있는 신호 상태를 선택하거나 또는 듀얼톤 다중 주파수, 다중 주파수 또는 듀얼톤과 같은 신호를 검출하는 회로 분석을 포함한다. 본 하이브리드 네트워크는 오퍼레이터가 하이브리드 네트워크의 관리를 감지할 수 있게 하는 지원 및 하이브리드 통신 시스템의 서비스 품질을 조정하기위한 전문가 시스템을 포함한다.
Description
인터넷은 점진적으로 고객 e-mail 시장에 대한 선택의 기회를 제공하는 통신 네트워크이 되어가고 있다. 최근에, 소프트웨어 회사들은 인터넷을 통한 전화 호출 전송에 관해 연구하기 시작했다. 그러나, 정상적인 호출 프로세싱을 위해 유저들이요구하는 시스템의 특성들이 인터넷의 호출 프로세싱에 필연적인 것으로 여겨진다. 오늘날, 인터넷상에서는 이러한 특성들을 제공하지 못한다. 따라서, 콜백 (callback)프로세싱을 용이하게 하기 위해서는 전화 능력을 포함하는 통신 네트워크를 인터넷에 접속시키는 시스템이 요구된다.
기존 전화 네트워크를 통해 호출을 예약하는 콜백 시나리오들이 잠시동안 이용되왔다. 그러한 서비스의 예로써 CSI 콜백, 국제 콜백을 위한 Rumilla 통신 및 분배, 도매 및 리빌링(rebilling) 특성을 제공하는 국제 콜백을 제공하는 SummitLink가 있다. 인터넷은 "콜백 서비스를 통한 이용할 수 있는 모든 정보의 수집"을 표방하는 "네트를 통한 콜백 (callback on the Net)" 이라는 웹사이트(website)를 제공한다. 이 정보는 검색 용어 "콜백"을 이용, 야후(Yahoo) 검색을 실행하여 얻어졌다.
종래의 시스템에 의해 제공되는 국제 콜백은 해외 교환국에 접속하기 위해서 번호를 다이얼할수 있는 유저와 관계한다. "콜백"은 디지털 교차 접속 시스템(DXC : Digital Cross-connect system)을 통과하는 고객의 음성 및 데이터 회로의 억세스 및 테스트에 관하여, 원격 테스트 시스템에 의해 이용되는 전화 용어다. 콜백 특성이 선택될 시, 원격 테스트 시스템은 로컬 전화선을 고객의 DSO 회로에 브리지(bridge)한다. 테스트중인 회로가 아날로그 회로인 경우, 원격 테스트기는 감시 기능을 실시한다. 테스트중인 회로가 음성 회로인 경우, 원격 테스트기는 원격 테스트 시스템에 의해 테스트중인 회로에 대한 고객의 전화에 대해 콜백에 대한 적절한 신호 상태를 선택하는 것을 포함하는 음성 테스트을 실시한다. 콜백 특성은 원격 테스트기가 원격 테스트기 위치에 같이 배치된 전화기로 전화 번호를 입력하게 한다.
원격 테스트 시스템은 내장형 카드에 부착된 로컬 전화선들을 갖는다. 이 전화선들의 목적은 테스트 시스템이 외부 호출을 할 수 있게하기 위함이다. 원격 유저가 영역 코드 또는 그들과 같은 장소에 배치된 전화를 포함하는 번호를 입력한 후에, 원격 테스트 시스템은 로컬 전화선들 중 하나를 선택하여, 훅오프시키고, 로컬 텔코(telco) 중앙국으로부터 다이얼 톤을 감지하자 마자 입력된 전화 번호에 펄스 또는 DTMF를 보낼 것이다. 원격 테스트기의 전화는 원격 테스트 시스템으로부터 호출을 수신하여, 훅오프시킨 다음, 원격 테스트 시스템으로부터의 호출은 완전한 것으로 간주된다.
원격 테스트기는 청취할 수 있는 품질을 감시하거나 또는 테스트중인 회로에 대한 적절한 신호 상태를 선택하여 음성 회로 고객 전화에 호출을 시작할 수 있다. 일단 고객에 대한 적절한 신호 상태가 선택되면, 채널 뱅크 카드 또는 PBX는 들어오는 호출을 검출하여 그것을 고객 전화에 대한 링 사이클로 변환한다. 이 동작에 대한 링잉(ringing) 상태를 고객 전화에 보낸다. 고객이 전화에 응답하자 마자, 원격 테스트기는 테스트중인 고객 회로를 통해 음성으로 고객과 통화한다. 이 테스트는 회로 보장 검증 테스트 동안 반복적으로 실시된다.
원격 테스트 시스템은 완성될 수 있는 외부 호출에 대해 제한을 받는다. 이 제한은 테스트 시스템의 인터페이스에 의해 지원될 수 있는 전화선들의 번호에 의존한다. 테스트 시스템내로 종결하는 각 로컬 선로에 대해 전화 회사가 매달 액세스 요금을 부과한다.
발명의 개요
본 발명의 한 양호한 실시예의 넓은 양상에 따르면, 전화 호출, 데이터 및 다른 멀티미디어 정보는 다중 경로와 다차원 콜백 프로세싱을 제공하기 위해서 인터넷을 통해 정보를 전송하는 교환 네트워크를 포함하는 하이브리드(hybrid) 네트워크를 통해 라우팅된다. 하이브리드 네트워크는 하나 이상의 패킷(packet) 전송 네트워크에 연결된 하나 이상의 교환 네트워크를 포함하며, 상기 패킷 전송 네트워크는 정보를 적절한 교환 전화 장치나 인터넷 장치 어드레스에 발송하기 위해서 호출 라우터(router)를 교환 통신 네트워크 및 패킷 전송 네트워크에 연결한다. 디스플레이가 부착된 컴퓨터는 패킷 통신 네트워크과 통신하며, 컴퓨터는 하이브리드 네트워크의 테스트을 포함하여 하이브리드 네트워크를 원격으로 관리하는데 이용되며, 상기 하이브리드 네트워크는 신호 상태를 선택하는 것과 같이 회로를 분석하는데, 상기 신호 상태는 루프 스타트 (loop start), 그라운드 스타트(ground start) 시작, 듀얼톤 다중 주파수 검출 또는 선로를 서비스부분에서 제거하는 것과 같은 것이다. 하이브리드 네트워크는 오퍼레이터가 하이브리드 네트워크의 관리를 감시하게 하고 전문가 시스템이 하이브리드 통신 시스템의 서비스 품질을 조정하게 하도록 지원한다.
본 발명은 인터넷과 전화 시스템의 통합에 관한 것으로, 특히 인터넷을 통신 시스템 아키텍춰의 통신 백본으로서 사용함과 아울러 호출 프로세싱 특성들의 배열을 풍부하게 유지하는 장치, 방법, 및 제조물에 관한 것이다.
상기 및 기타의 목적, 양상 및 장점들이 도면을 참조로 한 다음의 본 발명의 바람직한 실시예에 대한 상세한 설명에 의해 보다 잘 이해될 수 있을 것이다.
도1a는 바람직한 실시예에 따른 대표적인 하드웨어 환경의 블록선도이다.
도1b는 바람직한 실시예에 따른 전형적인 공통 채널 신호 시스템 #7(SS7) 네트워크의 아키텍쳐를 예시하는 블록선도이다.
도1c는 바람직한 실시예에 따른 인터넷(internet) 전화 시스템의 블록선도이다.
도1e는 바람직한 실시예에 따른 하이브리드 스위치의 블록선도이다.
도1e는 바람직한 실시예에 따른 하이브리드스위치의 연결에 대한 블록선도이다. .
도1f는 바람직한 실시예에 다른 하이브리드(인터넷-전화) 스위치의 블록선도이다.
도1g는 바람직한 실시예에 따른 하이브리드 인터넷 전화 스위치에 관계하는 소프트웨어 처리를 보인 블록선도이다.
도2는 바람직한 실시예에 따른 전형적인 SS7 네트워크에서의 PMU들의 사용을 보인 블록선도이다.
도3은 바람직한 실시예의 시스템 아키텍쳐를 예시하는 블록선도이다.
도4는 바람직한 실시예에 따른 로직 시스템 구성을 예시하는 하이 레벨의 프로세스순서도이다.
도5 - 9는 바람직한 실시예에 따른 도4에 예시된 구성요소들의 상세한 동작을 설명하는 프로세스 순서도이다.
도10a는 바람직한 실시예에 따른 공중 교환 전화망(PSTN) 1000을 예시하는 도면으로, 이 전화망은 로컬 교환 캐리어(LEC) 1020을 포함하며, 이 로컬 교환 캐리어를 통해 호출 진영이 전화 1021 또는 컴퓨터 1030을 사용하여 교환망에 접속하게 된다.
도10b는 바람직한 실시예에 따른 인터넷 라우팅 네트워크를 예시하는 도면이다.
도11은 바람직한 실시예에 따른 VNET PC에서 PC로의 정보 호출 흐름을 설명한다.
도12는 바람직한 실시예에 따른 VNET PC에서 아웃-오브-네트워크(out-of-network) PC로의 정보호출 흐름을 설명한다.
도13은 바람직한 실시예에 따른 VNET PC에서 아웃-오브-네트워크(out-of-network) 전화로의 정보호출 흐름을 설명한다.
도14는 바람직한 실시예에 따른 VNET PC에서 인-네트워크(in-network) 전화로의 정보호출 흐름을 설명한다.
도15는 바람직한 실시예에 따른 PC에서 PC로의 인터넷(internet) 전화 호출을 설명한다.
도16은 바람직한 실시예에 따른 인터넷을 통한 PC에서 전화로 라우팅되는 전화호출을 설명한다.
도17은 바람직한 실시예에 따른 전화에서 PC로의 호출을 설명한다.
도18은 바람직한 실시예에 따른 인터넷상에서 전화에서 전화로의 호출을 설명한다.
도19a 및 19b는 바람직한 실시예에 다른 지능 네트워크를 설명한다.
도19c는 바람직한 실시예에 따른 화상 회의 아키텍쳐를 설명한다.
도19d는 바람직한 실시예에 따른 화상 축적 전달 아키텍쳐를 설명한다.
도19e는 바람직한 실시예에 따른 인터넷상에서 영상 전화를 전송하기 위한 아키텍쳐를 설명한다.
도19f는 바람직한 실시예에 따른 인터넷 전화 시스템의 구성도이다.
도19g는 바람직한 실시예에 따른 우선 접속/라우터의 구성도이다.
도20은 바람직한 실시예에 따른 네트워크 구성 시스템의 고수준 구성도이다.
도21은 바람직한 실시예에 따른 도20에 나타난 시스템의 일부분의 작용 구성도이다.
도22는 도21의 바람직한 실시예에 따른 또 다른 고수준 구성도이다.
도23은 바람직한 실시예에 따른 스위치 없는(switchless) 네트워크 시스템의 구성도이다.
도24는 바람직한 실시예에 따른 도20 및 23에서 나타난 시스템의 일부분을 설명하는 계층 구성도이다.
도25는 바람직한 실시예에 따른 도24에 나타난 시스템의 일부를 설명하는 구성도이다.
도26은 바람직한 실시예에 따른 방법의 일부를 설명하는 구성도이다.
도27 - 39는 바람직한 실시예에 따른 도20 및 23의 시스템의 또 다른 양상을 설명하는 구성도이다.
도40은 바람직한 실시예에 따른 웹서버 로그온의 개요도이다.
도41은 바람직한 실시예에 따른 도40의 로그온과 함께 사용되는 서버 디렉토리의 개요도이다.
도42는 바람직한 실시예에 따른 도40의 로그온의 보다 상세한 개요도이다.
도43 - 50은 바람직한 실시예에 따른 하이브리드 네트워크의 부분들을 설명하는 구성도이다.
도51은 바람직한 실시예에 따른 데이터 관리 구간(DMZ) 5105의 구성이다.
도52a -52c는 바람직한 실시예에 따른 다이얼-인 환경과 연결하는 네트워크 구성도이다.
도53은 바람직한 실시예에 따른 팩스 톤(Fax Tone) 검출을 설명하는 순서도아다.
도54a - 54e는 바람직한 실시예와 일치하는 팩스 및 음성 메일 박스에 대한 VFP 완료 처리를 설명하기 위한 순서도이다.
도55a 및 55b는 바람직한 실시예에 따른 페이저 종료프로세서의 동작을 예시한다.
도56은 바람직한 실시예에 따른 페이저 종료로부터 호출되는 겟콜백(GetCallBack) 루틴(routine)을 예시한다.
도57은 바람직한 실시예에 따른 온라인 프로파일 관리(online profile management)로의 억세스를 위한 유저 로그인 스크린을 보여준다.
도58은 바람직한 실시예에 따른 유저의 호출 명령을 설정하거나 변경하기 위해 사용되는 호출 라우팅 스크린을 보여준다.
도59는 바람직한 실시예에 따른 회계 소유자(account owner)가 아닌 호출자에게 제시되는 게스트 메뉴를 설정하기 위해 사용되는 게스트 메뉴 구성 스크린을 보여준다.
도60은 바람직한 실시예에 따른 유저가 선택된 수신지에 대한 모든 호출을 라우팅 할 수 있도록 하는 오버라이드(override) 라우팅 스크린을 보여준다.
도61은 바람직한 실시예에 따른 스피드 다이얼을 설정하기 위해 사용되는 스피드 다이얼 번호 스크린을 보여준다.
도62는 바람직한 실시예에 따른 음성 메일을 설정하기 위해 사용되는 음성 메일 스크린을 보여준다.
도63은 바람직한 실시예에 따른 팩스메일을 설정하기 위해 사용되는 팩스메일 스크린을 보여준다.
도64는 바람직한 실시예에 따른 호출 스크린잉(screening)을 설정하기 위해 사용되는 호출 스크린잉 스크린을 보여준다.
도65 - 67은 바람직한 실시예에 따른 유저 프로파일 관리와 함께 사용되는 보조 스크린을 보여준다.
도68은 바람직한 실시예에 따른 유저가 입력한 스피드 다이얼 번호에 대한 검증이 어떻게 행해지는 지를 보여주는 순서도이다.
도69a - 69ai는 바람직한 실시예에 따른 소프트웨어 구현을 보여주는 자동응답 장치(ARU) 호출 순서도이다.
도70a - 70r은 바람직한 실시예에 따른 또 다른 소프트웨어 구현을 보여주는 콘솔(console) 호출 순서도이다.
도71은 바람직한 실시예에 따른 VNET - VNET 시스템에 대한 전형적인 클라이언트 환경설정을 설명한다.
도72는 바람직한 실시예에 따른 DAP의 운영을 설명한다.
도73은 바람직한 실시예에 따른 프로세스를 설명하는 데, 이 프로세스에 의해 전화는1-800 호출의 프로세싱을 위해 릴리스 링크 트렁크(Release Link Trunk)에 연결된다.
도74는 바람직한 실시예에 따른 고객 측의 DAP 절차 요구를 설명한다.
도75는 바람직한 실시예에 따른 호출자를 위해 특별한 번호 또는 핫라인을 선택하는 스위치 10530의 운영을 설명한다.
도76은 바람직한 실시예에 따른 인터넷을 통해 전화 호출을 선택적으로 라우팅하기 위한 컴퓨터에 기초한 음성 게이트웨이의 운영을 설명한다.
도77은 바람직한 실시예에 따른 중앙집중 아키텍쳐에 배치된 도76의 VRU의 운영을 설명한다.
도78은 바람직한 실시예와 일치하는 분산 아키텍쳐에 배치된 도76의 VRU의 운영을 설명한다.
도79a 및 79b는 바람직한 실시예에 따른 인터넷 호출 라우팅을 위한 표본 응용의 운영을 설명한다.
도79b는 바람직한 실시예에 따른 호출자에 의해 개시되는 소비자 트랜잭션을 위한 많은 응용을 설명한다.
도80은 바람직한 실시예에 따른 음성메일 및 음성 응답 장치 서비스를 제공하는 교환망의 구성을 설명한다.
도81은 바람직한 실시예에 따른 데이터베이스를 통해 데이터 공유와 함께 인바운드(inbound) 공유 자동 호출 분산기(ACD) 호출을 설명한다.
도82는 바람직한 실시예에 따른 예시적 통신시스템의 구성도이다.
도83은 바람직한 실시예에 따른 예시적 컴퓨터 시스템의 구성도이다.
도84는 바람직한 실시예에 따른 CDR 및 PNR 호출 기록 포맷을 설명한다.
도85a 및 85b는 바람직한 실시예에 따른 ECDR 및 EPNR 호출 기록 포맷을 종합적으로 설명한다.
도86은 바람직한 실시예에 따른 OSR 및 POSR 호출 기록 포맷을 설명한다
도87a 및 87b는 바람직한 실시예에 따른 EOSR 및 EPOSR 호출 기록 포맷을 종합적으로 설명한다.
도88은 바람직한 실시예에 따른 SER 호출 기록 포맷을 종합적으로 설명한다.
도89a 및 89b는 바람직한 실시예에 따른 스위치가 확장된 기록 포맷을 사용하는 조건을 설명하는 제어 흐름도이다.
도90은 바람직한 실시예에 따른 변환 시간 명령을 설명하는 제어 흐름도이다.
도91은 바람직한 실시예와 일치하는 변환 일광 절약 시간 제어를 설명하는 제어 흐름도이다.
도92는 바람직한 실시예에 따른 네트워크 호출 식별기 (NCID) 스위치 호출 처리약 시간 제어를 설명하는 제어 흐름도이다.
도93은 바람직한 실시예에 따른 수신된 NCID의 처리를 설명하는 제어 흐름도이다.
도94a는 바람직한 실시예에 따른 수신된 NCID의 생성을 설명하는 제어 흐름도이다.
도94b는 바람직한 실시예에 따른 NCID를 호출기록에 부가하는것을 설명하는 제어 흐름도이다.
도95는 바람직한 실시예에 따른 호출의 전송을 설명하는 제어 흐름도이다.
도96은 바람직한 실시예에 따른 화상 오퍼레이터가 화상 회의 플랫폼에 참석하는 것을 허용하는 것, 모니터링에 한정하지 않는 서비스를 제공하는 것, 화상 회의를 보고 기록하는 것 및 화상 회의 호출자를 보조하는 것 등을 위한 하드웨어 구성 실시예를 보여준다.
도97은 바람직한 실시예에 따른 화상 오퍼레이터 콘솔 시스템을 포함한 화상 오퍼레이터가 화상 회의를 관리하도록 하기 위한 시스템을 보여준다.
도98은 바람직한 실시예에 따른 화상 오퍼레이터 콘솔 시스템을 포함한 화상 오퍼레이터가 화상 회의를 관리하도록 하기 위한 시스템을 보여준다.
도99는 바람직한 실시예에 따른 화상 오퍼레이터에 의해 어떠한 방식으로 화상 회의가 개시되는가를 보여준다.
도100은 바람직한 실시예에 따른 화상 오퍼레이터 소프트웨어 시스템 클래스를 위한 클래스 계층을 보여준다.
도101은 바람직한 실시예에 따른 보콜 객체의 m_상태 가변(VOCall object's m_state variable)에서 일어날 수 있는 상태 변화를 설명하는 상태 전이도를 보여준다.
도102는 바람직한 실시예에 따른 보코넥션 객체의 m_상태 가변(VOConnection object's m_state variable)에서 일어날 수 있는 상태 변화를 설명하는 상태 전이도를 보여준다.
도103은 바람직한 실시예에 따른 보칸퍼런스 객체의 m_상태 가변(VOConference object's m_state variable)에서 일어날 수 있는 상태 변화를 설명하는 상태 전이도를 보여준다.
도104는 바람직한 실시예에 따른 보레코더 객체의 m_상태 가변(VORecoder object's m_state variable)에서 일어날 수 있는 상태 변화를 설명하는 상태 전이도를 보여준다.
도105는 바람직한 실시예에 따른 보레코더 객체의 m_상태 가변(VORecoder object's m_state variable)에서 일어날 수 있는 상태 변화를 설명하는 상태 전이도를 보여준다.
도106은 바람직한 실시예에 따른 화상 오퍼레이터 그래픽 유저 인터페이스에 대한 클래스 계층을 보여준다.
도107은 바람직한 실시예에 따른 화상 오퍼레이터 공유 데이터베이스에 대한 데이터베이스 도해를 보여준다.
도108은 바람직한 실시예에 따른 메인 콘솔 윈도우의 실시예를 보여준다.
도109는 바람직한 실시예에 따른 스케줄 윈도우의 실시예를 보여준다.
도110은 바람직한 실시예에 따른 오퍼레이터가 회의 또는 플레이백 세션(playback session)을 선택할 때 디스플레이 되는 회의 윈도우 41203의 실시예를 보여준다.
도111은 바람직한 실시예에 따른 회의 연결의 선택된 호출 또는 개별적 착신 또는 발신으로부터 H.320 입력을 디스플레이 하는 화상 와치(watch) 윈도우 41204의 실시예를 보여준다.
도112는 바람직한 실시예에 따른 모든 에러 메세지 또는 경고를 디스플레이 하는 콘솔 출력 윈도우 41205의 실시예를 보여준다.
도113은 바람직한 실시예에 따른 특성 대화 박스(Propertion dialog box)를 보여준다.
도 114a 는 바람직한 실시예에 따른 엑세스/라우터 시스템의 블록선도이다.
도 114b 는 바람직한 실시예에 따른 아키텍춰의 블록선도이다.
도 115 는 바람직한 실시예에 따른 인터넷 기반 콜백 아키텍춰의 블록선도이다.
인터넷(Internet)에 대한 서설
Ⅰ. 인터넷의 구성
인터넷은 컴퓨터가 인터넷에 도달되도록 하는 네트워크를 사용하기 위한 물리적 네트워크와 일련의 약정을 상호연결하는 방법을 말한다. 물리적으로, 인터넷은 92개국에 퍼져있고, 59,000개의 학술용, 상업용, 정부 및 군용 네트워크로 이루어져 있으며, GAO(Government Accounting Office)의 통계에 따르면 매년 2배 이상 증가하는 것으로 예상되는 거대하고 세계적인 네트워크이다. 또한 천만개의 호스트 컴퓨터, 5천만명의 유저 및 76,000개의 월드 와이드 웹(WWW) 서버가 인터넷에 연결되어 있다. 인터넷의 백본(backbone)은 미국내 및 전세계에 걸친 메이저 슈퍼컴퓨터 사이트와 교육 및 연구 기관들 사이의 일련의 고속 통신 링크로 구성된다.
단어 "인터넷"의 사용에 관한 일반적 오해가 불식되어야 한다. 원래 상기 단어는 인터넷 프로토콜에 기초한 네트워크의 이름으로서만 사용되었다. 그러나 오늘날 인터넷은 전체 클래스의 네트워크를 나타내는 일반적 이름으로 사용되고 있다. "인터넷(internet-소문자 i)"은 공통의 프로토콜에 의해 상호 연결되어 단일의 논리적 네트워크를 형성하는 개별적 물리 네트워크들의 집합을 말하며, "인터넷(Internet-대문자 I)"는 다수의 물리적 네트워크들을 단일의 논리적 네트워크에 연결하기 위해 인터넷(Internet) 프로토콜을 사용하는 상호 연결된 네트워크들의 전세계적인 집합을 말한다.
Ⅱ. 프로토콜 표준
A. 인터넷 프로토콜(Internet Protocol)
프로토콜은 인터넷 백본에 따른 행동을 통제하고, 따라서 데이터 통신을 위한 중요한 규칙을 제공한다. 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP)은 개방적 성질을 가지고 있어 모든 사람들에게 이용가능한 바, 이는 TCP/IP가 컴퓨터 또는 네트워크 운영시스템 및 아키텍쳐의 차이에 독립적인 네트워크 프로토콜 시스템을 생성하고자함을 의미한다.
B. 국제 전기 통신 연합 - 전기통신 표준화 분과 (ITU -T) 표준
ITU-T는 전기통신 장치를 위해 프로토콜 및 라인 코드화를 통제하는 수많은 표준을 확립하였다. 이들 표준들 중의 많은 부분이 본 출원서에서 참조되고 있는 바, 참고를 위해 하기에 관련표준들을 요약하였다.
ITU G.711 : 3 kHz 음성 체널의 펄스 부호 변조에 대한 권고.
ITU G.722 : 64 kbit/s 채널 내에서의 7 kHz 음성 코드화에 대한 권고.
ITU G.723 : 5.3 및 6.3 kbit에서 멀티미디어 통신 전송을 위한 이중 비율의 속도 스피치 코더(dual rate speech coder)에 대한 권고.
ITU G.728 : 저지연 코드 여기 선형 예측(LD-CELP: low-delay, code excited linear prediction)을 사용한 16 kbit/s의 속도로의 스피치 코드화에 대한 권고.
ITU H.221 : 시청각 텔레서비스에 있어서 64 내지 1920 kbit/s 채널을 위한 프레임 구조.
ITU H.223 : 저 비트율 멀티미디어 터미널에 대한 멀티플렉싱 프로토콜.
ITU H.225 : 비보장된 질의 서비스 LAN에 있어서 미디어 스트림 패킷화 및 동기화에 대한 ITU 권고.
ITU H.230 : 시청각 시스템을 위한 프레임 동기 제어 및 지시 신호.
ITU H.231 : 2 Mbit/s로의 디지털 채널 업을 사용한 시청각 시스템에 대한 다중점(multipoint) 제어 장치 권고.
ITU H.242 : 2 Mbit/s로의 디지털 채널 업을 사용한 시청각 터미널 사이의 통신 설립을 위한 시스템.
ITU H.243 : 2 Mbit/s로의 디지털 채널 업을 사용한 2 이상의 시청각 터미널 사이의 통신 설립을 위한 시스템.
ITU H.245 : 멀티미디어 통신을 위한 제어 프로토콜에 대한 권고.
ITU H.261 : 355×288 픽셀(pixel) 및 176×144 픽셀의 영상 해상도를 지원하는 시청각 서비스를 위한 영상 코더-디코더(coder-decoder)에 대한 권고.
ITU H.263 : 128×96 픽셀, 176×144 픽셀, 352×288 픽셀 및 704×576 픽셀의 영상 해상도를 지원하는 시청각 서비스를 위한 영상 코더-디코더에 대한 권고.
ITU H.320 : 좁은 밴드 ISDN 시각 전화 시스템에 대한 권고.
ITU H.321 : ATM 상의 시각 전화 터미널.
ITU H.322 : 보장된 질의 서비스 LAN 상의 시각 전화 터미널.
ITU H.323 : 비보장된 질의 서비스를 제공하는 LAN을 위한 시각 전화 서비스 및 장비에 대한 ITU 권고.
ITU H.324 : 다이얼 업 전화 서비스에서의 저 비트율(28.8 Kbit) 멀티미디어 통신을 위한 터미널 및 서비스에 대한 ITU 권고.
ITU T.120 : 멀티미디어 통신을 위한 전송 프로토콜.
또한 몇몇의 다른 관련된 표준이 인용 참고되었다.
ISDN : 종합 정보통신망, 단일 통신 연결에 의해 음성, 영상 및 데이터를 위한 디지털 통신 표준.
RTP : 실시간 이송 프로토콜(Real Time transport Protocol), 단일망 또는 다중망을 통해 음성 및 영상과 같은 실시간 데이터를 전송하기 위한 인터넷 표준 프로토콜.
IP : 인터넷 프로토콜, 상호 연결된 컴퓨터 시스템의 패킷 교환망에서 데이터 패킷의 전송 또는 전달을 위한 인터넷 표준 프로토콜.
PPP : 점대점 프로토콜
MPEC : 동영상 표준화 그룹, 국제 표준화 기구(ISO)의 하부 표준화 기구. 압축 알고리즘을 제외하고, 비트 스트림을 포함한 디지털 영상 및 음성의 압축에 대한 권고.
SLIP : 시리얼(serial) 라인 인터넷 프로토콜.
RSVP : 자원 예약 설정 프로토콜.
UDP : 유저 데이터그램(datagram) 프로토콜.
Ⅲ. TCP/IP 의 특징
인터넷에서의 TCP/IP 프로토콜의 인기는 전세계적 데이터 통신에 대한 중요한 요청을 만족시키고 이러한 요청을 만족시키는 중요한 기능을 가지고 있기 때문에 급속히 증대하였다. 오늘날에도 사용되고 있는 그러한 특징들에는:
1) 인터넷 상에서 TCP/IP를 운영하는 어떤 장치가 다른 장치의 주소를 설정하는 공통 어드레싱 방식 및
2) 하드웨어 또는 운영시스템이 어떠한 것인지에 관계없이 자유롭게 이송 가능하며 발전될 수 있는 개방 프로토콜 표준 등이 포함된다.
따라서 TCP/IP는 이서넷(Ethernet), 토큰 링, 다이얼 업 라인 또는 사실상 다른 어떠한 종류의 물리적 전송 미디어에도 사용될 수 있다.
Ⅳ. 통신 네트워크에서의 정보 이송
A. 교환 테크닉
통신 시스템에서의 정보의 전달 방법에 대한 이해는 오늘날 인터넷 백본 비지니스에 있어서 매우 중요한 역할을 담당하는 자에 의해 이루어진 최근의 발자취를 이해하는 것이 필요하다. 미국 전화 시스템은 회선 교환 테크닉을 사용한다. 사람 또는 컴퓨터가 전화 호출을 하면 전화 시스템 내의 교환 장비가 발신 전화에서 수신자 전화로의 물리적 경로를 찾는다. 회선 교환망은 발신 전화에서 로컬 교환국을 통해 그리고 그 다음 전화국, 트렁크 라인을 통해 원격 교환국, 및 최종적으로 목적지 전화로의 회선 연결에 의해 두 지점간에 전용연결 또는 전용회선을 형성하려고 시도한다. 이 전용 연결은 호출이 종료될 때까지 계속된다.
완전한 경로의 개설은 회선 교환망에서의 데이터의 전송에 있어서 선결요건이다. 회선이 놓여진 후, 마이크로폰은 아날로그 신호를 사로잡고, 그 신호는 아날로그 루프(loop) 상으로 시내 교환 캐리어(LEC) 중앙국(CO)으로 아날로그 형태로 전송된다. 아날로그 신호는 LEC CO에 도착한 후 디지털 형태로 변화되는데, 이것조차도 장비가 디지털 정보를 지원할 수 있을 정도로 현대적인 경우에 가능하다. 그러나, ISDN 실시예에서 아날로그 신호는 상기 장치에서 디지털로 전환된 후, 디지털 정보로 LEC에 전송된다.
64 Kbit(초당 천 비트)의 데이터 경로를 유지함에 의해 회로는 샘플이 전달될 수 있다는 것과 재생산될 수 있다는 것을 보장한다. 이 속도는 "디지털화된 음성" 그 자체를 전송하기 위해 요구되는 속도가 아니라, 펄스 부호 변조(PCM) 테크닉에 의해 디지털화된 "음성"을 전송하기 위해 요구되는 속도이다. 음성을 디지털화 하기 위한 많은 방법이 존재하는 데, ACPDM(32Kbps), GSM(13Kbps), TrueSpeech 8.5(8.5Kbps) 및 Voxware RT29HQ(2.9Kbps) 등이 포함된다. 또한 64 Kbps 경로는 LEC CO 스위치에서 LEC CO까지 유지되나, 종단간에는 그러하지 아니하다. 아날로그 국부 루프는 64 Kbps 디지털화된 음성이 아니라 아날로그 신호를 전송한다. 이 아날로그 국부 루프들 중의 하나는 호출자의 국부 전화에 접촉하기 위해 통상 전화망 회선 각각의 "라스트 마일(last mile)"의 형태로 존재한다.
이러한 능력의 보장은 회선 교환망의 강점이다. 그러나 회선 교환은 두 가지 결점을 가지고 잇다. 첫째, 다른 호출에 의해 라인이 붐빌 경우 호출이 되지 아니하기 때문에 설정 시간이 상당하다: 이럴 경우 다른 연결이 종료할 때까지 연결되지 아니한다. 둘째로 비용이 비싼 반면 유용성은 떨어질 수 있다. 즉, 호출자는 호출하는 동안, 데이터 전송이 하지 아니함에도 불구하고 모든 시간의 비용을 부담한다. 신호들의 전송사이의 시간은 전용라인이기 때문에 다른 호출에 사용될 수 없기 때문에 유용성은 낮을 수 있다. 연결된 후에는 사용되지 아니하는 시간은 낭비된다.
부가적으로는 전체 회선 교환 하부 조직은 64 Kbps 회선 주위에 설치되어 있다. 하부망은 음성에 대해 PCM 코드화 테크닉을 사용한다. 그러나 고질의 코덱(Codec)은 PCM 대역폭의 10분의 1보다 적게 사용하여 음성을 코드화할 수 있다. 그러나 대역폭의 10분의 1이 사용됨에도 불구하고, 회선교환망은 64 Kbps의 대역폭을 하나의 호출에 모두 할당한다. 또한 각 회선은 통상 단지 두 가입자만 연결한다. 회의 브릿징 장비의 도움이 없다면, 하나의 가입자와 또 하나의 다른 가입자를 연결하함에 의해 전화에 대한 모든 회선이 점거된다. 회의 브릿징 장비와 조합하여 사용되는 경우를 제외하면, 회선 교환은 멀티캐스트 또는 다분기점 통신 능력을 가지고 있지 않다.
긴 호출 설정 시간에 대한 다른 이유는 호출 설정에 관계된 서로 다른 신호망 및 전달 지연을 일으키는 장거리를 포함한다. 낮은 대역폭 링크에 기초한 종단에서 CO로의 아날로그 신호의 전달은 또한 호출 설정을 지연시킬 수 있다.
또한 호출 신호 데이터는 항상 데이터를 빛의 속도로 전송하는 것은 아닌 신호망 상에서 장거리를 이동한다. 호출이 국제적이라면, 신호망의 다양함은 증가하고 호출 설정을 다루는 장비는 모뎀 설정보다는 통상 빠르지 아니하기 때문에 설정 시간이 증가하고, 또한 거리가 더욱 증가하면 호출설정 시간은 더욱 증가한다. 더 나아가 일반적으로 회선 교환과 같은 연결지향의 가상 또는 물리 회선 설정은 미연결된 기술보다 대화하는 가입자 사이에 요구되는 종단간 연결로 말미암아 연결 설정에 더 많은 시간이 요구된다.
메시지 교환은 또 다른 교환 방식의 한 예이다. 이 교환 방식은 수신자와 송신자 사이에 물리 경로가 미리 확립되지는 않는다. 반면에 송신자가 송신할 데이터 블록을 가지고 있을 때는 교환국에 먼저 저장되고, 에러의 검사 후에 다음 교환 부로 재전송된다. 메시지 교환은 블록 사이즈에 제한이 없으며, 따라서 교환국은 긴 데이터 블록을 완화할 디스크를 가져야만 한다. 또한 하나의 블록이 한 회선을 장시간 사용할 경우에는 메시지 교환이 상호 작용의 통화량에 대해 쓸모가 없다.
컴퓨터 네트워크 산업의 대부분을 차지하는 패킷 교환망은 데이터를 고용량 기계간 연결로 다중 송신되는 패킷이라 불리는 작은 부분으로 나눈다. 패킷은 블록 크기에 엄격한 상한선을 가진 데이터의 한 블록으로서, 목적지에 전달되기 위해 필요한 충분한 식별을 가지고 있다. 이러한 패킷은 몇 백 바이트의 데이터를 가지고 있으며 만 분의 1초 정도 전송라인을 점유한다. 패킷 교환에 의한 큰 파일의 전달은 많은 패킷으로 분해하고, 그 각각을 하나의 기계에서 다른 기계로 한 번에 송신한다. 네트워크 하드웨어는 이러한 패킷을 특정의 목적지로 전달하고, 그곳에서 소프트웨어가 그것들을 하나의 파일로 재조합한다. 패킷 교환은 데이터 전송의 효율성으로 인해 사실상 모든 컴퓨터 상호연결에 사용된다. 패킷 교환망은 회선상의 대역폭을 필요한 만큼만 사용하며, 패킷 전송 사이에 다른 전송이 라인을 통해 행해질 수 있다. 또한 라우터 또는 교환국이 다음 교환국으로 수신한 패킷 또는 큰 파일의 부분을 다른 패킷이 도달하기 전에 빨리 전송할 수 있기 때문에 처리량은 증가한다. 메시지 교환에 있어서는 중간 라우터가 전체 블록이 전달될 때까지 기다려야 한다. 패킷 전송의 우월성으로 인해 오늘날 메시지 교환은 컴퓨터 네트워크에 있어서 더 이상 사용되지 아니한다.
인터넷(Internet)을 보다 잘 이해하기 위해서는, 전화 시스템과의 비교가 도움이 된다. 공용 교환 전화망은 인간 음성을 인지 가능한 형태로 전송하는 것을 목적으로 고안되었다. 컴퓨터 통신에 때한 그들의 적합성은 개선되어 왔지만 최적과는 거리가 멀다. 두 컴퓨터사이에 연결되는 케이블은 메가 비트의 백 배의 속도, 더 나아가 기가 비트의 속도로 데이터를 전송한다. 이 스피드에서의 에러 속도는 단지 하루에 1회 정도이다. 반면에 표준적 전화 라인을 사용하는 다이얼 업은 최대 속도가 1초에 천 비트이며 에러 속도가 더 높다. 에러 속도와 비트 속도의 곱은 국부 케이블이 전화 라인의 1011정도이다. 그러나 새로운 기술이 전화 라인의 효율을 개선시키고 있다.
B. 게이트웨이 및 라우터
인터넷(Internet)은 수천개 컴퓨터 시스템의 전체적 연결을 형성하는 많은 수의 네트워크로 구성된다. 기계들이 개개의 네트워크에 연결되는 것을 이해한 후에, 인터네트워크(internetwork) 또는 인터넷(internet)을 형성하는 네트워크 상호간의 연결방법을 살펴볼 수 있는 바, 이 때 인터넷(internet) 게이트웨이와 인터넷(internet) 라우터가 작용한다.
아키텍쳐의 면에서 볼 때, 주어진 두 개의 네트워크는 둘을 접속시키는 하나의 컴퓨터에 의해 연결된다. 인터넷 게이트웨이와 라우터는 네트워크 사이에 패킷을 송신하기 위해 필요한 링크를 제공하고, 따라서 연결이 가능하게 한다. 이러한 연결이 없다면 인터넷(Internet)을 통한 데이터 통신은 불가능하며, 정보는 목적지에 도달하지 아니하고, 도달하더라도 이해될 수 없다. 게이트웨이는 서로 모순된 네트워크 사이에 코드 및 프로토콜 전환을 수행하는 통신망에 대한 출입구로 생각될 수 있다. 예를 들면 게이트웨이는 인터넷(internet) 상의 네트워크 사이에 전기 메일 및 데이터 파일을 전송한다.
IP 라우터도 또한 네트워크를 연결하는 컴퓨터이며, 벤더들이 선호하는 새로운 단어이다. 라우터는 수신된 데이터 패킷을 계속 업데이트된 라우팅 테이블과 비교하여 목적지로 송신하는 방법을 결정해야한다. 패킷의 목적 네트워크 주소를 분석함에 의해 라우터는 이러한 결정을 하게 된다. 라우터는 통상 어떤 호스트 또는 유저가 패킷을 수신하는지에 대해서 결정할 필요는 없다. 반면에 라우터는 단지 목적 네트워크를 찾고, 반드시 적절한 최종 수요자일 필요 없이 적절한 네트워크에 도착하기에 적합한 정보를 기억하고 있다. 따라서 라우터는 거대한 슈퍼컴퓨터 시스템일 필요는 없으며, 종종 소용량이며 디스크 기억장치가 거의 없는 기계이다. 게이트웨이와 라우터의 차이는 작으며, 종종 서로 교환하여 사용될 수 있을 정도로 경계가 흐려져 있다. 현대적 용어학에서는, 게이트웨이는 서로 다른 프로토콜사이에서 데이터를 전달하고, 라우터는 서로 다른 네트워크사이에서 데이터를 전달한다. 그러므로 TCP/IP 및 OSI 사이에 메일을 전달하는 시스템은 게이트웨이이나, 전통적 IP 게이트웨이(서로 다른 네트워크를 연결함)는 라우터이다.
전통적 전화 시스템에서 라우팅을 단순하게 살펴보는 것은 유용하다. 전화 시스템은 과다하고 다중의 계층 구조로 망되어 있다. 각 전화는 두개의 구리선을 가지고 있으며, 이것은 전화기와 전화 회사의 가장 가까운 최종 오피스, 즉 시내 중앙국(local central office)이라 불리는 곳을 연결한다. 그 거리는 통상 10 km 보다 적으며: 미국에서만 거의 20,000개의 최종 오피스가 존재한다. 전화번호의 첫 3자리 수는 지역 코드와 결합되어 특정 최종 오피스를 나타내며, 속도와 요금 부과 구조를 지칭한다.
각 가입자 전화 및 최종 오피스 사이의 두선 연결은 로컬 루프라 부린다. 만약 가입자가 같은 최종 오피스에 연결된 가입자를 호출한다면, 오피스내의 교환 메카니즘은 두 개의 로컬 루프 사이에 직접적 전기적 연결을 설치한다. 이 연결은 회선교환망에 의해 호출이 지속되는 동안에 계속된다. 만약 가입자가 서로 다른 최종 오피스에 연결된 가입자를 호출한다면, 호출을 라우팅하기 위해 더 많은 작업이 행해져야 한다. 먼저 각 최종 오피스는 시외 오피스(toll office)라 불리는 이웃한 교환국에 연결되는 하나 이상의 출중계 라인을 가지고 있다. 이 라인은 시외 연결 트렁크라 불린다. 만약 호출자 및 수신자가 같은 시외 연결 트렁크에 연결되어 있다면, 시외 오피스내에서 연결이 설정될 수 있다. 만약 호출자 및 수신자가 같은 시외 연결 트렁크에 연결되어 있지 않다면, 계층 구조에서 보다 높은 곳에서 이 연결이 행해질 수 있다. regional 오피스 및 sectional 오피스는 네트워크를 형성하며, 이 네트워크에 의해 시외 오피스가 연결된다. 시외, 지역 교환국은 높은 대역폭 인터-톨(inter-toll) 트렁크를 통해 서로 통신한다. 교환국의 종류 및 그 독특한 형태는 전화 밀도에 따라 나라마다 다르다.
C. 매끄러운 유저 연결을 위한 네트워크 수준의 통신 사용법
인터넷(Internet)의 데이터 전송 기능 외에도, TCP/IP는 인터넷이 유일하며 가상의 네트워크라는 것을 유저에게 확신시킨다. TCP/IP는 호스트 또는 유저가 접속되는 특정한 네트워크에 상관없이 기계들을 전세계적으로 연결하여 이것을 성취한다. 물리 네트워크의 라우터 상호연결 외에도, 각각의 호스트에 소프트웨어, 즉 인터넷(Internet)을 유일하고 실제적인 물리 네트웨크로써 사용하게 하는 응용 프로그램이 요구된다.
D. 데이터그램 및 라우팅
인터넷 서비스의 기초는 전송 기본 단위로 패킷을 이용하여, 라우터에 의해 작동되는 근원적이며 연결 없는 패킷 전송 시스템이다. 인터넷(Internet) 백본과 같은 TCP/IP를 작동하는 인터넷(internet)에 있어서, 이 패킷은 데이터그램이라 불린다. 이 단락은 이 데이터그램이 인터넷(Internet)을 통해 라우팅되는 방법에 대해서 서술하겠다.
패킷교환망에 있어서, 라우팅은 어떠한 경로를 통해 패킷을 송신할 것인가를 결정하는 과정이다. 전술한 바와 같이. 라우터는 그러한 선택을 행하는 컴퓨터이다. 같은 네트워크 상에서 하나의 호스트에서 다른 호스트로 정보를 라우팅하기 위해서는 송신되는 데이터그램이 인터넷 백본에 도달할 필요는 없다. 이것은 내적 라우팅의 예이다. 네트워크의 외부에 있는 기계는 이러한 내적 라우팅 결정에 관여하지 아니한다.
직접 전송과 간접 전송의 구별은 다음과 같다. 직접 전송은 하나의 네트워크 상에 있는 서로 다른 기계들 사이에서 행해지는 데이터그램의 전송을 말한다. 그런 전송은 라우터와 관련되지 아니한다. 반면에 송신자는 데이터그램을 물리 프레임의 형태로 요약화하고, 주소를 쓴 후, 상기 프레임을 목적 기계에 직접 송신한다.
간접 전송은 둘이상의 물리네트워크가 관련되었을 경우에 필요하다. 즉 서로 다른 네트워크 상에서의 정보의 전송에 사용된다. 이런 형태의 통신은 인터넷(Internet) 백본을 통해 정보를 라우팅하는 것이라 생각할 수 있다. 간접 전송에 있어서 라우터는 필수적이다. 데이터그램을 송신하기 위해서, 송신자는 데이터그램을 송신할 라우터를 식별하고, 그 후 라우터는 데이터그램을 목적 네트워크로 송신한다. 라우터는 수백 만개인 개개의 호스트 주소를 기억하지 않으며 수천 개의 물리 네트워크를 기억한다는 것은 전술한 바 있다. 근본적으로 인터넷(internet)에 있어서 라우터는 상호 협동적이며, 상호연결된 구조를 형성하며, 데이터그램은 라우터가 데이터그램을 직접 전송할 수 있는 라우터에 도달할 때까지 백본을 가로질러 하나의 라우터에서 다른 라우터로 보내진다.
Ⅴ. 기술 개요
새로운 기술 및 시스템의 지속적 유입에 의해 인터넷(internet) 세계는 계속 변화하고 있다. 가까운 미래에 더 유행할 것 같은 아래의 3개의 발전이 기술계에 대한 개요를 제공해준다.
A. ATM
비동기 전송 방식(ATM - Asynchronous Transfer Mode)은 시내 및 광역망을 위한 고속, 커넥션 지향적 시스템을 사용하는 뛰어난 기술이다. ATM 네트워크는:
·많은 컴퓨터로부터의 통신량을 처리하기 위해 초당 기가 비트(1조 비트)의 속도로 작동되는 고속 스위치,
·호스트와 ATM을 연결하며 100 또는 155 Mbps의 속도로 작동되는 스위치를 가지며, 데이터 고속 전송을 제공하는 광섬유(구리선에 대비하여), 및
·각각이 53 바이트로 이루어진 고정된 크기의 셀(cell)을 포함하는 현대식 하드웨어를 요한다.
ATM은 데이터 뿐만 아니라 음성, 영상 및 텔레비전 신호를 전송하기 위해 설계되었기 때문에 패킷교환 및 회선교환의 기능을 통합한다. 순수 패킷교환 기술은 더 안정한 대역폭을 요하는 음성전송을 수행하기에는 만족스럽지 아니하다.
B. 프레임 릴레이(Frame relay)
프레임 릴레이 시스템은 패킷교환 기술을 사용하나 전통적 시스템보다는 더 효율적이다. 이 효율성은 전통적 X.25 패킷교환 서비스보다 더 적은 에러 체크를 수행하는 데 부분적으로 기인한다. 많은 중간 노드(node)는 에러체크를 거의 또는 전혀 수행하지 아니하며 단지 라우팅만을 수행하며, 에러 체크는 시스템의 고층에서 행한다. 오늘날 전송의 높은 신뢰성으로 인해 이전에는 행해졌던 많은 에러 체크가 불필요하게 되었다. 따라서 프레임 릴레이는 전통적 시스템에 비해 높은 성취를 제공한다.
C. ISDN
종합 정보 통신망(ISDN - Integrated Service Digital Network)은 대개 64 Kbit/s 의 속도로 운영되는 "음성, 영상 및 데이터를 디지털 회선을 통해 전송하기 위한 국제 전기통신 표준"이다. 전통적 전화망은 음성을 4 Kbit/s의 속도로 운영한다. ISDN을 채용하려면 최종 수요자 또는 회사는 ISDN 터미널 장비, 중앙국 하드웨어 및 중앙국 소프트웨어로 업그레이드하여야 한다. ISDN이 표방하는 목적은:
·음성, 데이터 및 신호에 대해 국제적으로 용인되는 표준의 제공하는 것,
·종단간 모든 전송 회선을 디지털화 하는 것,
·표준 대역외 신호 시스템을 채용하는 것, 및
·더 많은 대역폭을 데스크탑(desktop)에 제공하는 것을 포함한다.
Ⅵ. MCI 지능망(Intelligent Network)
MCI 지능망은 음성, 팩스 및 관련된 서비스를 처리하기 위한 호출 처리 아키텍쳐이다. 상기 지능망은 자동 호출 분산기(ACD)를 따라 특정 용량을 가진 특정 목적 브릿징 스위치와 다목적 컴퓨터로 구성되어 있다. 수 변환 서비스, 자동 또는 수동 오퍼레이터 서비스, 타당성 검사 서비스, 데이터베이스 서비스 등을 포함하는 호출 처리는 전문화된 소프트웨어를 가진 일련의 전용 다목적 컴퓨터에 의해 행해진다. 새로운 가치가 부가된 서비스는 소프트웨어를 확장함에 의해 단순하며 경제적인 방식으로 시스템에 쉽게 통합될 수 있다.
아래의 단어들에 대해 정의가 도움이 될 것이다.
ISP : 지능 서비스 플랫폼
NCS : 네트워크 제어 시스템
DAP : 데이터 접속점
ACD : 자동 호출 분산기
ISN : 지능 서비스망(지능망)
ISNAP : 지능 교환망 부속 처리기
MTOC : 수동 전기통신 운영 콘숄
ARU : 음성 응답 장치
ACP : 자동 호출 처리기
NAS : 네트워크 음성 서버
EVS : 확장된 음성 서비스
POTS : 전통적 구 전화 시스템
ATM : 비동기 전송 방식
지능망 아키텍쳐는 풍부한 일련의 기능을 가지고 있으며, 매우 유연하다. 새로운 기능 및 서비스의 부가는 단순하며 빠르다. 기능 및 서비스는 다목적 컴퓨터에서 작동하는 특정 목적 소프트웨어를 이용하여 확장될 수 있다. 새로운 기능 및 서비스의 부가는 특정 목적 소프트웨어를 업그레이드함에 의해 이루어지며, 경제적이다.
지능망 기능 및 서비스는:
·호출 형태 식별,
·호출 라우팅 및 선택적 종료
·오퍼레이터 선택 및 호출 보류
·음성 인식 및 자동, 대화식 응답
·고객 및 고객 프로파일 검증 및 타당성 검사
·음성 메일
·호출 타당성 검사 및 데이터 베이스
·음성 회의 예약
·팩스 전송 및 보도
·고객 요금 부과
·기만 모니터링(Fraud Monitoring)
·오퍼레이션널 측정 및 사용 통계 리포팅, 및
·스위치 인터페이스 및 제어 등을 포함한다.
A. MCI 지능망의 구성요소
도19A는 바람직한 실시예와 일치하는 지능망을 설명한다. MCI 지능망은 다수의 구성요소로 이루어진다. MCI 지능망의 주요 구성요소는
·MCI 교환망 2,
·네트워크 제어 시스템(NCS)/데이터 접속점(DAP) 3,
·ISN - 지능 서비스망 4, 및
·EVS - 확장된 음성 서비스 9를 포함한다.
1. MCI 교환망
MCI교환망은 특정 목적 브릿징 스위치 2로 구성되어 있다. 이 브릿징 스위치 2는 호출이 지능 서비스망 4에 의해 검증된 후 호출자 및 피호출자를 라우팅하고 연결한다. 이 브릿징 스위치는 제한된 프로그래밍 용량을 가지고 있으며, 지능 서비스망(ISN) 4의 제어 하에 기본적 교환 서비스를 제공한다.
2. 네트워크 제어 시스템/데이터 접속점(NCS/DAP)
NCS/DAP 3은 MCI 지능망의 필수 구성요소이다. DAP는 수 변환과 같은 다양한 데이터베이스 서비스를 제공하며. 또한 호출에 대한 착신 수의 스위치 ID 및 트렁크 ID를 식별하는 서비스를 제공한다.
NCS/DAP 3에 의해 제공되는 서비스는:
·800, 900 VNET 수에 대한 수 변환,
·시외통화 옵션을 제한하는 범위 제한과 시간, 날짜, 발신지 및 퍼센트 할당을 포함하는 향상된 파라미터 라우팅,
·호출에 대한 착신 번호 중에서 스위치 ID 및 트렁크 ID를 포함하는 정보 데이터베이스,
·고객 데이터베이스에 대한 원격 질의,
·VNET/950 카드 타당성검사 서비스, 및
·VNET ANI/DAL 타당성 검사 서비스를 포함한다.
3. 지능 서비스망(ISN) 4
ISN 4는 호출을 라우팅하기 위한 자동 호출 분산기(ACD)를 포함한다. ACD는 지능 교환망 부속 처리기(ISNAP) 5와 통신하며, 다른 수동 또는 자동 에이전트에 호출을 전송한다. ISN은 ISNAP 5 및 오퍼레이터 네트워크 센터(ONC)를 포함한다.
ISNAP 5는 호출 라우팅을 위해 군 선택 및 오퍼레이터 선택을 책임진다. ISNAP는 다른 에이전트에게 호출을 전송하기 위해 ACD와 통신한다. ISNAP는 또한 오퍼레이터에 의해 원조되는 호출을 위한 데이터 및 음성을 좌표화하는 책임을 지고 있다. ONC는 라이브 오퍼레이터 또는 자동호출 처리기(ACP), MTOC 및 NAS 7을 포함하는 자동응답장치(ARU)를 포함하는 에이전트, 서버 및 데이터베이스로 구성되어 있다. 이 시스템은 이서넷 LAN 상에서 서로 통신하며, 호출 처리를 위한 다양한 서비스를 제공한다.
ONC에 의해 제공되는 서비스는:
·호출형태 식별, 호출 타당성검사 및 호출 제한을 포함하는 타당성 검사서비스,
·고객 지원을 위한 수동 또는 자동 오퍼레이터 서비스,
·다양한 데이터베이스 룩업을 위한 데이터베이스 서비스,
·호출 확장 능력,
·호출 브릿징 능력,
·유저 입력을 위한 프롬프트, 및
·플레이 음성 메시지를 포함한다.
4. 확장된 음성 서비스 (EVS - enhanced voice service)
확장된 음성 서비스는 가치가 더해진 수 개의 기능 외에도 메뉴-기초된 라우팅 서비스를 제공한다. EVS 시스템은 유저가 입력할 것을 촉진하며, 고객 입력에 기초하여 호출을 라우팅 하거나 음성 메일 또는 팩스 라우팅을 위한 특별한 서비스를 제공하여 준다. MCI 지능망의 구성요소인 EVS가 제공하는 서비스는:
·플레이 고객 특정 음성 서비스,
·유저 입력을 위한 프롬프트,
·정보접속에 기초한 유저 입력,
·호출 확장 능력,
·호출 브릿징 능력,
·음성 회의 능력,
·호출 전송능력
·유저 음성 메시지 기록,
·기록된 음성메시지의 원격 업데이트, 및
·팩스 전송 및 수신 등을 포함한다.
5. 부가적 요소
상기 언급한 구성요소 외에도, 일련의 부가적 요소가 MCI 지능망에 포함되어 있다. 이러한 구성요소는:
·지능 호출 라우팅(ICR) 서비스는 호출 중 또는 이전의 호출에 의해서 호출자로부터 얻어진 정보를 기초로 해서 특별한 호출 라우팅을 위해서 제공된다. 라우팅은 또한 물리 또는 논리적 네트워크 배치의 지식에 기초해서 얻어진다. 시간에 기초한 부가적 지능 라우팅 및 통화중 라우터에 기초한 교체 가능한 라우팅 서비스가 또한 제공된다.
·요금 부과는 MCI 지능망의 주요한 구성요소의 하나이다. 요금 부과 구성요소는 호출 형태 및 호출 시간에 기초해서 고객의 요금 부과를 위한 서비스를 제공한다. 특별한 요금 부과 서비스는 800 콜렉트 콜과 같은 가치가 부가된 서비스를 위해 부가적으로 제공된다.
·기능 모니터링 요소는 네트워크의 기만적 또는 비합법적 사용 때문에 수입이 감소되는 것을 방지하기 위한 서비스를 제공하는 MCI 지능망의 주요한 구성요소의 하나이다.
·오퍼레이션널 측정은 생산 성취도의 분석을 위해 모으는 정보를 포함한다. 광고 캠페인에 대한 응답의 분석, 전문화된 리포트를 야기하는 호출 형태는 오퍼레이션널 측정으로부터 유래된다. 모여진 정보는 미래의 생산 계획 또는 하부구조의 요구를 예측하는 데 이용된다.
·사용법 통계 리포팅은 사용에 관한 리포트를 작성하기 위한 오퍼레이셔널 데이터베이스 및 요금 부과 정보로부터 정보를 모으는 것을 포함한다. 사용통계 리포트는 호출 형태, 적재 형태 및 인구통계정보를 연구하는 데 사용된다. 이러한 리포트는 미래의 생산계획 및 마케팅 입력을 위해 사용된다.
B. 지능망 시스템 요약
MCI 호출 처리 아키텍쳐는 수 개의 주요 구성요소에 의해 건설되었으며, 이러한 구성요소는 MCI 스위치 네트워크, 네트워크 제어 시스템, 확장된 음성 서비스 및 지능 서비스 네트워크 등이 포함된다. 호출 처리는 일련의 다목적 컴퓨터 및 몇 개의 전문화된 처리기에 의해 행해지며, 이것에 의해 MCI 지능망의 기초가 형성된다. 스위치는 제한된 프로그래밍 용량 및 복잡한 인터페이스를 가진 특정 목적 브릿징 스위치이다.
스위치에 새로운 기능의 부가는 매우 어렵고 때로는 불가능하다. MCI 스위치 상의 호출은 800 번호에서처럼 번호 변환이 요구되면 맨 처음에 검증된다. 번호 변환이 요구되면 내부 테이블을 기초로 해서 스위치에서 행해지며, 또는 그러한 요구는 번호 변환 및 착신 번호 중에서 트렁크 ID 및 스위치 ID를 결정하는 소프트웨어를 가진 다목적 컴퓨터인 DAP로 보내어진다. 호출은 ACD로 라우팅되고, 이 곳에서 라이브 오퍼레이터 또는 ARU와 같은 다양한 호출 처리 에이전트로 보내어진다. ACD는 어떠한 그룹의 에이전트가 호출에 책임이 있는지, 그리고 어떠한 에이전트가 호출을 처리할 수 있는 지를 결정하는 ISNAP와 통신한다.
상기 에이전트는 ISN에 의해 제공되는 다양한 서비스를 위한 필수 데이터베이스를 가진 검증 또는 데이터베이스 서버인 네트워크 정보 분배 서비스(NIDS) 서버와 통신함에 의해 수신된 호출을 처리한다. 상기 서버에 의해 호출을 처리함에 의해 호출이 검증되면 그러한 상태를 다시 ACD에 통신한다. ACD는 착신 번호로 다이얼링하고, 입력호출을 착신 번호와 브릿징하고, 다시 스위치로 호출을 해방하기 위해 해방 링크 트렁크(RLT - Release Link Trunk)를 실행시키다. 에이전트는 또한 요금 부과를 위해 요금 부과 상세 정보(BDR)를 생성한다. 호출이 종료되었을 때, 스위치는 전체 요금 부과 정보를 생성하기 위해 후에 대응되는 BDR 정보와 일치되는 오퍼레이션 서비스 기록을 생성한다. 새로이 가치가 부가된 서비스의 부가는 간단하며, 그리고 새로운 기능은 ISP에 있는 소프트웨어 및 다른 계산 시스템의 구성의 부가에 의해 부가될 수 있다. 전형적 호출 흐름의 시나리오는 다음에 설명되어 있다.
C. 호출 흐름의 실시예
호출 흐름의 실시예는 도 19A에 보이는 바와 같이 전화 1에서 10으로의 800 번호 콜렉트 콜의 처리를 설명한다. 이 호출은 피호출자 10으로 콜렉트 콜하기 위해 호출자가 1-800 콜렉트(COLLECT)를 다이얼링함에 의해 개시된다. 상기 호출은 이 번호가 MCI가 소유한 것임을 알고 있는 호출자 지역 벨 오퍼레이팅 회사(RBOC - Calling Party's Regional Bell Operating Company)에 의해 가장 가까운 MCI 교환 설비로 라우팅되어 MCI 스위치 2에 연결된다.
상기 스위치 2는 800 번호 서비스임을 확인하고, 스위치에 있는 참고 테이블로부터 800 번호 변환을 수행하거나, 또는 데이터베이스 룩업을 이용해 번호 변환 서비스를 제공하고 데이터 접속점(DAP) 3을 요구한다.
호출 처리는 자동 호출 분산기 4를 통해 일련의 지능 계산 시스템으로 넘겨진다. 이 실시예에서, 상기 호출이 콜렉트 콜 호출이기 때문에 호출이 더 진행되기 전에 호출자는 수동 또는 자동 오퍼레이터에 도달하여야 한다. 스위치로부터의 호출은 ISNAP 5를 따라 선택적으로 존재하는 ACD 4에 전송된다. ISNAP 5는 어떠한 군의 에이전트가 호출 형태에 따라 호출을 처리할 것인지를 결정한다. 이 작업은 군 선택(group select)라 불린다. 호출을 처리할 수 있는 에이전트는 수동 원격 통신 오퍼레이터 콘숄(MTOC) 6 또는 네트워크 음성 서버(NAS) 7a와 관련된 자동 호출 처리기 (ACP) 7을 포함한다. ISNAP 5는 어떠한 에이전트가 호출을 처리하기 위해 자유로운 지를 결정하고, 음성 호출을 특정한 에이전트에 라우팅 한다. 에이전트는 매우 정교한 호출 처리 소프트웨어로 이루어져 있다. 에이전트는 호출자로부터 피호출자의 전화 번호를 포함하는 모든 관련된 정보를 수집한다. 에이전트는 일련의 데이터베이스 룩업 요구를 하면서 데이터베이스 서버와 통신한다. 데이터베이스 룩업 요구는 호출 형태에 대한 질문, 호출자와 피호출자의 전화 번호에 기초한 호출 검증 및 만약 있다면 호출자와 피호출자의 전화번호에 기초한 호출 블로킹 제한을 포함하는 호출 제한을 포함한다. 그후 에이전트는 ISNA-ACD 조합에 호출자에게 잠시 대기할 것과 피호출자에게 연결하기 위해 다이얼링할 것을 신호한다. 에이전트는 피호출자에게 호출자에 대한 정보 및 콜렉트 콜의 요구에 대한 사실을 알려준다. 에이전트는 피호출자로부터의 응답을 수집하고 호출을 계속 처리해 나간다.
만약 피호출자가 호출을 수신에 동의한다면, 에이전트는 ISNAP-ACD 조합에 호출자와 피호출자를 브릿징할 것을 신호한다. 그리고 나서 에이전트는 완전한 요금 부과정보를 생산하기 위해 스위치에 의해 발생된 개개의 OSR과 일치하는 BDR을 차단한다. 그후 ISNAP-ACD 조합은 호출자와 피호출자를 브릿징하고, RLT를 실행시켜 라인을 스위치로 다시 해방시킨다. 호출자와 피호출자는 스위치를 통해 대화를 주고받는다. 어느 한편에 의한 호출 종료 시에 스위치는 이전에 완전한 호출정보를 생산하기 위해 생성된 BDR과 일치하는 OSR을 생성한다.
만약 피호출자가 콜렉트 콜을 거절한다면, 에이전트는 ACD-ISNAP 조합에 에이전트에 다시 보류되어 있는 호출자를 다시 연결할 것을 신호한다. 마침내 에이전트는 호출자에게 피호출자의 응답을 알리고, BDR을 생성한 후 호출을 종료한다.
MCI 지능망은 호출 처리를 위한 짜임새 있고 효율적인 네트워크 아키텍쳐이며, 전문적 소프트웨어, 특정목적 브릿징 스위치 및 ACD를 가지고 있는 일련의 지능 처리기를 기초로 하고 있다. 지능망은 MCI 교환망과 병존하는 오버레이 망이며, 호출을 처리하기 위하여 교환망과 상호작용하는 수 개의 전문적 처리기로 이루어져 있다. 지능망에 관한 하나의 실시예는 전적으로 음성 지향적이다. 데이터 및 팩스는 몇 가지 전문적이며 전용된 기능과 가치가 부가된 서비스를 사용하여 음성호출로 처리된다.
다른 실시예에서는 지능망은 POTS에 기초한 비디오폰 및 영상 및 음성을 위한 인터넷 전화를 포함하는 새로이 나타나는 기술을 위해 채용되었다. 아래의 단락들은 떠오르는 신기술에 기초한 아키텍쳐, 기능 및 서비스에 대해서 상세히 서술되어 있다.
ISN과 떠오르는 신기술과의 호환성
아래의 단락들은 떠오르는 신기술에 기초한 아키텍쳐, 기능 및 서비스에 대해서 상세히 서술되어 있으며, 그 모두는 지능망에 집적되어 있다.
Ⅶ. ISP 프레임워크
A. 배경
ISP는 몇 개의 이종의 시스템으로 구성되어 있다. ISP 집적이 진행됨에 따라, 이전에는 독립된 시스템이 ISP 모든 분야에서 분석, 테스팅, 스케쥴링 및 트레이닝의 수준에 있어서 부수적 증가와 더불어 더 큰 통합체의 일부분이 되고 있다.
1. 광대역 접속
고 대역폭 서비스의 범위는 바람직한 실시예에 의해 지지된다. 이것은 요구되는 영상, 회의, 원거리 학습 및 원격 의료를 포함한다.
비동기 전송 방식(ATM)은 트렁크 및 전통적 회선에 기초한 전화의 교환 모델을 회피하기 위해 네트워크 제어를 네트워크의 주변으로 밀어낸다. 이 방식은 고 대역폭 서비스를 도모하기 위해 광범위하게 배치될 것으로 예상된다.
2. 인터넷(Internet) 전화 시스템
인터넷(Internet) 및 월드 와이드 웹은 용이한 고객 접속, 광범위한 상업적 기회를 제공하고, 성공적 원격 통신 회사의 역할을 육성한다. ISP 플랫폼은 전화에서 인터넷(Internet)까지 적용될 수 있는 다양한 기능을 제공한다. 상기 기능에는 접속, 고객 장비, 개인적 회계, 요금 부과, 마케팅(및 광고) 데이터 또는 응용함량 및 기본적 전화 서비스가 포함된다.
원격통신 산업은 인터넷(Internet)의 주요한 전송제공자이다. 인터넷(Internet) 고객을 위해 전화 환경에서 다양한 기능을 제공해주는 바람직한 실시예는 최적화되어 있다.
도19F는 인터넷(internet) 바람지한 실시예와 일치하는 전화 시스템의 구성도이다. 수 개의 컴퓨터 1900, 1901, 1902, 1903은 파이어 월 1905 뒤에서 이서넷 또는 다른 네트워크 연결에 의해 인터넷(Internet) 1910에 연결되어 있다. 도메인 이름 시스템 1906은 이름을 인터넷(Internet)에 있는 IP 주소에 맵한다. 요금 부과 1920, 준비 1920, 디렉토리 서비스 1934, 메시지 서비스 1930 및 음성메시지 1932를 위한 개개의 시스템은 통신 링크에 의해 인터넷 1910에 접속된다. 다른 통신 링크는 일련의 장치 1941 -1943에 정보를 통신하기 위해 사용되는 주변 장치 1940과 통신을 촉진하기 위해 사용될 수 있다. 웹서버 1944는 오더 엔트리 시스템 1945를 위해 인터넷(Internet) 1910에 대한 접속을 제공한다.
실시예에서 오더 엔트리 시스템 1945는 주어진 전화번호에서 이름, 주소, 팩스번호, 비서의 번호, 부인의 전화번호, 이메일 번호, IP 주소, 폰메일 주소를 포함한 완전한 프로파일 정보를 생성한다. 이 정보는 네트워크 상에서 그 정보에 접속할 권한이 부여된 모는 사람에게 접속되는 데이터베이스에서 보수 유지된다. 다른 실시예에서, 오더 엔트리 시스템은 유저가 입력한 정보를 보충하기 위해 프로파일에 대한 정보를 제공하는 현존하는 디렉토리 서비스 데이터베이스 1934에 접속하기 위한 웹 인터페이스를 이용한다. 인터넷(Internet) 1910은 게이트웨이 1950을 통해 공중교환망(PSTN) 1960에 결합되어 있다. 바람직한 실시예에 있어서 게이트웨이 1950은 PSTN 1960에 있는 회선 교환 호출 및 인터넷 1910에 있는 몇 개의 엔티티로부터 가상의 연결을 제공한다.
PSTN 1960은 직접 다이얼 입력 1970, 800 번호 처리를 촉진하기 위한 데이터 접속점(DAP) 1972, 및 예를 들면 회사 연결라인을 촉진하기 위한 VNET 처리를 포함한 다양한 시스템을 가지고 있다. 공중 분기 교환(PBX-Public Branch Exchange) 1980은 통신을 촉진하기 위해 통신 링크를 통해 PSTN과 팩스 1981, 전화 1982 및 모뎀 1983과 같은 다양한 컴퓨터 장비 사이에 접속된다. 오퍼레이터 1973은 PSTN 1960 또는 인터넷 1910으로(또는 에서) 입력(또는 출력)되는 호출 또는 회의 호출을 위치시키는 것을 도와주기 위해 호출에 선택적으로 접속될 수 있다.
다양한 서비스가 지능 서비스망(ISN) 1990, 직접 다이얼 계획 1991, 준비 1974, 오더 엔트리 1975, 요금 부과 1976, 디렉토리 서비스 1977, 회의 서비스 1978, 및 허가/인증 서비스 1979에 대한 접속을 포함한 개별적 통신 링크를 통해 PSTN에 접속될 수 있다. 이러한 모든 서비스는 게이트웨이 1950을 통해 PSTN 1960 및 인터넷 1910을 사용해서 그들 스스로 상호 통신할 수 있다. ISN 및 DAP 1972의 기능은 인터넷 1910에 접속된 장치에 의해 이용될 수 있다.
도19G는 바람직한 실시예와 일치하는 우선 접속/라우터의 구성도이다. 우선 접속 라우터(PAR-Prioritizing Access Router)는 인터넷 접속 장치 및 인터넷 프로토콜(IP) 라우터의 기능을 조합하기 위해 고안되었다. 상기 PAR은 필수적인 모뎀 및 PPP/SLIP를 IP로 전환, IP를 PPP/SLIP로 역전환함에 의해 다이얼업 모뎀을 인터넷에 접속이 할 수 있게 한다. PAR은 또한 IP 패킷 신호원/목적지 주소와 UPD 또는 TCP 포트를 분석하며, 각 패킷에 대해서 적절한 출력 네트워크 인터페이스를 선택한다. 최근에, PAR은 다른 네트워크 인터페이스에 보다 특정 네트워크 인터페이스에 목적된 패킷을 우선하여 처리하기 위해 우선 라우팅 기술을 사용한다.
우선 접속/라우터의 고안 목적은 인터넷(internet) 네트워크 상에서 최선 노력 데이터 호출량의 나머지로부터 실시간 호출량을 분리하는 것이다. 인터넷 접속점에서 실시간 및 상호작용하는 멀티미디어 호출량은 실시간 강제가 없는 호출량으로부터 가장 잘 격리되며, 따라서 질 높은 서비스의 제어가 이루어진다. 우선 접속/라우터를 사용하는 과정은 도19G로 참고하여 아래에 기술되어 있다.
우선, 2010에서 컴퓨터는 모뎀을 통해 PAR에 다이얼업 한다. 컴퓨터 모뎀은 데이터 전송 속도 및 모뎀 프로토콜 파라미터를 PAR 모뎀과 교섭한다. 컴퓨터는 공용 교환 전화망(PSTN) 연결 상에서 모뎀간 연결을 사용하는 PAR을 가지고 두 지점간 프로토콜(PPP) 섹션을 설정한다. 컴퓨터는 모뎀 연결을 통하여 PPP 패킷을 PAR에 전송한다. PAR 모뎀 2010은 모뎀에서 호스트 처리기 인터페이스 2080을 통해 PPP 패킷을 PPP에서 IP로 전환하는 처리기 2020으로 전송한다. 모뎀에서 호스트 처리기 인터페이스는 현재 사용되거나 이전에 발명된 어떠한 물리 인터페이스도 사용될 수 있다. 몇 가지 예로는 ISA, EISA, VME, SC부스(bus), MVIP 부스, 메모리 채널 및 TDM 부스 등이 있다. 시분할 다중장치(TDM) 부스와 같은 다중 부스를 사용할 경우 용량을 특정 데이터 흐름에 전용하며, 결정론적 행위를 보존할 수 있기 때문에 몇 가지 이점이 있다.
PPP에서 IP로의 전환 처리기 2020은 PPP 패킷을 IP 패킷으로 전환하고, 처리간(process to process) 인터페이스 2085를 통해서 IP 패킷을 다시 패킷 분류가 2050으로 전송한다. 처리간 인터페이스는 전용 처리기 하드웨어사이의 물리 인터페이스 또는 소프트웨어 인터페이스가 될 수 있다. 처리간 소프트웨어 인터페이스의 예로는 기능 또는 서브루틴 호출, 메시지 대기행렬, 공유 메모리. 직접 메모리 접속(DIA) 및 메일박스 등을 포함한다.
패킷 분류가 2085는 패킷이 어떠한 특정 우선 군에 속하는 지의 여부를 결정한다. 패킷 분류 기는 흐름 명세서 테이블을 보유하고 있으며, 이 흐름 명세서 테이블은:
목적지 IP 주소, 신호원 IP 주소, 조합된 신호원/목적지 IP 주소, 조합된 목적지 IP 주소/UDP 포트, 조합된 목적지 IP 주소/TCP 포트, 조합된 신호원 IP 주소/UDP 포트, 조합된 신호원 IP 주소/TCP 포트, 목적지 IP 주소와 조합된 신호원 IP 주소 및 TCP 또는 UDP 포트, 신호원 IP 주소와 조합된 목적지 IP 주소 및 TCP 또는 UDP 포트, 목적지 IP 주소 및 TCP/UDP 포트와 조합된 신호원 IP 주소 및 TCP 또는 UDP 포트 등에 의해 정의되어 있다.
패킷 분류기는 흐름 명세서 테이블을 패킷에 사용된 IP 주소 및 UDP 또는 TCP 포트와 비교하여 검사한다. 어떠한 매치가 발견된다면, 이 패킷은 우선 흐름으로 분류되고 우선태그가 부착된다. 자원 예약 설전 프로토콜 기술은 패킷 분류기 단계에서 사용될 수 있다.
패킷 분류기 2050은 처리간 인터페이스를 통해 우선태그가 부착된 것과 미부착된 것을 패킷 스케줄러 2060으로 인계한다. 처리간 인터페이스 2090은 처리간 인터페이스 2085와 일치할 필요는 없으나 동일한 것이 유용하다. 패킷 스케줄러 2060은 우선 패킷이 고우선을 받도록 하며, 경쟁하는 최선노력 호출량의 앞의 외부 네트워크 인터페이스에 위치되도록 가중치 대기행렬(Weighed Fair Queuing)과 같은 우선 대기행렬 기술을 사용한다.
패킷 분류기 2060은 패킷을 호스트 처리기에서 주변 부스(bus) 2095를 통해 우선 순위에 따라 외부 네트워크 인터페이스(2010, 2070, 2071, 또는 2072)에 인계한다. 어떠한 수의 외부 네트워크 인터페이스가 사용될 수 있다.
IP 패킷은 비모뎀 인터페이스(2070, 2071, 및 2072)를 통해 PAR에 도달할 수 있다. 이러한 인터페이스의 예로는 이서넷, 고속 이서넷, FDDI, ATM 및 프레임 릴레이 등이 있다. 이러한 패킷은 모뎀 PPP 인터페이스를 통해 도착하는 IP 패킷과 동일한 경로로 진행된다.
우선 흐름 명세서는 제어 처리기 2030을 통해 관리된다. 제어 처리기는 외부 제어 응용프로그램 인터페이스 2040을 통해 외부에 설치된 우선예약을 받아들일 수 있다. 제어기는 허가 제어 절차 및 정책절차에 대항하여 특별 흐름을 위한 우선예약을 검증한다. 그리고 예약이 허가된다면, 처리간 인터페이스 2050을 통해 흐름 명세서는 패킷 분류기 안에 있는 흐름 명세서 테이블에 입력된다. 처리간 인터페이스 2065는 처리간 인터페이스 2085와 동일할 필요는 없으나, 동일한 것이 유용하다.
도20에는 지능 서비스 플랫폼(ISP) 2100을 위한 본 발명에 사용된 아키텍쳐럴 프레임워크가 나타나 있다. ISP 2100 아키텍쳐의 의도는 ISP의 모든 구성요소를 가로질러 지능 서비스를 MCI 네트워크에 준비 및 전송에 대한 통합적 접근을 정의하고자 함이다.
현존하는 통신 네트워크 시스템 각각은 서비스 관리, 자원 관리, 보안, 분산 처리, 네트워크 제어, 또는 운영 지원을 제공하는 고유의 방식이 있다. ISP 2100의 아키텍쳐는 위의 기능을 제공하는 단일의 응집된 아키텍쳐럴 프레임워크를 정의한다. 이 아키텍쳐는 아래의 목적을 성취하고자 한다:
·세계적 용량 발전,
·확장된 미래 서비스의 전달,
·자원의 효율적 사용,
·마케팅 시간의 절약,
·유지보수 및 운영비용 감소,
·평균 생산 질의 상승, 및
·용량을 위 또는 아래로의 확장에 대한 소개.
ISP의 목적 용량은 기본적 다양한 서비스를 위한 기본적 구성의 설치를 제공하는 것이다. 이러한 서비스는 높은 대역폭, 큰 고객 제어 또는 개인적 유연성 및 배우 감소된, 때로는 순간적 준비 사이클 등을 그 특징으로 한다.
3. 용량
ISP 2100은 세계적이며 도처에 산재하고 있다. 세계적으로는, 상기 ISP는 동맹 파트너의 네트워크를 통해 모든 나라에 도달한다. 부문별로는, 유선 또는 유선 접속을 통해 모든 사무 및 주거 장소에 퍼져 있다.
4. 미래의 서비스
상기 기능은 아래의 사항을 전달하기 위해 사용될 수 있다:
·오늘날 보유하고 있는 것을 초과하는 전화 및 메시지 서비스,
·떠오르는 영상 및 멀티미디어 제공
·확장된 개인 네트워크를 포함한 강력한 데이터 서비스, 및
·유저가 서비스에 대한 완전한 제어를 가능케 하는 소프트웨어 및 장비.
ISP 2100에 의해 제공되는 서비스는 광고, 농업, 교육, 오락, 재정, 정치, 법률, 생산, 의학, 네트워크 전송, 부동산, 연구, 소매, 선적, 전기통신, 여행, 전매, 및 다른 목적에 확장될 수 있다.
서비스는:
·주문 가능한 : 고객은 서비스의 제공을 그들의 필요에 맞출 수 있으며,
·고객에 이해 운영되는 : 고객은 서비스의 관리 및 제어를 위해 직접 접속 가능하며,
·소 결합된(loosely coupled) : 서비스는 단지 필요한 경우에만 네트워크 자원을 얻고 획득하며, 고객은 사용한 것에 대해서만 대가를 지불하고, 대역폭은 미리 할당하지 않고 요구되는 경우 가능하며,
·안전하고 비공개적인 : 고객의 프라이버시 및 비밀은 네트워크 세계에서 주요하다. 상업적 거래는 안전하며 비밀이 보장된다. 유저 및 고객은 시별 및 인증되며, 네트워크는 타락되는 것으로부터 보호된다.
B. ISP 아키텍쳐 프레임워크
아래의 단락들은 고객에게 서비스를 제공하는 데 있어서 ISP 플랫폼 2100의 역할에 대해서 기술하고 있다.
ISP 2100은 제공자 네트워크 설비 2102, 공용 네트워크 설비 2104, 및 고객 장비 2106을 포함하는 지능 서비스 하부구조를 통해서 고객에게 서비스를 제공한다. 서비스 하부구조는 종단간 서비스 품질 및 유용성을 보장한다.
아래의 단락들은 ISP 플랫폼 2100과 제공자의 내부 또는 외부의 다양한 외부 시스템의 관계에 대해서 기술하고 있다.
도20의 제공자 구성요소 2108은:
·지능 서비스 2110 - 내부 데이터 통신 네트워크 2102를 포함하며, 서비스 준비, 서비스 전달, 및 서비스 보증을 책임진다. 이것은 ISP의 역할을 대변한다.
·수입관리 2112 - 고객 서비스의 회계를 책임진다.
·네트워크 관리 2114 - 물리 네트워크 2102의 운영 및 발전을 책임진다.
·생산 관리 2116 - 고객 서비스의 생산 및 마케팅을 책임진다.
도20에 묘사된 2100의 외부 엔티티는:
·네트워크 2104 - 이것은 전체 네트워크 연결 및 서비스를 위해 고객에 의해 사용되는 접속 방법을 대변한다. 이것은 제공자의 회선 교환망, 패킷 교환망, 내적 확장 광역망, 인터넷(internet), 제공자의 무선 파트너의 네트워크, 제공자의 세계적 동맹과 지역 파트너 네트워크, 광대역망 뿐만 아니라 이 네트워크에 결합된 고객 구내 장비 2118을 포함한다.
·제3의 서비스 제공자 2120 - 이것은 ISP 2100을 통해 고객에게 서비스를 전달하는 외부 망을 대변한다.
·서비스 전매자 2122 - 이것은 설비 2100을 사용하는 고객을 가진 망을 대변한다.
·세계적 동맹 파트너 2124 - 네트워크와 서비스 하부구조의 공유 설비 및 교환 능력을 가진 망.
C. ISP의 기능적 프레임워크
도21은 ISP 2100의 구성요소를 보다 상세히 보여준다. ISP 2100의 아키텍쳐를 구성하는 일련의 논리적 구성요소가 나타나 있다. 이것들 중의 어느 것도 단 하나의 물리 엔티티가 아니며, 각각은 통상 복수의 장소에서 복수 개로 존재한다. 구성요소는 연속적 지능 서비스 2100 환경을 제공하기 위해 동반 작동한다. 이 환경은 고정된 것은 아니다. 이것은 유용한 새로운 서비스의 부가 및 새로운 기술과의 통합을 할 수 있는 신축성 있게 발전하는 플랫폼으로 계획되어 있다. 플랫폼 구성요소는 내부 분산 처리 하부구조를 포함하는 하나 이상의 네트워크 연결에 의해 링크되어 있다.
ISP 2100의 기능적 구성요소는:
·인바운드(inbound) 및 아웃바운드(outbound) 게이트웨이 2126 - 다른 제공자가 제공하는 서비스에 접속하는 것을 가능하게 하며, 다른 제공자가 제공자의 서비스에 접속할 수 있게 한다.
·매매 가능한 서비스 게이트웨이 2128 - 판매용 3층 서비스 생성 환경에 인터페이스하게 한다. 서비스는 판매 가능한 서비스 게이트웨이를 통해서 배치되고 업데이트된다. 이것은 배치되고 생성된 서비스가 외부 고객용임을 제외하고는 관리 서비스 게이트웨이 2130과 다르지 않다.
·관리 서비스 게이트웨이 2130 - 플랫폼의 관리 및 서비스 논리에 적용되는 서비스 생성 개념을 설명한다. 관리 서비스는 관리 서비스 게이트웨이 2130을 통해서 배치되고 관리된다. 또한 ISP 2100의 외부에 있는 관리 시스템을 가진 인터페이스는 관리 서비스 게이트웨이 2130에 의해서 실현된다. 관리 서비스의 몇 가지 예는 수집, 일시적 저장, 및 네트워크 결과의 전송 등을 포함한다. 다른 서비스는 네트워크 관리 2132로 전송하기 전에 ISP 2100으로부터 경보 정보의 수집 및 필터링을 포함한다.
·서비스 엔진 2132 - 판매 가능하거나 관리 서비스를 위한 서비스 논리 실행 환경. 서비스 엔진 2132는 독특하며 상용화된 서비스 기능을 제공하기 위하여 특정고객 프로파일에 수록된 논리를 실행한다.
·서비스 생성 환경 2136 - 판매용 서비스, 및 잠재된 기능 및 용량뿐만 아니라 관리 서비스를 생성하고 배치한다.
·데이터 관리 2138 - 이곳에서 모든 고객 및 서비스프로파일 데이터가 배치된다. 데이터는 서비스 엔진 2134, 통계서버 2140, 호출 문맥 서버 2142, 분석 서버 2144, 및 ISP 2100 데이터를 요구하는 다른 전문적 응용 또는 서버 2146에서 캐시(cash)된다.
·서비스 선택 2148 - 서비스가 소대역 또는 광대역 네트워크, 회선 교환, 또는 셀 교환을 통해서 접속되는 지의 여부에 관계없이 서비스는 서비스 선택 기능 2148을 통해서 접속된다. 서비스 선택 2148은 실행할 하나 이상의 서비스를 선택하기 위해 특별히 고안된 서비스 엔진 2134의 전문화된 버전이다.
·자원 관리 2150 - 전문화된 자원 2152, 서비스 엔진 2134 상에서 작동하는 서비스 예, 및 관리 및 할당을 요하는 ISP 2100에 존재하는 다른 종류의 자원을 포함한 모든 자원을 관리한다.
·전문화된 자원 2152 - 특정한 네트워크에 기초한 능력(인터넷을 음성 전환, DTMF-검출, 팩스, 음성 인식, 등등)은 전문화된 자원 2152로서 나타난다.
·호출 문맥 서버 2142 - 실시간의 네트워크 결과 기록 및 서비스 결과 기록을 받아들이고, 데이터에 대한 질문을 허가한다. 호출에 대한 모든 결과가 생성되면, 조합된 결과 정보는 전체가 수입 관리 기능 2154로 전송된다. 데이터는 단기간 저장된다.
·통계서버 2140 - 서비스 엔진으로부터 통계 결과를 받아들이고, 룩업을 수행하며, 데이터에 대한 질문을 할 수 있게 한다. 데이터는 단기간 저장된다.
·고객에 기초한 용량 2156 - 고객의 전제를 기초한 능력 예를 들면 ANI 스크리닝, 인터넷 접속, 압축, 상호작용 게임, 영상 회의, 소매 접속 등을 할 수 있게 하는 고객을 전제한 소프트웨어 및 전문화된 하드웨어.
·분석 서비스 2144 - 네트워크 접속에 기초하지 아니하나, 실시간 또는 실시간 근처의 네트워크 통계 또는 호출 문맥 정보에 기초한 가치 부가에 기초하는 특별한 종류의 서비스 엔진. 그 예는 기만 검출 및 고객 호출량 통계 등을 포함한다.
· 다른 특별 서비스 2146 - 서비스 엔진에 기초하거나 기초하지 않는 전문화된 형태의 응용 또는 서버를 수반한다. 이 구성요소는 서비스 전달, 모니터링 또는 관리에 사용될 수 있는 다른 계산 자원 및 저수준의 기능 용량을 제공한다.
D. ISP 집적 네트워크 서비스
도22는 ISP 아키텍쳐 2100이 다른 네트워크를 통해서 서비스를 제공하는 방법을 보여준다. 이 네트워크는 인터넷(Internet) 2160, 공용교환 전화망(PSTN) 2162, Metro 접속 링 2164, 무선 2166 등을 포함한다. 부가적으로 ATM 또는 ISO 이서넷과 같은 새로운 스위치 없는 광대역망 아키텍쳐 2168 및 2170이 현재의 PSTN 네트워크 2162에 대체될 수 있다.
상기 아키텍쳐는 기본적 PSTN 2162 외에도 수 개의 네트워크를 채용하고 있는 바, 이것은 이 교환 가능한 네트워크가 PSTN에 의해서는 제공될 수 없는 서비스를 종종 저렴한 비용구조를 가지고 지원할 수 있기 때문이다. 이러한 네트워크는 도22에 묘사되어 있다.
이 새로운 네트워크 각각은 ISP 2100과 상호작용하도록 계획되어 있다. 호출(또는 트란잭션)은 고객 서비스 요구로부터 네트워크 내에서 발신되며, ISP는 트란잭션을 수신하고, 먼저 고객을 식별하고 트란잭션을 범용 서비스 엔진 2174로 전송함에 의해 서비스를 제공한다. 서비스 엔진은 어떤 서비스 기능이 필요한지를 결정하고 필요한 논리 적용하거나, 또는 필요한 기능을 위한 전문화된 네트워크 자원을 이용한다.
ISP 2100 그 자체는 일련의 자원 관리자 및 관리 및 모니터링 메카니즘의 제어를 받고 있다. 단일의 시스템 상은 공통적 정보 베이스를 동시에 사용함을 통해 가능하게 된다. 정보 베이스는 ISP에 의해 생성되거나 사용되어지는 모든 고객, 서비스, 네트워크 및 자원 정보를 보유하고 있다. 다른 외부 응용장치는 게이트웨이, 중간단계를 통해 접속이 허용되며, 때로는 같은 정보 베이스로 직접적으로 접속된다.
도22에서, 각 엔티티는 ISP의 하나의 논리적 요소를 묘사한다. 이 엔티티 각각은 통상 복수의 장소에서 복수 개로 배치된다.
E. ISP 구성요소
Ext App 2176 - 외부 응용장치:
App 2178 - 내부 ISP 응용장치(기만 분석과 같은):
Dc 2180 - 데이터 클라이언트. 로컬 데이터 복사를 제공하는 ISP 정보 베이스에 대한 클라이언트:
Ds 2182 - 데이터 서버. ISP 정보의 마스터 복사의 하나:
Admin 2184 - ISP 관리 기능 (환경설정 및 유지보수용):
Mon 2186 - ISP 모니터링 기능(실수, 성취, 및 회계용):
GRM 2188 - 선택된 자원에 대한 세계적 자원 관리 개관:
LRM 2190 - 선택된 자원에 대한 로컬 자원 관리 개관:
SR 2192 - 전문화된 자원의 풀(영상 서버, 포트, 음색인식과 같은):
SE 2134 - 필요한 서비스 논리를 실행하는 범용 서비스 엔진: 및
서비스 선택 2194 - 네트워크로부터 제공되는 트란잭션을 처리하는 서비스(서비스 엔진 2134에 의해 작동되는)를 선택하는 기능.
F. 스위치 없는 통신 서비스
스위치 없는 네트워크 2168은 셀교환 또는 패킷교환 기술을 데이터와 멀티미디어 통신 서비스 양자에 응용하기 위해 사용되는 단어이다. 과거에는 회선교환이 시간에 민감한 등시성 음성의 이송을 위한 유일하게 존립하는 기술이다. 지금은 서비스 보장의 질을 제공하는 비동기 전송방식 셀교환 네트워크의 발전에 힘입어, 등시성 및 신속한 데이터 서비스를 제공하는 단일의 네트워크 하부구조가 성취될 수 있다.
스위치 없는 네트워크는 회선 교환 아키텍쳐보다 저비용 모델을 제공할 것으로 예상된다. 그 이유는:
·각 응용장치에 요구되는 대역폭을 정확하게 제공하고, 데이터가 전송되지 아니할 때에는 대역폭을 저장하는 유연성. 최소 56 Kbps 회선 이 자동적으로 모든 호출에 할당되지 아니한다.
·각 네트워크 섹션을 위한 대역폭 요구를 더욱 감소시키는 압축기술에 대한 적응성.
·음성인식 또는 회의와 같은 특별한 DSP 용량에 대한 접속을 위해 아날로그 포트가 제공될 필요성이 없기 때문에 발생하는 전문화된 자원 장비를 위한 저비용.
· 영상회의, 요구에 대한 트레이닝, 원격 전문화, 통합된 영상/음성/전기메일, 및 정보서비스와 같은 스위치 없는 네트워크를 발전된 고 대역폭 서비스에 적용가능성 및 용이한 순응성 등이다.
도23은 바람직한 실시예와 일치하는 스위치 없는 네트워크 2168의 샘플을 설명하고 있다.
G. 제어 원칙
1. 아키텍쳐럴 원칙
이 단락은 아키텍쳐의 토대를 제공하는 아키텍쳐럴 원칙을 열거한다.
서비스 원칙은:
1. 서비스 모델은 새롭고 실존하는 서비스의 연속적 통합을 지원하여야 한다.
2. 서비스는 서비스의 연속적 개관을 제공하는 공통적 서비스 생성 환경(SCE-Service Creation Environment)으로부터 생성된다.
3. 모든 서비스는 공통적 서비스 생성 환경 내에서 실행된다.
4. 모든 서비스는 하나 이상의 서비스 기능으로부터 생성된다.
5. ISP 데이터 서버에 하나의 컴퓨터 프로파일에 저장되어 있는 데이터는 복수 서비스를 파생하기 위해 사용될 수 있다.
6. 서비스 모델은 각 서비스에 대한 서비스 파라미터를 열거 및 실행을 지원하여야 한다. 이 서비스 파라미터는 합쳐졌을 때 각 고객에 적절한 서비스를 제공한다. 서비스 배치는 열거된 서비스 파라미터를 고려하여야 한다.
2. 서비스 기능 원칙
1. 모든 서비스 기능은 하나 이상의 용량의 조합에 의해서 기술된다.
2. 모든 서비스 기능은 정해진 수의 용량에 의해서 정의될 수 있다.
3. 개별적 서비스 기능은 서비스 고안자가 용량에 대한 공통적 이해를 할 수 있도록 하는 표준적 방법을 사용하여 정의될 수 있어야 한다. 각 서비스 기능은 입력, 에러 수, 디스플레이 형태 및 잠재적 서비스 응용을 상세히 기록하여야 한다.
4. 네트워크 전체에 있어서 물리적 엔티티의 상호작용은 서비스 기능의 유저에게 서비스 기능 인터페이스를 통해 보여져서는 안된다.
5. 각 서비스 기능은 단일하고 안정한 외부 인터페이스를 가져야 한다. 인터페이스는 일련의 오페레이션으로 묘사되고, 및 각 오퍼레이션에 의해 요구 및 제공되는 데이터로 묘사된다.
6. 서비스 기능은 스스로 네트워크에 배치되지는 아니한다. 서비스 기능은 서비스 기능을 자극하는 단지 서비스 논리기능 프로그램의 일부로 배치된다(도 21). 따라서 서비스 기능은 서비스 논리 프로그램에 정적으로 링크되어 있으며, 용량은 서비스 논리 프로그램에 동적으로 연결되어 있다. 이 곳에서 서비스에 대한 자원의 소 결합이 이루어진다.
3. 용량 원칙
1. 용량은 어떤 물리 또는 논리 실행의 고려로부터 완전히 독립적으로 정의된다.
2. 각 용량은 단일하고 안정한 인터페이스를 가져야 한다. 인터페이스는 일련의 오페레이션으로 묘사되고, 및 각 오퍼레이션에 의해 요구 및 제공되는 데이터로 묘사된다.
3. 개별적 용량은 서비스 고안자가 용량에 대한 공통적 이해를 할 수 있도록 하는 표준적 방법을 사용하여 정의될 수 있어야 한다. 각 서비스 기능은 입력, 에러 수, 디스플레이 형태 및 잠재적 서비스 응용을 상세히 기록하여야 한다.
4. 네트워크 전체에 있어서 물리적 엔티티의 상호작용은 용량의 유저에게 용량 인터페이스를 통해 보여져서는 안된다.
5. 용량은 고수준의 용량을 형성하기 위해 병합될 수 있다.
6. 용량에 대한 오퍼레이션은 하나의 완전한 활동도를 정의한다. 용량에 대한 오퍼레이션은 하나의 논리적 출발점 및 하나 이상의 논리적 종말점을 가지고 있다.
7. 용량은 네트워크 전체에 있어서 하나 이상의 물리 하드웨어 또는 소프트웨어에 실현될 수 있다.
8. 각 용량 오퍼레이션에 의해 요구되는 데이터는 용량 오퍼레이션 지원 데이터 및 유저 의뢰 데이터 파라미터에 의해서 정의된다.
9. 용량은 어떠한 서비스에 관계없이 네트워크에 배치된다.
10. 용량은 그 속성에 있어서 세계적이며, 서비스 고안자의 논점에서는 전체 네트워크가 하나의 단일한 엔티티로 간주되기 때문에 그 위치는 서비스 고안자에 의해 고려될 필요가 없다.
11. 용량은 재생가능하다. 그들은 다른 서비스에 대한 보완 없이 사용될 수 있다.
4. 서비스 생성, 배치, 및 실행 원칙
1. 각 서비스 엔진 2134는 고객베이스의 일부를 지원한다. 서비스 엔진에 의해 지원되는 고객의 목록은 환경설정 데이터에 의해 파생되고, ISP 데이터 서버 2182에 저장된다.
2. 각 서비스 엔진 2134는 그 환경설정 데이터를 ISP 데이터 서버 2152로부터 활동 시간에 얻는다.
3. 서비스 엔진 2134는 필요한 경우, ISP 서비스 엔진 2134를 위해 환경 설정되어 있으며 고객을 지원하기 위해 필요한 데이터를 임시 저장하기 위해 데이터베이스 클라이언트 2180(데이터 관리 단락을 참조)을 사용한다. 임시저장은 ISP 데이터 서버 2182에 의해 또는 ISP 데이터 서버 2182의 데이터베이스에 의해 제어될 수 있다. 데이터 서버 2182로부터 데이터를 적재할 것이 너무 많은 경우에는, 데이터는 반영구적으로 서비스 엔진 2134(디스크 또는 메모리)에 임시저장 될 수 있다.
4. 서비스 엔진 2134는 모든 고객 서비스 또는 일부의 고객 서비스를 실행할 것으로 예상된다. 그러나 서비스 상호작용의 경우에는, 하나의 서비스 엔진 2134는 항상 서비스의 실행을 제어하여야 한다. 서비스 엔진은 서비스 실행하는 동안 제어를 다른 서비스 엔진에 인계할 수 있다.
5. 서비스 엔진은 데이터, 환경설정 데이터조차도 소유하고 있지 아니하다.
6. 서비스 엔진은 데이터의 배치를 목적으로 하지 아니한다. 데이터 서버 2182가 데이터의 배치를 목적한다.
5. 자원관리 모델 2150 원칙
1. 자원 2152는 네트워크 상의 어느 곳에서도 접근 가능해야 한다.
2. 자원은 서비스에 특정된 것이 아니며 바람직한 모든 서비스에 공유될 수 있다.
3. 같은 형태의 서비스는 하나의 군으로 관리된다.
4. 자원 관리 모델 2152는 최소비용, 라운드 로빈(Round Robin), 최소 사용, 최고 효율, 최신 환경, 고장날 때까지 지속적 사용 및 배타적 사용 등을 포함하는 관리 정책을 채용할 수 있을 정도로 신축성이 있어야 한다.
5. 자원관리 모델 2150은 자원 할당을, 가능하다면 선택된 정책을 존경할 수 있게, 최적화하여야 한다.
6. RM 2150은 트란잭션 토대에 의해 트란잭션에 대한 정적인 환경설정에서 완전히 동적인 자원의 할당에 이르기까지 자원할당기술에 대한 조망을 제시하여야 한다.
7. RM 2150은 자원 고갈, 및 우선권에 의한 선점적 재할당과 같은 자원 사용 정책을 고려하여야 한다.
8. 자원 관리 모델 2150은 자원 풀에서 자원의 상태, 사용 및 건강에 대해서 점검하고 접속할 수 있어야 한다.
9. 모든 자원 2152는 피관리 객체로 취급되어야 한다.
10. 모든 자원은 RM 2150을 사용하여 풀에 들어가기 위해 등록 가능해야 하며, pool을 빠져 나오기 위해 등록말소 가능해야 한다.
11. 자원에 대한 요구, 획득 및 해방을 위한 유일한 방법은 RM 2150을 통해서 일어난다.
12. 자원들 상호간의 관계는 고전된 것이 아니어야 하며, 주어진 자원의 개별적 요구는 필요 및 요구에 대한 응답으로 등록된 풀로부터 할당되어야 한다.
13. 모든 전문화된 자원 2152는 지속적 플랫폼의 개관으로부터 관리 가능해야 한다.
14. 모든 전문화된 자원 2152는 직접 또는 대리를 통해 SNMP 또는 CMIF 에이전트 기능을 제공해야한다.
15. 모든 전문화된 자원 2152는 공통적 관리 정보 베이스로 표현될 수 있어야 한다.
16. 모든 전문화된 자원 2152는 질문, 탐사, 서비스의 외부 또는 내부에 위치시키는, 및 항목을 테스트하는 일련의 표준적 오퍼레이션을 지원하여야 한다.
17. 모든 전문화된 자원 2152는 표준적 SNMP 또는 CMIF 관리 인터페이스를 통해 제어되는 일련의 기본적 자기점검 용량을 제공하여야 한다.
6. 데이터 관리 2138 원칙
1. 어떠한 데이터 명세의 복수 복사가 허용된다.
2. 데이터 명세의 가치의 복수 버전이 가능하나, 하나의 뷰는 마스터로 간주된다.
3. 주어진 명세의 마스터 버전은 단일한 지배하에 있다.
4. 복수 유저가 같은 데이터에 동시에 접속하는 것이 허용된다.
5. 사무 규칙이 모든 데이터 변화의 유효성을 보장하기 위해 ISP 2100에 균일하게 적용되어야 한다.
6. 유저들은 데이터의 로컬 복사 상에서 작업하고, 데이터 접속은 독립적이며 투과적 위치에 있다.
7. 데이터 관리의 논점에서 보면, 유저는 응용장치 또는 다른 소프트웨어의 구성요소이다.
8. 데이터 접속은 ISP 2100을 통해 표준화된 단일한 일련의 방법에 순응하여야 한다.
9. 개인적 데이터는 로컬 데이터 베이스에 위치하나, 공유하거나 분배될 수 없다.
10. 단지 마스터 데이터만이 공유되거나 분배될 수 있다.
11. 공유 데이터 명세에 대한 개인적 포맷은 로컬 데이터베이스에서 허용된다.
12. 트란잭셔널 용량은 사무 규칙 내에서 허용된다면 유저의 자유재량에 의해서 느슨하게 될 수 있다.
13. 규칙에 기초한 논리 및 다른 메타데이터 제어는 정책을 적용할 신축성 있는 수단을 제공한다.
14. 데이터 복제는 데이터 소스의 복제에 의해 신뢰성을 제공한다.
15. 데이터베이스의 분배는 어떤 특정한 데이터 저장 크기를 감소시킴에 의해, 또는 어떤 특정한 데이터 저장에 대한 트란잭션 속도를 감소시킴에 의해 확장성을 제공할 수 있다.
16. 데이터 관리 2138은 데이터 자원의 정적인 환경설정 및 동적인 환경설정 양자를 모두 허용하여야 한다.
17. 공통적 데이터 모델 및 공통적 스키마는 채용되어야 한다.
18. 데이터의 논리적 응용 논점은 파일의 재배치, 데이터베이스의 재로딩, 데이터 저장의 재포맷과 같은 물리적 데이터 오퍼레이션으로부터 단절되어 있다.
19. 감사 추적 및 사건 역사는 적절한 문제점의 해결을 위해 요구된다.
20. 온라인 데이터 감사 및 조정은 데이터 보전을 위해 요구된다.
21. 실패된 데이터베이스의 데이터 복구는 실시간에 필요하다.
22. 데이터 매트릭스는 모니터링, 트렌딩 및 제어 목적을 위해 요구된다.
23. 99.9999 가동률을 가진 7 by 24 오퍼레이션이 요구된다.
24. 데이터 관리 2138 메카니즘은 고수준의 성장을 위해 확장가능해야 한다.
25. 데이터 관리 2138 메카니즘은 대규모 및 소규모 양자 모두에 비용이 효율적인 해결책을 제공하여야 한다.
26. 데이터 관리 2138 메카니즘은 자비롭게 다중부여 상황을 취급하여야 한다.
27. 데이터 취급 및 데이터 동시성은 우리의 사무 필요를 충족시키기 위해 일어나야 한다.
28. 신뢰성 있는 오더 엔트리 및 서비스 생성은 가능한 경우에는 언제나 중간 응용장치가 아닌 ISP 데이터베이스를 통해 일어나야 한다.
29. 모든 데이터는 보호되어야 하며, 부가적으로 고객 데이터는 비밀이 유지되고 신뢰성 있게 보유되어져야 한다.
30. 환경설정, 오퍼레이셔널 세팅 및 작동시간 매개 파라미터는 ISP 관리 정보 베이스(MIB)에서 마스터된다.
31. 가능한 경우에는 언제나 규격화된 데이터 해결책이 데이터 관리 필요를 만족시키기 위하여 사용되어야 한다.
아래의 원칙은 객체 지향적 논점에서 기술되어 있다.
32. 데이터 항목은 가장 낮은 일련의 지속적 객체이다. 이 객체는 하나의 데이터 값을 싸고 있다.
33. 데이터 항목은 유저가 정의한 형태를 가질 수 있다.
34. 데이터 항목은 생성되거나 삭제될 수 있다.
35. 데이터 항목은 단지 하나의 읽기 및 설정 방법을 가지고 있다.
36. 데이터 명세의 내부적 값은 범위 제한 및 규칙에 의해서 강제된다.
37. 무가치의 상태에 있는 데이터 항목은 유저에 의해 접속되지 아니하여야 한다.
7. 오퍼레이셔널 지원 원칙
1. 공통적 뷰(view) - 모든 ISP 2100 오퍼레이셔널 지원 유저 인터페이스는 같은 룩 엔드 필(look and feel)을 가져야 한다.
2. 기능적 공통성 - ISP 오퍼레이셔널 지원 환경 전체에 걸쳐 객체의 관리는 같은 방식으로 표현된다.
3. 하나의 뷰 - 하나의 분산 피관리 객체는 ISP 오퍼레이셔널 지원 유저 인터페이스에서 하나로 표현되며 분산은 자동적이다.
4. OS/DM 도메인 - 오퍼레이셔널 지원 도메인 내에 있는 데이터는 ISP 데이터 관리 2138 메카니즘에 의해 관리되어야 한다.
5. 전역 MIB - 전체 ISP에서 자원을 표현하는 논리적 전역 MIB가 있다.
6. 외부 MIB - 관리 대상 구성요소의 일부분인 내장형 MIB는 오퍼레이셔널 지원 및 데이터 관리의 외부에 있다.
7. 시스템 구조 - ISP OS 표준에 대한 시스템 구조는 중개 층을 통해 확보될 수 있다.
8. 운영 기능 - 운영 부문은 물리 및 논리 자원을 위해 네트워크 층 및 요소 관리를 취급한다.
9. 관리 기능 - 관리 부문은 계획 및 서비스 관리를 취급한다.
10. 프로파일 도메인 - 서비스 및 고객 프로파일 데이터베이스는 데이터 관리 시스템의 도메인 하에서 관리 부문에 의해서 관리된다.
11. 통신 관리망(TMN - Telecommunication Management Network) 컴플라이언스(compliance) - TMN 컴플라이언스는 게이트웨이를 통해서 TMN 시스템에 실현될 수 있다.
12. 동시성 - 다중 오퍼레이터 및 관리자는 ISP OS 인터페이스로부터 동시에 오퍼레이션을 수행할 수 있어야 한다.
8. 물리 모델 원칙
1. 호환성 - 물리 네트워크 모델은 현존하는 통신 하드웨어 및 소프트웨어에 대한 호환성을 거꾸로 제공해준다.
2. 확장성 - 물리 네트워크 모델은 광범위한 고객 인구 및 서비스 요구에 부응할 수 있게 확장 가능하다.
3. 중복성 - 물리 네트워크 모델은 두 네트워크 요소를 통한 정보 흐름을 위해 복수개의 정보 경로를 제공한다. 한 점에서의 실패는 무시될 수 있다.
4. 투과성 - 네트워크 요소는 네트워크 중복 아래로 투과 가능하다. 실패한 경우에는 중복 링크로의 교체는 자동적이다.
5. 관용적 성능 저하 - 물리 네트워크 모델은 복수의 네트워크 고장의 경우에 용량의 단계적 감소에 의해 유용한 정보를 제공할 수 있다.
6. 상호운용성 - 물리 네트워크 모델은 다른 특성을 가진 네트워크가 다른 네트워크 요소와 상호 운용 가능하게 한다.
7. 안전성 - 물리 네트워크 모델은 정보의 안전한 전송을 요구 및 전송한다. 그리고 네트워크 요소에 안전한 접속을 보증하는 능력을 가지고 있다.
8. 모니터링 - 물리 네트워크 모델은 네트워크 상의 호출량을 모니터링하기 위해 잘 정의된 인터페이스 및 접속 방법을 제공한다. 상기 언급한 안전은 민감한 데이터에 권한 없는 자의 접속을 방어함에 의해 완전하게 된다.
9. 분배 가능성 -물리 네트워크 모델은 고립된 관리 도메인을 형성하기 위해 분할 가능하다.
10. 서비스 품질 - 물리 네트워크 모델은 범용의 서비스. 적절한 서비스 및 유저 선택적 서비스 등과 같은 서비스 품질을 제공한다.
11. 세계적 접속 - 물리 네트워크 모델은 네트워크 상에서의 위치 때문에 네트워크 요소에 대한 접속을 방해하지 아니한다.
12. 조절 인식 - 물리 네트워크 모델은 조절 환경에 있어서의 갑작스러운 변화에 순응할 수 있다.
13. 비용의 효율성 - 물리 네트워크 모델은 하나의 벤더 플랫폼 또는 특정 표준의 기능에 의존하지 아니함으로써 비용이 효율적인 장치가 가능하게 한다.
H. ISP 서비스 모델
이 단락은 ISP 아키텍쳐 프레임워크의 서비스 모델을 기술한다.
1. 목적
ISP 서비스 모델은 아래의 서비스를 지원하기 위해 프레임워크를 확립한다.
·빠른 서비스 생성 및 배치.
·효율적 서비스 실행.
·고객을 위한 서비스의 완전한 상용 제어.
·고객을 위한 연속적 서비스 개관을 전체 서비스 통합.
·용량의 소결합을 통한 ISP 용량의 개선된 재사용.
·서비스 장치의 감소된 비용.
·벤더 독립성.
2. 작용 범위
ISP 서비스 모델은 아래의 사항을 포함한 서비스와 관련된 모든 활동을 지원한다.
·준비
·생성
·배치
·명령
·업데이팅
·모니터링
·실행
·테스팅 또는 시뮬레이션
·고객 지원 및 장해 추적
·요금 부과
·장애 티켓 취급
·운영 지원
이 모델은 판매 가능한 서비스 및 관리 서비스를 포함한다.
·판매 가능하다 서비스 우리의 고객에 의해 구입되는 서비스이다.
·관리 서비스는 MCI 네트워크의 운영의 일부이며 고객에 판매되지 아니한다.
서비스 모델은 또한 ISP 아키텍쳐의 다른 부분과의 데이터 관리, 자원 관리 및 운영지원을 포함한 상호작용을 정의한다.
3. 서비스 모델 개관
서비스 2200의 전달이 ISP의 중앙에 위치해있다(도24). 돈을 벌기 위한 통신 서비스 제공자의 능력에 있어서 서비스는 가장 중요한 논점이다. 다음의 서비스의 정의는 이 서비스 모델 전체에 걸쳐 사용된다. 서비스는 공표된 인터페이스를 통해 접속했을 때 유저를 위해 바람직하고 예상되는 결과를 야기하는 잘 정의된 논리 구조와 사무 처리를 조합한 일련의 용량이다.
서비스 2200과 응용장치 2176 또는 2178의 가장 주요한 차이점은 서비스 2200은 판매, 운영 및 서비스의 유지보수를 지원하는 사무 처리를 포함한다는 것이다. 서비스를 발전시키는 핵심적 과제는 자동화될 수 있는 것을 정의하고 인간이 서비스와 어떻게 상호작용하는 지를 명백히 밝히는 것이다.
4. 서비스 구조
서비스를 기술하기 위해 사용하는 어휘는 서비스 그 자체, 서비스 기능 및 용량을 포함한다. 이 구조는 도24에 보이는 바와 같이 3층의 구조로 되어 있다.
서비스 2200은 전술한 바와 같이 객체 지향적 객체의 면에서는 객체이다. 서비스 2200은 서비스 기능 2202라 불리는 다른 객체를 함유하고 있다. 서비스 기능 2202는 서비스를 위해 ISP 프레임워크에서 하나이상의 용량 2204의 제어된 상호작용을 이끌어내는 잘 정의된 인터페이스를 제공한다.
서비스 기능 2202는 차례로 다양한 용량 2204 객체를 사용한다. 용량 2204는 서비스 기능 2202를 생성하기 위해 사용되는 표준적이며, 재사용 가능한 광네트워크 빌딩 블록이다. 서비스 생성에 있어서 주요한 조건은 기본적 용량 객체를 생성하는 엔지니어가 그 각각이 많은 다른 필요한 서비스에 재사용 가능하다는 것을 보증하는 것이다.
a) 서비스 2200
서비스 2200은 기본적으로 매우 고수준의 프로그램 언어로 씌어진 프로그램인 서비스 논리로 기술된다. 또는 그래픽 유저 인터페이스를 사용하는 것으로 기술된다. 이 서비스 논리 프로그램은:
·어떠한 서비스 기능 2202가 사용되는 지의 여부,
·서비스 기능이 발동되는 순서,
·입력 서비스 데이터의 출처,
·출력 서비스 데이터의 목적지,
·에러 값 및 에러의 취급,
·다른 서비스 2200의 발동,
·다른 서비스와의 상호 작용, 및
·다른 서비스와의 상호 작용 등을 식별한다.
서비스 논리 그 자체는 통상 네트워크에서 서비스 2200을 실행시키기에 충분하지 아니하다. 일반적으로 고객 데이터는 유연성의 논점을 위하여 수치를 정의될 것, 또는 고객의 특별한 요구를 위해 서비스를 상용화하는 것을 요한다. 관리 및 판매용 서비스는 같은 서비스 모델의 부분이다. 관리 및 판매용 데이터의 유사성은 용량의 공유를 허용한다. 관리 및 판매용 데이터는 동일한 네트워크의 두 가지 논점을 대변한다. 즉 관리 서비스는 네트워크의 오퍼레이셔널 논점을 대변하고, 판매용 서비스는 네트워크의 외부 고객 또는 유저 논점을 대변한다. 양 서비스는 공통으로 보존되는 네트워크 데이터에 의존하다. 모든 판매용 서비스는 고객이 서비스 주문, 요금 부과 메카니즘, 다른 운영지원 용량, 및 서비스 모니터링 용량을 위한 수단을 가지고 있다. 관리 서비스는 플랫폼의 유지보수를 위한 처리 및 지원 용량을 제공한다.
b) 서비스 기능 2202
서비스 기능 2202는 잘 정의된 기능 호출의 인터페이스를 제공한다. 용량 2204가 많은 다른 서비스 기능 2202에서 재사용될 수 있는 것처럼, 서비스 기능은 많은 다른 서비스 2200에서 재사용될 수 있다. 서비스 기능 2202는 아래층의 용량의 데이터 입력 조건에서 파생되는 특정한 데이터 입력 조건을 가지고 있다. 서비스 기능의 데이터 출력 방식은 아래층의 용량으로부터 가동되는 데이터에 기초하여 서비스 기능의 작성기에 의해 정의된다. 서비스 기능 2202는 물리 자원의 존재 여부에는 의존하지 아니하나, 도25에서 보이는 바와 같이, 용량 2204에는 의존한다.
서비스 기능의 예로는:
·시간에 기초한 라우팅 - 캘린더, 데이트/시간, 및 호출 객체와 같은 용량에 기초하여, 이 기능은 시간에 기초한 서로 다른 위치에 대한 라우팅이 가능하게 한다.
·인증 - 비교 및 데이터 룩업과 같은 용량에 기초하여, 이 기능은 카드 번호 및/또는 접속 번호의 입력촉진에 의해 호출 카드 사용에 대한 타당성을 검사하기 위해 사용될 수 있다. 또한 이 기능은 가상의 구내망에 대한 접속을 검사하기 위해 사용될 수 있다.
·자동적 유저 상호 작용 - 음성 객체(음성의 기록 및 재생을 위한), 호출 객체(특별한 자원에 호출을 전송 및 브릿징하기 위한), DTMP 객체(DTMP 디지트의 수집 및 아웃펄싱(outpulsing)을 위한), 어휘 객체(연설 인식과 함께 사용하기 위한)와 같은 용량에 기초하여, 이 기능은 서비스의 유저와 자동적 상호작용을 허용할 수 있다. 이 서비스 기능 객체는 유저와의 영상 상호작용을 위한 용량을 포함하기 위해 확장될 수 있다.
c) 용량 2204
용량 2204는 용량이 내적, 전용 상태 데이터 및 생성, 삭제, 및 용량의 사용예를 위한 잘 정의된 인터페이스를 가지고 있음을 뜻하는 객체이다. 용량 2204의 촉진은 그 인터페이스 운영 중의 하나를 촉진시킴에 의해 행해진다. 용량 2204는 재사용을 위해 설치되었다. 따라서 용량은 입력 및 출력 구조를 위한 명확히 정의된 데이터 요구 조건을 가지고 있다. 또한 용량은 명확히 정의된 에러 취급 루틴을 가지고 있다. 용량은 객체 지향적 계층 구조 내에서 정의될 수 있으며, 그 결과로 범용 용량은 다른 몇 개의 용량에 의해 계승되어질 수 있다.
네트워크에 기초한 용량 객체의 몇몇 예는:
·음성(기록 및 재생을 위한),
·호출(브릿징, 전송, 전달, 다이얼 아웃, 등을 위한),
· DTMF(호출 및 아웃펄싱을 위한), 및
·팩스(수신, 송신, 또는 방송을 위한) 등이 있다.
몇몇 용량은 네트워크에 기초해 있으며, 몇몇은 우리 플랫폼에 배치된 데이터에 전적으로 의존해 있다. 이러한 용량의 예로는:
·캘린더(날짜가 언제인지를 결정하기 위한),
·대조(디지트 또는 문자를 대조하기 위한),
·변환(데이터 형태를 교환 가능한 포맷으로 변환하기 위한). 및
·분산(퍼센트 분산에 기초한 결과를 선택하기 위한) 등이 있다.
d) 서비스 데이터
서비스가 실행되는 동안 데이터에 대한 3가지 출처가 있는 바:
·주어진 서비스 촉진을 위한 디폴트값을 포함하는 서비스 템플릿(template)에 정의된 정적인 데이터,
·명백한 유저 입력 또는 내장된 네트워크 연결에서 파생되며, 서비스가 실행됨에 따라 얻어지는 대화형 데이터, 및
·서비스가 요구될 때(예: 생성시간) 고객 또는 그 대표자에 의해 정의되는 유저 프로파일에 정의된 고객 데이터 등이다.
5. 서비스 2200 실행
서비스 2200은 서비스 논리 실행 환경(SLEE - Service Logic Execution Environment)내에서 실행된다. SLEE는 실행 가능한 소프트웨어로써, ISP 2100에 배치된 어떠한 서비스도 실행시킬 수 있다. 서비스 엔진 2134는 이 실행환경을 제공한다. 서비스 엔진 2134는 서비스 엔진에 배치된 서비스를 단순히 실행시킨다.
서비스 템플릿 및 지원 프로파일은 데이터베이스 서버 2182 상에 배치된다(도22). SLEE가 서비스엔진 2134 상에서 실행될 때, SLEE는 데이터베이스 서버 2182로부터 그 구성을 검색한다. 그 구성은 SLEE가 서비스 2200의 목록을 실행하도록 지시한다. 이러한 서비스를 위한 소프트웨어는 데이터베이스 서버 2182 상에 배치된 서비스 템플릿의 일부분이다. 만약 소프트웨어가 서비스 엔진 2134상에서 준비가 되어 있지 아니하다면, 소프트웨어는 데이터베이스 서버 2192로부터 검색된다. 소프트웨어는 실행되고 서비스 2200은 작동되기 시작한다.
대부분의 경우, 서비스 2200은 서비스 기능2202를 먼저 자극하며(도24). 그것에 의해 서비스가 그 자체를 자원 관리자 2188 또는 2190에 등록되도록 한다. 등록되면, 서비스는 트란잭션을 수용하기 시작한다. 그 후, 서비스 2200은 개시작용을 기다리고 있는 서비스 기능 2202를 자극한다. 이 작용은 인터넷 로그 온에서 800 호출 또는 판매 카드 검사 데이터 트란잭션에 이르기까지 어느 것이라도 상관없다. 네트워크에서 개시작용이 발생한다면, 서비스 선택기능 2148은 자원 관리자 기능 2150을 사용하여 실행되고 있는 서비스의 경우를 발견한다. 개시작용은 서비스 2200 경우에 전달되고, 서비스 논리(서비스 템플릿으로부터)는 부가적 서비스 기능 2202를 자극함에 의해 연속적 작용을 결정한다.
서비스 2200이 실행되고 있는 동안, 프로파일 데이터는 서비스 기능 2202의 행동을 결정하기 위해 사용된다. 서비스 성능의 요구 조건에 따라, 서비스 필요한 몇몇 또는 전체 프로파일 데이터는 고가의 원거리 데이터베이스 룩업을 방지하기 위해 ISP 2100 데이터베이스 서버 2182로부터 서비스엔진 2134에 임시 저장될 수 있다. 서비스가 실행됨에 따라, 정보는 서비스 기능 2202에 의해 생성될 수 있으며 문맥 데이터베이스에 저장된다. 이 정보는 네트워크 트란잭션 식별기에 의해 유일하게 식별된다. 회선 교환 호출에 있어서, 미리 정의된 네트워크 호출 식별기는 트란잭션 식별기로 사용될 수 있다. 부가적 정보는 네트워크 장비에 의해 생성될 수 있으며, 문맥 데이터베이스에 저장되며, 또한 같은 트란잭션 식별기에 의해 색인된다. 트란잭션과 관련된 마지막 네트워크 요소는 트란잭션 정보의 말단을 문맥 데이터베이스에 저장한다. 링크된 목록 전략은 특정한 트란잭션을 위한 모든 정보가 문맥 데이터베이스에 저장된 때를 결정하기 위해 사용된다. 모든 정보가 도착하면, 하나의 사상이 그런 종류의 사상에 동의한 서비스에 생성되고, 서비스는 문맥 데이터베이스에 있는 데이터 상에서 운영된다. 이러한 운영은 문맥 데이터베이스에서 데이터를 추출하고, 이것을 요금 부과 시스템 또는 기만 분석 시스템에 전달하는 것을 포함한다.
6. 서비스 상호작용
네트워크 트란잭션에 있어서, 하나 이상의 서비스가 네트워크에 의해서 자극될 수 있다. 때로는 하나의 서비스의 지시가 다른 서비스의 지시와 경쟁할 수 있다. 그러한 경쟁의 예로는 VNET 호출자가 호출자에게 허용되지 아니하는 국제적 호출을 하는 서비스를 요청하는 것이다. VNET 호출자는 국제적 호출이 허용되는 다른 VNET 유저의 번호를 다이얼하고, 피호출 VNET 유저는 국제적 호출을 받아들일 경우에는 호출을 브릿징한다. 최초의 호출자는 제 3자에게 국제적 호출을 할 수 있으며, 그의 회사가 국제적 호출을 허용하지 아니하는 것에 구애되지 아니한다. 이런 상황에서는 국제적 호출을 브릿징할 지의 여부를 결정하기 위해 두 서비스를 상호작용하도록 하는 것이 필요하다.
ISP 서비스 모델은 서비스 2200이 다른 서비스와 상호작용할 수 있도록 하여야 한다. 서비스 2200이 다른 서비스와 상호작용하는 방법에는 몇 가지가 있다:
·제어 2210의 전송: 이곳에서 서비스는 그 실행경로를 끝내고 제어를 다른 서비스에 전송하며,
·동시적 상호작용 2212: 이곳에서 서비스는 다른 서비스를 자극하고 응답을 기다리며,
·비동기 상호작용: 이곳에서 서비스는 다른 서비스를 자극하고, 또 다른 작용을 수행하고, 그리고 나서 다른 서비스가 완료 및 응답하기를 기다리며, 및
·단방향 상호작용 2216: 이곳에서 서비스는 다른 서비스를 자극하나 응답을 기다리지는 아니한다.
상기 상호작용 VNET 서비스의 예에서, 착신 VNET 서비스는 동시적 서비스 상호작용 용량을 사용하여 발신 VNET 서비스에 질문을 할 수 있다. 이러한 흥미 있는 꼬임은 서비스 논리가 네트워크에 기초한 플랫폼 및 고객 구내 장비 상에 다같이 배치될 수 있기 때문이다. 이것은 서비스 상호작용이 네트워크에 기초한 서비스 및 고객을 기초한 서비스 사이에서 일어나야 함을 의미한다.
7. 서비스 모니터링
서비스 2200은 고객 및 네트워크 양자에 의해 모니터링 되어야 한다. 모니터링은 아래의 두 가지 중 어느 하나에 의해 일어난다:
·서비스 2200은 트란잭션 문맥 데이터베이스에 전달하기 위해 상세한 사상 연쇄 정보를 생성할 수 있다.
·서비스 2200은 통계 데이터베이스에 주기적으로 전달하기 위해, 또는 통계 데이터베이스에 의해 요구되는 즉시 검색하기 위해 통계 정보를 생성할 수 있다.
분석 서비스는 실시간 또는 근실시간 데이터 분석 서비스를 수행하기 위해 통계데이터베이스 또는 문맥 데이터베이스를 사용할 수 있다.
문맥 데이터서비스는 네트워크 트란잭션과 관련된 모든 사상 정보를 수집한다. 이 정보는 네트워크 고장해소, 요금 부과, 또는 네트워크 모니터링 등을 위해 필요한 모든 정보를 구성한다.
I. ISP 데이터 관리 모델
이 단락은 ISP 2100 목표 아키텍쳐의 논점에서 데이터 관리 2138을 기술한다.
1. 범위
ISP 데이터 관리 2138 아키텍쳐는 ISP 경계를 가로지르는 정보의 전송을 포함하며, ISP 생성 환경 내에서 생성, 유지보수 및 데이터의 사용을 다루는 모델을 설립하기 위해 의도되었다.
데이터 관리 2138 아키텍쳐는 모든 영구적 데이터, ISP 내에서의 데이터의 복사와 흐름 및 ISP 경계를 통한 정보의 흐름을 다룬다. 이 모델은 데이터 접속, 데이터 분할, 데이터 안전, 데이터 통합, 데이터 조작 및 데이트베이스 관리에 대한 목록을 정의한다. 이것은 또한 필요한 경우 관리 정책을 개괄한다.
2. 목적
이 아키텍쳐의 목적은:
·데이터관리를 위한 공통 ISP 기능 모델을 생성하는 것,
·응용장치에서 데이터를 고립하는 것,
·데이터 시스템의 고안을 위한 파트너를 설립하는 것,
·시스템 배치에 대한 규칙을 제공하는 것,
·미래 기술 및 선택을 안내하는 것, 및
·중복 개발 및 중복 데이터 저장을 감소시키는 것 등이다.
목표 아키텍쳐의 부가적 목적은:
·데이터 유연성을 보장하는 것,
·데이터 공유를 촉진시키는 것,
·ISP 데이터 제어 및 통합을 실시하는 것,
·데이터 안전 및 보호를 설립하는 것,
·데이터 접속 및 사용을 가능하게 하는 것,
·높은 데이터 성능 및 신뢰를 제공하는 것,
·데이터 분할을 충족시키는 것, 및
·운영의 단순화를 성취하는 것 등이다.
3. 데이터 관리 개요
하나의 실시예에서, 데이터 관리 아키텍쳐는 다양한 시스템 구성요소, 시스템이 상호작용하는 방법 및 각 구성요소의 예상 행동을 기술하는 프레임워크이다. 이 실시예에서 데이터는 복수 위치에서 동시에 저장되나, 데이터 및 그 복제된 카피는 논리적으로 하나의 명세인 것처럼 보인다. 이 실시예에서 주요한 차이점은 유저가 어떠한 데이터가 다운로드되고 저장될 것인지를 명령한다는 것이다.
a) 도메인
데이터 및 데이터 접속은 도27에서 보이는 바와 같이 2220 및 2222 두 도메인에 의해서 특징 지워진다. 각 도메인은 그 내부에 복수개의 데이터 카피를 가질 수 있다. 또한, 도메인은 국제적 경계로 확장할 수 있는 하나의 논리적, 세계적 데이터베이스를 생성한다. 도메인 정의에 관한 주요한 논점은 모든 데이터 접속이 동일하다는 것이다. 호출 처리 룩업 또는 네트워크 사이드 데이터 업데이트로부터 공급되는 오더 엔트리에 있어서 차이점이 없다.
중앙 도메인 2220은 시스템의 통합을 제어 및 보호한다. 이것은 단지 논리적 묘사이지 물리적 엔티티가 아니다. 주변 도메인 2222는 유저 접속을 제공하고 용량을 업데이트한다. 이것은 단지 논리적 묘사이지 물리적 엔티티가 아니다.
b) 분할
통상 데이터는 복수 위치에서 동시적으로 저장된다. 데이터 및 그 복제된 카피는 논리적으로 하나의 명세인 것처럼 보인다. 이 카피들 중에서 어떠한 것도 물리 서브세트에 분할될 수 있으며, 따라서 모든 데이터 항목이 하나의 사이트에서 필요한 것은 아니다. 그러나 분할은 단지 하나의 단일한 데이터베이스의 논리적 개관을 유지한다.
c) 아키텍쳐
이 아키텍쳐는 아래의 기능을 가진 분산 데이터베이스 및 분산 데이터 접속의 아키텍쳐이다:
·복제 및 동기,
·데이터 파일의 분할,
·동시 제어,
·트란잭셔널 용량, 및
·공유된 공통 스키마.
도28은 논리적 시스템 구성요소 및 고수준의 정보흐름을 보여준다. 기술된 구성요소 중에서 어느 하나도 물리 엔티티는 아니다. 각각의 복수 경우가 아키텍쳐에서 일어난다. 도28의 요소는:
·네트워크 2224 - 네트워크 측에서의 ISP 2100에 대한 외부접속,
·SVC I/F 2226 - ISP로의 네트워크 인터페이스,
·시스템 2228 - 오더 엔트리와 같은 외부 응용장치,
·G/W 2230 - 외부 응용장치를 위한 ISP에 대한 게이트웨이,
·dbAppl 2232 - 데이터 접속 및 업데이트 용량을 요구하는 롤(roll),
·db클라이언트 2234 - 주변 도메인에 대한 제1의 롤,
·db서버 2236 - 중앙 도메인에 대한 제1의 롤,
·dbAdmin 2238 - 데이터에 대한 관리 롤,
·dbMon 2240 - 모니터링 롤,
·I/F Admin 2242 - 인터페이스에 대한 관리 롤, 및
·Ops 2244 - 운영 콘숄.
d) 정보 흐름
도28에 기술된 흐름은 논리적 추출이다. 그들은 논리적 구성요소 사이를 넘나드는 정보 형태의 특징을 구체화하고 있다. 그 흐름에는:
·요구 - 외부 시스템으로부터 ISP에 대한 데이터 요구,
·응답 - ISP로부터 외부 요구에 대한 응답,
·접속 - ISP 내부의 응용장치에 의한 데이터 검색,
·업데이트 - ISP 내부의 응용장치에 의한 데이터 업데이트,
·Evts - 모니터에 보내어지는 데이터에 관련된 사상,
·Meas - 모니터에 보내어지는 데이터에 관련된 메트릭스,
·새 데이터 - ISP 마스터 데이터에 부가,
·Changed Data - ISP 마스터 데이터를 변화시키는 것,
·뷰 - ISP 마스터 데이터를 검색하는 것,
·subscription - ISP 마스터 데이터의 비동기 스트림,
·캐시 카피 - ISP 마스터 데이터의 스냅샷(snapshot) 카피,
·실행 - 어떠한 제어 활동, 및
·제어 - 어떠한 제어 데이터 등이 있다.
e) 도메인 조합
데이터 관리 2138의 주변 도메인 2222는 통상:
·ISP 응용장치,
·외부 시스템,
·네트워크 인터페이스 2226 및 시스템 게이트웨이 2230, 및
·데이터베이스 클라이언트(dbClient) 2234 등을 포함한다.
데이터 관리 2138을 위한 중앙 도메인은 통상:
·모니터링(dbMon) 2240,
·관리(dbAdmin) 2238, 및
·데이터베이스 마스터(dbServer) 2236 등을 포함한다.
4. 논리적 기술
각 아키텍쳐 구성요소의 기능은 아래에 개별적으로 기술되어 있다.
a) 데이터 응용장치(dbAppl) 2232
이것은 데이터베이스 접속을 요하는 어떠한 ISP 응용장치도 포함한다. 그 예로는 ISN NIDS 서버 및 DAP 트란잭션 서버 등이 있다. 상기 응용장치는 요구되는 데이터베이스에 접속하고, 어떤 요구되는 정책 명령을 제공함에 의해 데이터베이스 클라이언트 2234로부터 요구되는 데이터를 얻는다. 이 응용장치는 또한 오더 엔트리 또는 스위치 요구 변환과 같은 외부 시스템 또는 네트워크 요소를 위하여 데이터베이스 접속을 제공한다.
데이터 응용장치는 아래의 기능을 지원한다:
·업데이트: 응용장치가 ISP 데이터베이스에서 데이터를 삽입, 업데이트 또는 삭제하게 하는 것,
·접속 요구: 접속 요구는 응용장치가 데이터를 검색, 복수 항목을 목록화, 목록에서 항목을 선택 또는 일련의 절차를 반복하게 하며, 및
·사상 및 측정: 사상 및 측정은 모니터링 기능 2240에 지향된 업데이트의 특수한 형태이다.
b) 데이터 측정 2138
(1) 클라이언트 데이터베이스 2234
클라이언트 데이터베이스는 데이터의 주변 복사를 대변한다. 이것은 응용장치가 ISP 데이터에 접속하는 유일한 방식이다. 주변 복사는 데이터베이스 서버 2236에 저장된 것처럼 데이터의 포맷과 일치할 필요는 없다.
클라이언트 데이터베이스는 데이터의 가입 또는 캐시 복사를 위해 마스터 데이터베이스 2236에 저장된다. 가입은 자동적으로 데이터베이스 서버 2236에 의해 유지 보수되나, 캐시복사는 버전이 쓸모 없게 된 경우 새로 공급되어야 한다.
클라이언트 데이터베이스의 주요한 논점은 응용장치에 의한 데이터 업데이트는 연속적으로 나열되고 데이터베이스 서버 2236에 의해 보유되는 마스터 카피와 동기되는 것을 보장하는 것이다. 그러나 클라이언트 데이터베이스가 상기 업데이트된 것을 받아들이고 단지 후에 그 변화를 데이터베이스 서버와 동기시키는 것이 합리적이다. 락 스텝(lock step)에서의 업데이트를 선택할 지 또는 선택하지 아니할 지의 여부는 데이터 관리의 문제점이 아니라 응용 정책의 문제점이다.
데이터베이스 서버에 가해지는 변화만이 클라이언트 데이터베이스에 전달된다.
만약 클라이언트 데이터베이스 2234가 불활성화되거나 데이터베이스 서버와 통신하는 것이 불가능할 경우에는, 클라이언트 데이터베이스는 마스터와 다시 동기되어야 한다. 심한 경우에는 전체 데이터베이스 또는 선택된 서브세트를 다시 로드하기 위해 오퍼레이터 중재가 요구될 수도 있다.
클라이언트 데이터베이스 2234는 다음의 인터페이스 운영을 제공한다:
·권한 있는 응용장치에 의한 일련의 특정 데이터에 대한 접속,
·권한 있는 응용장치에 의한 정책 선호의 확정,
·데이터의 로컬 카피의 특정 뷰의 선택,
·데이터의 로컬 카피의 삽입, 업데이트 또는 삭제,
·가입된 데이터를 데이터베이스 서버와 동기시키는 것, 및
·캐시된 데이터에 대한 데이터베이스 서버로부터 만료 안내.
부가적으로 데이터베이스 클라이언트는 로그 또는 리포트 및 신호 문제점을 모니터 2240에 제출한다.
(2) 데이터 마스터(데이터베이스 서버 - dbServer)
데이터베이스 서버 2236은 데이터의 보호에 중심적 역할을 수행한다. 데이터베이스 서버에서 데이터는 소유되고, 마스터 카피는 유지 보수된다. 신뢰성을 위해 적어도 2개 이상의 마스터 데이터의 카피가 유지 보수된다. 데이터 성취를 개선시키기 위해 부가적 마스터 카피가 배치될 수 있다.
이 카피는 락스텝에서 동기된다. 즉 각 업데이트는 업데이트 경쟁을 방지하기 위해 대응되는 마스터 락을 얻는 것이 요구된다. 엄격한 실현 정책은 변화할 수 있으나, 통상 모든 마스터 카피는 연속적 업데이트 순서를 유지하여야 하고, 다른 마스터 카피와 같이 데이터의 같은 뷰 및 같은 통합 집행을 제공하여야 한다. 데이터의 내부 카피는 데이터베이스 클라이언트 2234에 투명하다.
데이터베이스 서버 2236은 데이터 명세 사이의 관계를 기술하거나 집행하며, 특정한 데이터 값 또는 포맷을 제한하는 사무규칙 층을 포함한다. 모든 데이터 업데이트는 이 규칙을 통과하거나 또는 거절되어야 한다, 이와 같은 방식에 의해 데이터베이스 서버는 모든 데이터가 단일한 카피로서 관리되는 것을 보증하고, 모든 사무규칙이 수집되고 균일하게 적용되는 것을 보증한다.
데이터베이스 서버 2236은 데이터 변화가 일어나는 것을 추적해서 로그 및 요약 통계를 모니터에 제공한다. 부가적으로 이러한 변화는 능동 가입에 전달되고, 캐시 카피는 만료 메시지에 의해 쓸모가 없다는 것이 표시된다. 데이터베이스 서버는 또한 안전 검사 및 인증을 제공하고, 선택된 항목이 저장되기 전에 코드화하는 것을 보장한다.
데이터베이스 서버는 아래의 인터페이스 운영을 지원한다:
·데이터베이스 서버로부터 선택된 데이터를 뷰하는 것,
·데이터베이스 서버로부터 선택된 데이터를 가입하는 것,
·선택된 데이터를 데이터베이스 클라이언트 2234에 있는 캐시카피에 복사하는 것,
·데이터베이스 클라이언트에 요구되는 현재의 카피를 새롭게 제공하는 것,
·마스터의 모든 데이터베이스 서버 카피에 새로운 데이터를 삽입하는 것,
·모든 데이터베이스 서버 카피에 데이터 속성을 변화시키는 것, 및
·이전의 가입을 취소하고 데이터의 캐시카피를 삭제하는 것.
(3) 데이터 관리 2238
데이터 관리 2238은 데이터 정책을 정하는 것, 논리 및 물리 데이터베이스의 관리 및 데이터 관리 2138 도메인을 확보 및 구성하는 것 등과 관련되어 있다. 데이터 관리 정책은 안전, 분산, 통합 규칙, 성능 요구 및 복제와 분할의 제어 등을 포함한다. 데이터 관리 2238은 데이터 위치를 설정, 물리 저장의 할당, 메모리 할당, 데이터 로딩, 접속 경로의 최적화 및 데이터베이스 문제점을 해결하는 것 등과 같은 데이터 자원의 물리 제어를 포함한다. 데이터 관리 2238은 또한 데이터의 감사, 조정, 이동, 목록화 및 전환과 같은 데이터의 논리제어를 제공한다.
데이터 관리 2238은 다음의 인터페이스 운영을 지원한다:
·데이터 형태의 특징을 정의하는 것,
·주어진 차원의 논리 컨테이너를 생성하는 것,
·둘 이상의 컨테이너를 결합을 통해 관련시키는 것,
·데이터 값 또는 관계를 조건부 트리거(trigger) 및 실행에 의한 제한,
·데이터에 대한 물리 컨테이너를 주어진 위치에 위치시키는 것,
·데이터에 대한 물리 컨테이너를 새로운 위치에 이동시키는 것,
·물리 컨테이너 및 그 데이터를 제거하는 것,
·하나의 컨테이너에서 다른 컨테이너로 데이터를 로딩하는 것,
·컨테이너의 데이터 내용을 삭제하는 것, 및
·컨테이너의 데이터 내용을 증명하는 것 또는 조정하는 것.
(4) 데이터 모니터링 (dbMon) 2240
데이터 모니터링 2240은 모든 데이터와 관련된 사상과 ISP 경계 게이트웨이, 데이터베이스 클라이언트 및 데이터베이스 서버로부터의 통계적 측정을 장악하는 모니터링 기능을 대변한다. 데이터 모니터링 2240 메카니즘은 감사 추적 및 로그를 생성하기 위하여 사용된다.
데이터 모니터링은 통상 수동 인터페이스를 나타낸다. 데이터는 그것에 공급된다. 그러나 모니터링은 계층적 활동이며, 더 나아간 분석 및 롤업은 데이터 모니터링 내에서 일어난다. 부가적으로 데이터 모니터링은 어떤 임계 또는 조건이 만족될 때 경보를 송신한다.
메트릭스의 속도 및 수는 서비스 품질, 데이터 성능, 다른 서비스 수준 동의 등을 평가하기 위해 사용된다. 데이터 검사, 저장 및 롤업 등을 위해 모든 예외 및 에러는 데이터 모니터링에 로그 및 이동된다.
데이터 모니터링 2240은 다음의 인터페이스 운영을 지원한다:
·모니터 제어, 필터, 및 임계값을 설정하는 것,
·데이터와 관련된 활동을 로그하는 것,
·상태. 메트릭스, 또는 감사 결과를 보고하는 것, 및
·경보 또는 경고 신호를 보내는 것.
(5) 데이터 관리 운영 (Ops) 2244
운영 콘숄(Ops) 2244는 퍼스넬(personnel) 모니터링, 관리 및 또 다른 관리 시스템을 위한 워크스테이션 인터페이스를 제공해준다. Ops 콘숄은 전술한 dbMon 2240, dbMon 2238, dbSever 2236을 위한 운영 인터페이스에 대한 접속을 제공해준다. Ops 콘숄 2244는 다양한 시스템, 인터페이스. 및 데이터 관리 도메인 내의 응용장치 등의 기억 상황도[또는 맵(map)]에 기초한 아이콘(icon)을 통해 동적 상태의 디스플레이를 제공해준다.
5. 물리 기술
이 단락은 데이터 관리 2138 물리 아키텍쳐를 기술한다. 이것은 일련의 구성요소가 어떻게 배치되는 지를 기술한다. 일반적 배치 개관은 도29에 나타나 있다.
도 29에서:
·원은 물리 사이트를 표시하기 위해 사용되었고,
·박스 및 박스 조합은 컴퓨터 노드이며, 및
·기능적 역할은 약어로 표기되어 있다.
도 29에서 사용된 약어는:
·OE - 오더 엔트리 시스템 2250,
·GW - ISP 게이트웨이 2230,
·APP - 응용장치 2232,
·CL - 데이터베이스 클라이언트 2234,
·SVR - 데이터베이스 서버 2236,
·ADM - 데이터 관리 구성요소 2238,
·MON - 데이터 모니터링 구성요소 2240, 및
·Ops - 운영 콘숄 등이다.
요소들의 기능적 역할은 도28과 관련하여 상기 언급한 바 있다.
도 29에 표시된 각 사이트는 하나 이상의 광역망(WAN) 링크에 의해 다른 사이트와 연결되어 있다. 정확한 네트워크 구성 및 배열은 상세한 엔지니어링 고안 과제로 남겨져 있다. 데이터베이스 카피가 오더 엔트리 사이트 2251에 분산되는 것은 일반적이지 아니하다. 그러나 이 아키텍쳐에서는 엔트리 사이트는 주변사이트와 동등한 것으로 간주되고 데이터베이스 기능을 가지고 있다.
ISP 2100의 네트워크 사이드에서는 주변 사이트 2252 각각은 데이터베이스 클라이언트 2234를 가지고 있다. 이 사이트는 통상 근거리 통신망(LAN - local area network)을 운영한다. 데이터베이스 클라이언트는 ISN 오퍼레이터 콘숄, ARU, 또는 NCS 스위치 요구 변환과 같은 네트워크나 시스템 응용장치를 위한 로컬 레포지터리로 작용한다. 중앙 사이트 2254는 데이터베이스 클라이언트에게 중복데이터 저장 및 데이터 접속 경로를 제공한다. 데이터 모니터링 구성요소 2240은 증가된 성능을 위해 주변 사이트에 배치될 수 있음에도 불구하고, 중앙 사이트는 또한 롤업 모니터링 기능을 제공한다.
관리 기능은 바람직한 운영 또는 관리 사이트 2254에 위치해 있으나, 데이터 모니터링과 반드시 같은 위치에 있을 필요는 없다. 관리 기능은 명령 및 제어를 위해 운영 콘숄과 dbAdmin을 요구한다. 원거리 운영 사이트는 광역 또는 근거리 연결로부터 dbAmin 노드 2238에 접속이 가능하다. 사이트 각각은 다른 사이트에 있는 복제 기능 구성요소에 의해 백업되고 다양하고 중복된 링크에 의해 연결되어 있다.
6. 테크널리지 선택
아래의 단락은 고려되어져야 하는 다양한 테크널리지 옵션을 기술한다. 데이터 관리 2138 아키텍쳐는 운영을 위해 어떤 특별한 테크널리지를 요구하는 것은 아니나, 다른 테크널리지 선택이 시스템의 최종 성능에 영향을 미칠 수 있다.
도 30은 매우 높은 성능 환경을 제공하는 일련의 테크널리지를 묘사한다. 그림에서 나타난 특정한 응용장치는 최소 수준의 수용가능한 성능을 결정하기 위한 것이다.
3개의 일반적 환경이 나타나 있다:
·상층부에는 다중프로토콜 라우팅되는 네트워크 2260이 외부 및 원거리 요소를 중앙 데이터 사이트와 연결한다. 관리 터미널 및 작은 중범위(mid-range) 컴퓨터 및 오더 엔트리와 같은 고가동율 응용 플랫폼 등이 나타나 있다:
·중앙에는 큰 데이터 저장 장치를 가진 대규모 고성능 기계 2262가 있다: 이것들은 마스터 데이터베이스, 데이터 처리 그리고 dbServer 및 dbMon과 같은 데이터 변환/트랙킹 기능의 전형이다:
·하층부에는 ISN 오퍼레이터 센터 또는 DAP 사이트와 같은 근거리 처리 및 네트워크 인터페이스 2264가 나타나 있다.
7. 완성
현재의 ISP 데이터 시스템의 많은 것이 알려져 있지만, 최종적 완성이 결정되기 전에 부가적으로 상세한 필요조건이 필요하다. 이 필요조건은 ISN, NCS, EVS, NIA 및 TMN 시스템이 필요하고, 또한 광대역, 인터넷(Internet) 및 스위치 없는 응용장치를 위해 계획된 새로운 산물 모두가 부가된다.
8. 안전
ISP 데이터는 보호된 통합 자원이다. 데이터 접속은 제한되고 인증된다. 데이터와 관련된 활동은 추적되고 감사된다. 모든 저장된 패스워드, 개인 식별 번호(PINS - personal identification numbers), 개인 인사 기록 및 선택된 재정, 사무 및 고객정보 등에 대한 데이터 암호화가 요구된다. 보안된 데이터는 클리어-텍스트(clear-text) 형태로 전송되어야 한다.
9. 메타-데이터(meta-data)
메타-데이터는 데이터 파생 논리를 위한 규칙을 구성하는 데이터의 형태이다. 메타데이터는 데이터의 운영 형태를 묘사 및 관리하기 위해 사용된다. 이 아키텍쳐 하에서, 메타데이터에 의해 파생되는 많은 제어가 행해진다. 메타데이터는 통상 가장 유연한 실행시간 옵션을 제공한다. 메타데이터는 통상 시스템관리자의 제어 하에 있다.
10. 표준 데이터베이스 테크널리지
제안된 데이터 관리 아키텍쳐의 완성은 가능하면 상업적으로 유용한 산물을 이용하여야 한다. 벤더는 데이터베이스 테크널리지, 복제 서비스, 규칙 시스템, 모니터링 장치. 콘숄 환경 및 다른 유용한 제공 등을 제공한다.
J. ISP 자원 관리 모델
이 단락은 ISP 2100 아키텍쳐와 관련되어 있기 때문에 자원 관리 2150 모델을 기술한다.
a) 범위
자원 관리 모델은 자원을 필요로 하는 프로세스와 자원 그 자체 사이의 관계에 있어서 자원 할당 및 할당 해제의 순환을 다룬다. 이 순환은 자원 등록 및 자원 할당 해제로부터 개시하여, 자원 요구, 자원 획득, 자원 상호작용 및 자원 해방을 계속한다.
b) 목적
자원 관리 모델 2150은 일반적으로는 ISP 개발 코뮤니티(community)에 위한, 및 구체적으로는 ISP 아키텍쳐를 위한 통상의 아키텍쳐럴 가이드라인을 정의하고자 함이다.
c) 목표
현존하는 전통적 ISP 아키텍쳐에 있어서, 서비스는 그 물리 및 논리 자원을 제어 및 관리한다. 서비스로부터 자원을 추출하는 아키텍쳐로의 이송은 자원과 서비스 사이의 상호 작용 및 관계를 제어하는 관리기능을 정의할 것을 요구한다. 이러한 기능이 자원 관리 2150 모델에 의해 대변된다.
자원 관리 모델의 목표는 네트워크-와이드 자원 관리의 허용, 자원 이용의 최적화 및 네트워크를 통한 자원 공유를 가능하게 하기 위해 고안되었다:
·서비스로부터 자원을 추출하는 것,
·자원 상태에 대한 실시간 접속을 제공하는 것,
·자원 부가 및 제거의 과정을 단순화하는 것,
·안전하고 단순한 자원 접속을 제공하는 것, 및
·자원의 유저들 중의 어느 한사람이 자원을 독점하지 못하도록 공평한 자원 획득을 제공하는 것.
d) 기본 개념
통상 자원 관리 2150 모델은 자원과 그것을 이용하는 프로세서 사이의 관계 및 상호작용을 제어한다. 모델이 제시되기 전에, 모델을 설명하기 위한 기본적 용어 및 개념에 대한 이해가 확립되어야 한다.
용어 및 개념에 대한 목록은 다음과 같다.
(1) 정의
·자원 - 외부 프로세스에 의해서 자극될 때 특정되어 있고 잘 정의된 용량을 제공하는 작업의 기본단위. 자원은 논리적으로는 서비스 엔진 및 언어 인식 알고리즘과 같은 것으로 분류될 수 있고, 물리적으로는 CPU, 메모리 및 스위치 포트로 분류될 수 있다. 자원은 ATM 링크 대역폭 또는 디스크 공간과 같이 공유될 수 있으며, 또한 VRU 또는 스위치 포트와 같이 전용될 수도 있다.
·자원 풀(Pool) - 공통 용량을 공용하고 있는 일련의 등록된 자원의 일체.
·서비스 - 네트워크 자원의 유저와 자원 그 자체 사이의 모든 활동 및 상호작용의 흐름에 대한 논리적 표현.
·정책 - 자원 할당과 할당해제, 자원 풀 크리 임계값, 및 자원 이용 임계값 등을 취급하는 실행을 제어하는 일련의 규칙.
(2) 개념
·자원 관리 모델은 잘 정의된 절차 및 정책을 통해 자원 풀에/로부터 자원을 요구, 획득, 해방시키는 일련의 기능을 제어하거나 허용하는 메카니즘이다. 자원 할당과 자원 할당해제는 3개의 단계를 거친다:
·자원 요구: 프로세스가 자원 관리자 2150으로부터 자원을 요구하는 단계이다.
·자원 획득: 만약 요구되는 자원이 유용하고 요구 프로세스가 요구할 권한이 있는 경우에는, 자원 관리자 2150은 자원을 부여하고, 프로세스는 그것을 이용할 수 있다. 반면에, 프로세스는 자원 할당 과정을 포기하고 후에 다시 시도하거나, 또는 자원 관리자가 자원을 부여할 것을 요구할 수 있다.
·자원 해방: 할당된 자원은 프로세스가 자원을 더 이상 필요로 하지 아니할 경우 자원 풀로 다시 되돌아간다. 자원 형태에 따라, 프로세스는 자원을 해방하고 자원관리자에게 새로운 상태를 알려주거나, 프로세스 그 자체가 자원관리자에게 자원이 유용함을 알려준다. 이 두 가지 방법 중 어떤 방법에 의하더라도, 자원관리자는 자원을 자원 풀에 복귀시킨다.
자원 관리 모델은 자원 풀의 생성 및 그것을 제어하는 정책을 고려한다. 자원관리 모델은 자원이 자원 풀의 적법한 회원으로 등록되거나 또는 등록 말소되도록 한다.
자원 관리 모델 정책은 부하 균형, 고장 극복 및 최소비용 알고리즘을 강요하고, 서비스가 자원을 독점하는 하는 것을 방지한다. 자원관리 모델은 자원 이용을 추적하고, 자원 풀이 요구를 충족시키지 아니한다면 자동적으로 올바른 조치를 취한다. 어떠한 서비스도 그것이 권한이 부여되어 있으면 네트워크를 통해 어떠한 자원도 이용할 수 있다.
자원 관리 모델은 자원을 모델링하기 위해 OSI 객체 지향 접근을 채용하였다. 이 모델 하에서 각 자원은 피관리 객체(MO - Managed Object)로 표현된다. 각 MO는 아래의 논점에서 정의되어 있다.
·속성 : MO의 속성은 MO의 성질을 표현하고, MO의 특성 및 현재의 상태를 기술하기 위해 사용된다. 각 속성은 하나의 값과 관련되어 있다. 예를 들면, MO의 현재 상태(CURRENT_STATE) 속성은 휴지(IDLE)를 뜻한다.
·연산 : 각 MO는 일련의 연산을 가지고 있다.
이 연산에는:
·생성: 새로운 MO를 만들어내는 것,
·삭제: 현재의 MO를 삭제하는 것,
·실행: 정지(SHUTDOWN)와 같이 특정한 연산을 수행하는 것,
·값 획득: 특정한 MO 속성값(attribute value)을 얻는 것,
·값 부가: 특정한 MO 속성값을 부가하는 것,
·값 제거: 특정한 MO 속성값을 일련의 값으로부터 제거하는 것,
·값 대체: 현재의 MO 속성값을 다른 값으로 대체하는 것,
·값 설정: 특정한 MO 속성값을 디폴트값에 설정하는 것,
·통보: 각 MO는 그 상태를 관리 엔티티에 알려주거나 보고할 수 있다. 이것은 트리거 또는 트랩으로 볼 수 있다: 및
·경향: MO의 경향은 MO가 특정한 연산 및 이 반응에 부과되는 제약에 어떻게 반응하는 지에 의해 표현된다. MO는 외적 자극 및 내적 자극 양자에 모두 반응한다. 외적 자극은 연산을 지시하는 메시지로 표현된다. 내적 자극은 타이머의 만료와 같이 MO에 발생하는 내적 사건이다. 만료된 타이머에 MO가 어떻게 반응하여야 하는 지에 대한 제약은 MO가 그러한 사실을 보고하기 전에 타이머의 만료횟수를 특정함에 의해 부과될 수 있다.
자원을 이용, 조작 또는 모니터링 하는 것이 필요한 모든 요소는 그 자원을 MO처럼 다루는 것 및 상기 언급한 연산을 통해서 자원에 접속하는 것이 필요하다. 자원의 상태를 알 필요가 있는 관련된 요소는 그 자원에 의해 생성된 사상을 어떻게 수신하고 반응할 것인지를 알 필요가 있다.
부분 및 전역 자원 관리 (Local and Global Resource Management)
자원 관리 모델은 적어도 2개의 관리 계층구조로 이루어져 있다: 부분 자원 관리(LRM) 2190 및 전역 자원 관리(GRM) 2188. 각 자원관리는 자기 고유의 도메인 및 기능을 가지고 있다.
2. 부분 자원 관리(LRM)
·도메인: 부분 자원 관리(LRM)의 도메인은 네트워크의 특정한 장소에 속하는 특정한 자원 풀에 제한되어 있다. 복수개의 부분 자원 관리가 하나의 장소에 있을 수 있으며, 각 부분 자원 관리는 특정한 자원 풀을 관리하는 것을 책임진다.
·기능: 부분 자원 관리(LRM)의 중요한 기능은 자원 관리 모델의 아내에 따라 프로세스와 자원 사이의 자원할당 및 할당해제 과정을 촉진시키는 것이다.
3. 전역 자원 관리(GRM)
·도메인: 전역 자원 관리(GRM)의 도메인은 네트워크 상에 퍼져있는 모든 자원 풀에 있는 모든 등록된 자원에 미친다.
·기능: 전역 자원 관리(GRM)의 주요한 기능은 부분자원 관리 2190을 도와 LRM 도메인 내에서는 유용하지 아니한 자원을 위치시키는 것이다.
도31은 네트워크 2270 내에서의 GRM 및 LRM 도메인을 설명한다.
4. 자원 관리 모델 (RMM)
자원 관리 모델 (RMM)은 정적 환경설정에 반하여 동적 자원 할당의 개념에 기초하고 있다. 동적 자원 할당 개념은 자원과 자원을 이용하는 프로세스 사이에 미리 정해진 정적인 관계가 존재하지 아니함을 의미한다. 할당 및 할당해제 과정은 공급과 요구에 기초한다. 자원 관리자 2150은 자원의 존재를 알고 있으며, 자원을 필요로 하는 프로세스는 자원관리자를 통해 자원을 획득한다. 반면에 정적인 환경설정은 각 자원과 프로세스 사이에 미리 정해진 관계가 존재함을 의미한다. 이와 같은 경우에는 자원 관리 엔티티가 자원을 관리할 필요가 없다. 동적 자원 할당 및 정적환경설정은 자원 관리 형태의 두 극단을 대변한다. 어떠한 자원 관리 형태도 양극단 사이에 속한다.
자원 관리 모델은 LRM 2190 및 GRM 2188의 경향, 논리적 관계 및 상호작용을 기술한다. 그것은 또한 LRM/GRM과 자원을 필요로 하는 프로세스 사이의 자원 할당 및 할당해제를 제어하는 규칙 및 정책을 기술한다.
a) 단순 자원 관리 모델
자원 할당 및 할당해제가 복잡한 과정을 거칠 수 있다는 것을 파악하기 위해, 단순한 형태의 과정이 실제 모델의 소개로 제시되어 있다. 단순 자원 할당 및 할당해제는 6단계를 통해 성취된다. 도32는 이 단계들을 기술하고 있다.
1. 프로세스 2271은 자원 관리자 2150으로부터 자원 2173을 요구한다.
2. 자원 관리자 2150은 자원 2173을 할당한다.
3. 자원 관리자 2150은 할당된 자원을 프로세스에 부여한다.
4. 프로세스는 자원과 상호작용한다.
5. 프로세스가 자원과 작업을 종료하였을 때, 프로세스는 이것을 자원에게 알린다.
6. 자원 2273은 자원 관리자 2150에 다시 해방시킨다.
b) 자원 관리 모델 논리 요소
자원관리 모델은 상기 언급한 목표를 성취하기 위해 상호작용하며 서로 협동하는 일련의 논리 요소로 표현된다. 이 요소는 도33에 나타나 있으며, 자원 풀(RM) 2272, LRM 2190, GRM 2188 및 자원관리 정보베이스(RMIB - Resource Management Information Base) 2274를 포함한다.
(1) 자원 풀 2272
같은 형태이며, 공통적 속성을 가지거나 같은 용량을 제공하고, 그리고 같은 네트워크 장소에 위치되어지는 모든 정보는 자원 풀(RP)을 형성하기 위해 논리적으로 그룹화된다. 각 RP는 자기 고유의 LRM을 가지고 있다.
(2) 부분 자원 관리자 (LRM) 2190
LRM 2190은 특정한 자원 풀 2272의 관리를 책임지고 있는 요소이다. 도32에 나타난 바와 같이, LRM에 의해 관리되는 자원 풀로부터 자원을 필요로 하는 모드 프로세스는 LRM을 통해 자원에 접속하여야 한다.
(3) 전역 자원 관리자 (GRM) 2188
GRM 2188은 네트워크 상의 자원 풀에 대한 전체적 개관을 가지고 있는 엔티티이다. GRM은 이 전체적 개관을 LRM을 통해 얻는다. 모든 LRM은 RP 2272 상태 및 통계를 가지고 GRM을 업데이트 한다. 모든 로컬 자원이 바쁘고 또는 요구되는 자원이 다른 장소에 속하기 때문에 어떤 LRM이 자원을 할당하지 못하는 경우가 있다. 이와 같은 경우에는 LRM이 요구되는 자원을 네트워크를 가로질러 위치시키기 위해 GRM과 상의할 수 있다.
(4) 자원 관리 정보 베이스(RMIB) 2274
상기 언급한 바와 같이, 모든 자원은 피관리 객체(MO)처럼 취급될 수 있다. RMIB 2274는 네트워크를 가로질러 모든 MO에 대한 모든 정보를 가지고 있다. MO 정보는 객체 정의, 상태, 연산 등을 포함한다. RMIB는 ISP 데이터관리 모델의 일부분이다. 모든 LRM 및 GRM은 RMIB에 접속할 수 있고, 그들 자신의 개관을 가지고 있으며, ISP 데이터관리 모델을 통해 MO 정보에 대한 접속 권한을 가지고 있다.
5. 구성요소 상호작용
그들의 임무를 수행하기 위해, 자원관리 모델 요소는 자원관리 모델의 규칙, 정책, 가이드라인 내에서 상호작용하고 서로 협력하여야 한다. 아래의 단락은 이 엔티티들이 어떻게 상호작용하는 지를 설명한다.
a) 엔티티 상호작용 (ER - Entity Interaction) 다이어그램 (도33)
도33에서, 각 사각형은 하나의 엔티티를 표현하며, ＜ ＞ 사이의 어휘는 두 엔티티 사이의 관계를 의미하며, 사각 괄호 "[ ]"는 괄호된 수에서 비괄호된 곳으로 나아가는 관계의 방향을 의미한다. 그 수는 관계가 1대1, 1대다, 및 다대다 임을 의미한다.
도33은 다음과 같이 해석된다.
1. 하나의 LRM 2190이 하나의 RP를 관리한다.
2. 복수의 LRM2190이 RMIB 2274에 접속한다.
3. 복수의 LRM 2190이 GRM 2188에 접속한다.
4. 복수의 GRM 2188이 RMIB 2274에 접속한다.
(b) 등록 및 등록말소
자원 등록 및 등록말소는 동적으로 관리되는 일련의 자원에만 적용된다. 자원이 정적으로 할당되는 몇 가지 경우가 있다. LRM 2190은 일련의 자원을 가지고 있는 자원 풀 2272 상에서 운영된다. LRM이 어떠한 자원을 관리하기 위해서는 자원은 LRM에게 그 상태 및 존재에 대해서 알려주어야 한다. 또한 GRM 2188은 어떠한 자원을 위치시키기 위해서는 네트워크를 가로질러 그 자원의 가동성에 대해서 인식하고 있어야 한다. 아래의 등록 및 등록말소 가이드라인은 동적으로 관리되는 모든 자원에 적용되어야 한다:
·모든 자원은 그들의 LRM 2190에 특정한 자원 풀 2272의 멤버로서 등록되어야 한다.
·만약 어떠한 이유에 의해서 자원이 정지 또는 서비스의 중단할 필요 있는 경우, 모든 자원은 그들의 LRM 2190에서 등록 말소되어야 한다.
·모든 자원은 그들의 가동 상태를 LRM 2190에 보고하여야 한다.
·모든 LRM은 등록 및 등록 말소된 자원에 기초하여 최근의 자원 가동률을 이용하여 GRM 2188을 업데이터 해야 한다.
c) GRM, LRM 및 RP 상호작용
모든 RP 2272는 LRM에 의해서 관리될 것이다. 특정한 자원 형태를 필요로 하는 각 프로세스는 자원 접속을 촉진시키는 하나의 LRM이 할당될 것이다. 프로세스가 자원을 필요로할 경우 프로세스는 할당된 LRM을 통해 그것을 요구하여야 한다. LRM이 자원을 위한 요구를 받았을 때, 두 가지 경우가 있을 수 있다:
1. 자원이 가동될 수 있는 경우: 이 경우에는 LRM은 풀의 자원 멤버를 할당하고 자원을 프로세스가 취급할 수 있도록 넘겨준다. 프로세스가 완결될 때까지 프로세스는 자원과 상호작용한다. 프로세스가 자원과의 상호작용을 완결한 경우 자원 형태에 따라, 프로세스는 자원에 그러한 사실을 알리고 자원 그 자체가 LRM에 자원이 가동될 수 있음을 알리거나, 또는 프로세스가 자원을 해제함과 아울러 LRM에 자원을 더 이상 사용하지 아니함을 알릴 수 있다.
2. 자원이 가동될 수 없는 경우: 이 경우에는 LRM 2190이 GRM 2188과 요구되는 자원을 가지고 있는 외부자원에 대해서 상의한다. 만약 외부 자원이 가동될 수 없는 경우라면, LRM은 요구하는 프로세스에 어떠한 자원도 가동될 수 없음을 알린다. 이 경우 요구하는 프로세스는:
·포기하고 재시도,
·자원이 가동될 수 있을 때 LRM이 자원을 할당할 것을 요구하는 것, 또는
·특정한 시간 내에 자원이 가동될 수 있다면 LRM이 자원을 할당할 것을 요구하는 것 등이다.
만약 외부 자원이 가동될 수 있다면, GRM 2188이 위치 및 접속정보를 LRM에 전달한다. 그리고 나서 LRM은:
·요구하는 프로세스를 위하여 자원을 할당하고, 프로세스가 자원을 취급할 수 있도록 하거나(이 경우 GRM을 통한 자원할당은 프로세스에 통과 가능하다), 또는
·요구하는 프로세스에게 위치된 자원을 관리하는 LRM에 접촉할 것을 권유한다.
d) GRM, LRM 및 RMIB 상호작용
RMIB 2274 네트워크를 가로질러 모든 관리되는 자원에 대한 모든 정보 및 상태를 가지고 있다. 각 LRM 2190은 RMIB 2274에 대한 하나의 개관을 가지고 있으며, LRM이 관리하는 RP 2272에 자세히 표시한다. 반면에 GRM은 모든 자원에 대한 전체 개관을 가지고 있다. 이 개관은 모든 LRM 개관으로 구성된다. GRM의 전체 개관은 네트워크를 가로질러 자원을 위치시킬 수 있게 한다.
RMIB 2274가 정확한 자원 정보를 유지하기 위해서는, 각 LRM 2190이 최근 자원 상태를 이용하여 RMIB을 업데이트 해야 한다. 이것은 자원 부가, 자원 제거 및 자원 상태 업데이트를 포함한다.
GRM 2188 및 LRM 2190 양자는 ISP 데이터 관리 엔티티를 통해 접속이 가능하고 RMIB의 개관을 가지고 있다. RMIB 데이터에 대한 실질적 관리는 ISP 데이터 관리 엔티티에 속한다. GRM 및 LRM는 단지 RMIB를 업데이트 하는 것을 책임지고 있다.
K. 운영지원 모델 (OSM - Operational Support Model)
1. 소개
현존하는 대부분의 ISP 서비스 플랫폼은 그 각각이 고유한 운영지원 기능을 가진 채 독립적으로 발전되었다. 주어진 일련의 플랫폼을 운영하는 방법을 배우는 데 소요되는 시간은 플랫폼의 수에 따라 증가한다. ISP 서비스 플랫폼은 모든 운영지원 기능에 대한 공통의 모델을 가진 아키텍쳐로 이동하는 것이 필요하다. 이것은 현재의 요구를 지원하고 미래의 변화에 적응해 나가는 모델을 정의할 것을 요한다. 이 운영지원 모델(OSM)은 ISP 2100에 대한 관리 지원의 완성을 위한 프레임워크를 정의한다.
a) 목적
운영지원 모델의 목적은:
·ISP 자원에 대한 플랫폼을 통합함에 의해 운영의 단순화를 성취하는 것,
·공통 관리 하부구조를 제공함에 의해 운영 personnel에 대한 커브를 감소하는 것,
·중복되는 관리 시스템을 감소시킴에 의해 관리 시스템의 비용을 감소시키는 것, ·ISP 서비스 및 네트워크 요소에 대한 공통 관리 하부구조를 제공함에 의해 ISP 서비스를 위한 마켓(market) 시간을 개선하는 것, 및
·ISP 물리 자원(하드웨어) 및 논리 자원(소프트웨어)을 관리하기 위한 프레임워크를 제공하는 것 등이다.
b) 범위
기술된 OSM은 ISP 물리 네트워크 요소 및 그 위에서 작동되는 서비스의 분산관리를 위해 제공된다. 관리 프레임워크는 논리 자원의 관리에 확장될 수 있다. 그러나, 여기 제시된 아키텍쳐는 --------------------------------------.
관리 서비스는 4개의 층내에서 일어난다:
·계획,
·서비스 관리,
·네트워크 층, 및
·네트워크 요소.
층내에서의 정보는 4개의 기능 영역 내에 속한다.
·환경설정 관리,
·오류관리,
·자원 관리, 및
· 회계. 모든 ISP에 공통 운영지원 모델의 사용은 ISP의 운영을 강화시키고, ISP 내에서의 미래 프로덕트 및 서비스의 고안을 단순화한다. 이 운영지원 아키텍쳐는 ITU 전기통신 관리 네트워크(TMN) 표준과 일치한다.
c) 정의
피관리 객체(Managed Object): 하나 이상의 관리 시스템에 의해 모니터링 되고 제어되는 자원. 피관리 객체는 관리 시스템 내에 위치하고 다른 피관리 객체 내에 내장될 수 있다. 피관리 객체는 관리 또는 물리자원일 수 있으며, 자원은 하나 이상의 피관리 자원으로 표현될 수 있다.
피관리 시스템(Managed System): 하나 이상의 피관리 객체.
관리 서브도메인: 패어런트(parent) 관리 시스템 내에 전적으로 위치하는 관리 도메인.
관리 시스템(Management System): 피관리 객체 및/또는 서브도메인에 대한 모니터링 및 제어기능에 영향을 미치는 피관리 도메인 내의 응용 프로세스.
관리 정보 베이스(MIB-Management Information Base) : MIB는 피관리 객체에 대한 정보를 가지고 있다.
관리도메인: 하나 이상의 관리 시스템, 0 또는 그 이상의 피관리 시스템, 및 관리 서브도메인의 집합.
네트워크 요소: 전송 시스템, 교환시스템, 다중화, 신호터미널, 전위처리기, 메인프레임(mainframe), 클러스트 제어장치, 파일 서버, LAN, WAN, 라우터, 브리지, 이서넷 스위치, 허브(Hub), X.25 링크, SS7 링크 등의 아날로그와 디지털 통신 장비 및 관련된 지원 장비 등의 복수 형태로 구성되는 통신망. 관리되어질 때, 이런 장비는 네트워크 요소라 통상 불려진다.
도메인: 기능(오류, 서비스.......), 기하 및 망 구조 등과 같은 다양한 방식으로 분할될 수 있는 관리환경.
운영 시스템: 관리 기능은 운영 시스템 내에 위치한다.
2. 운영지원 모델
도34는 네트워크 요소 상의 운영지원 모델 2308에 대한 관리 층 2300, 2302, 2304, 및 2306을 표시하고 있다. 운영지원 모델 2308은 ISP 2100의 관리를 매일 지원한다. 이 모델은 3개로 망되어 있다. 이 망은 층 2300-2306, 층 내의 기능영역. 및 관리 서비스를 제공하는 활성화이다. 피관리 객체(자원)는 관리 시스템에 의해서 모니터링 되고, 제어되고, 변경된다.
a) 기능 모델
아래의 단락은 관리 층 2300-2306내에서 일어나는 기능영역을 기술한다.
(1) 계획
ISP 계획 층 2300은 ISP 2100에 관해서 수집된 데이터의 레포지토리이며, 데이터에 부가적 가치가 제공되는 곳이다:
·구성관리 2312: 정책 및 목적의 설정.
·오류관리 2314: 오류에 대한 평균시간 예측.
·자원 측정 2316: 필요한 미래 자원(트렌딩, 용량, 서비스 동의 순응, 유지 보수 동의, 워크 포스)의 예측.
·회계: 서비스 가격 결정을 지원하기 위해서 서비스를 제공하는 비용의 결정.
(2) 서비스 관리(SM)
서비스 오더링, 배치, 준비, 서비스 품질 동의, 및 서비스 품질 모니터링은 ISP 서비스 관리 층 2302 안에 있다. 고객은 서비스를 제어 및 감시하기 위해 SM 층 2302에 대한 제한된 개관을 가지고 있다. SM 층은 NLM 내에 있는 에이전트와 상호작용하는 관리자를 제공한다. SM 층은 계획 층 230 내에 있는 관리자와 상호작용하는 에이전트를 제공한다. SM 층 내에 있는 관리자는 SM 층 내에 있는 다른 관리자와 상호작용한다. 이 경우 관리자-에이전트 관계는 동등하다.
·구성관리 2320: 서비스 정의, 서비스 활성화, 고객 정의, 고객 활성화, 서비스 특징, 하드웨어 준비, 소프트웨어 준비, 다른 데이터 및 자원 의 준비.
·오류 관리 2322: 서비스 동의의 침범에 대한 모니터 및 보고. 테스팅.
·자원 관리 2324: 서비스 동의의 침범을 예측하고, 잠재 자원 부족을 신호하고, 현재 및 미래의 서비스 요구를 예측한다.
·회계 2326: 회계 정보를 처리 및 전달한다.
네트워크 층 관리
ISP 네트워크 층 관리(NLM - Network Layer Management) 층 2304는 요소 관리에 나타난 것처럼 모든 네트워크 요소를 전체적으로 및 개별적으로 관리하는 책임을 맡고 있다. 개별적 요소가 서비스를 내부적으로 제공하는 방법과는 무관하다. NLM 층 2304는 EM 2306 내에 있는 에이전트와 상호작용하는 관리자를 제공한다. NLM 층 2304는 또한 SM 2302 층 내에 있는 관리자와 상호작용하는 에이전트를 제공한다. NLM 2304 층 내에 있는 관리자는 NLM 2304 층 내에 있는 다른 관리자와 상호작용한다. 이 경우 관리자-에이전트 관계는 동등하다.
·구성관리 2328은 네트워크 와이드 퍼스펙티브(perspective)로부터 로컬 및 원격 자원과 서비스의 특징을 정의하는 기능을 제공한다.
·오류 관리 2330은 다중 NE에서 발생하는 오류의 검출, 보고, 고립 및 수정 보완하는 기능을 제공한다.
·자원 관리 2332는 용량 퍼스펙티브로부터 자원이용의 네트워크 와이드 측정, 분석 및 보고를 제공한다.
·회계 2334는 다중 소스로부터 회계정보를 확장한다.
(3) 요소 관리(EM)
요소 관리 층 2306은 NE 2310을 책임지고 있으며, NE에 의해 제공되는 기능의 추출을 지원한다. EM 층 2306은 NE 내에 있는 에이전트와 상호작용하는 관리자를 제공한다. EM 층은 또한 NLM 2304 층 내에 있는 관리자와 상호작용하는 에이전트를 제공한다. EM 2306 층 내에 있는 관리자는 EM 층 내에 있는 다른 관리자와 상호작용한다. 이 경우 관리자-에이전트 관계는 동등하다.
·구성관리 2336은 로컬 및 원격 자원과 서비스의 특징을 정의하는 기능을 제공한다.
·오류 관리 2330은 오류의 검출, 보고, 고립 및 수정 보완하는 기능을 제공한다.
·자원 관리 2332는 용량 퍼스펙티브로부터 자원이용의 측정, 분석 및 보고를 제공한다.
·회계 2334는 회계 퍼스펙티브로부터 자원이용의 측정 및 보고를 제공한다.
(b) 네트워크 요소(NE-Network Element)
네트워크 용량을 제공하는 컴퓨터, 프로세스, VRU, 인터넷 게이트웨이, 및 다른 장비들은 네트워크 요소 2310이다. NE는 요소 관리 층 2306을 위해 운영을 수행하는 에이전트를 제공한다.
(c) 정보 모델
도35는 관리자 에이전트 상호작용을 보여준다. 통신망 관리는 분산 정보 응용프로세스이다. 이것은 NE 2100을 모니터링 및 제어하기 위해서 분산된 일련의 관리 응용 프로세스들 사이의 관리 정보의 상호교환을 포함한다. 이 정보교환의 목적을 위하여, 관리 프로세스는 관리자 2350 또는 에이전트 2352의 역할을 수행한다. 관리자 2350의 역할은 관리운영요구를 에이전트 2352에 송신하고, 그 운영의 결과를 수신하고, 사상 통지를 수신하고, 수신된 정보를 처리하는 것이다. 에이전트 2352의 역할은 피관리 객체 상에서 적절한 운영을 수행함에 의해 관리자의 요구에 응답하고, 응답 및 통지를 관리자에게 송신하는 것이다. 하나의 관리자 2350은 복수의 에이전트 2352와 상호작용할 수 있으며, 에이전트는 하나 이상의 관리자와 상호작용할 수 있다. 고수준의 관리자가 저수준의 관리자를 통해 피관리 객체에 작용한다는 점에서 관리자는 캐스케이드될 수 있다. 이 경우 저수준 관리자는 관리자 및 에이전트 양자의 역할을 수행한다.
3. 프로토콜 모델.
a) 프로토콜
관리자 및 에이전트 사이의 정보의 교환은 일련의 통신 프로토콜에 의존한다. 좋은 모델을 제공하는 TMN은 권고 X.710, 및 X.711에 정의된 바에 따라, 공통 관리 정보 서비스(CMIS) 및 공통 관리 정보 프로토콜(CMIP)을 사용한다. 이것은 ITU의 응용 공통 서비스 요소(X.217 서술 및 X. 227 프로토콜 서술) 및 원격 운영 서비스 요소(X.219 서술 및 X. 229 프로토콜 서술)에 기초하여 피어 투 피어 통신 프로토콜을 제공해준다. FTMA는 또한 파일 전송을 위한 상위 계층 프로토콜로서 지원된다. 이 상위 계층 프로토콜의 사용은 권고 X.812에 서술되어 있다. 이송프로토콜은 권고 X.811에 서술되어 있다. 권고 X.811은 또한 다른 하위 계층 프로토콜 사이에 상호작용을 기술한다. 이 일련의 프로토콜은 Q3로 언급된다.
b) 공통 문맥
프로세스 사이에 정보를 공유하기 위해서는 교환되는 정보의 해석에 대한 공통된 이해가 필요하다. BER과 함께 ASN.1(X.209)은 관리 프로세스(관리자/에이전트) 사이에 교환되는 모든 PDU에 대한 이 공통된 이해를 발전시키기 위해 사용될 수 있다.
c) 상위 계층의 서비스
TMN CMIS 서비스 층에서 요구되는 최소의 서비스가 아래에 기재되어 있다.
·설정: 속성의 값을 부가, 제거, 또는 대체하는 것,
·읽기: 속성의 값을 읽는 것,
·읽기 취소: 이전에 행해진 읽기를 취소하는 것,
·실행: 객체가 어떠한 행위를 하도록 요구하는 것,
·생성: 객체를 생성하는 것,
·삭제: 객체를 제거하는 것, 및
·사상 보고(event reporting): 네트워크 자원이 사상을 선언하도록 하는 것.
4. 물리 모델
도36은 ISP 2100의 물리모델을 보여준다.
5. 인터페이스 포인트
조정 장치 2360은 하나의 정보 모델을 ISP 정보 모델로의 전환을 제공한다. 게이트웨이 2362는 ISP 외부에 있는 관리시스템과의 연결에 사용된다. 이 게이트웨이는 ISP 컴플라이언트(compliant) 시스템 및 넌컴플라이언트(noncompliant) 시스템 양자의 운영을 위해 필요한 기능을 제공한다. 이 게이트웨이는 조정 장치 2360을 가지고 있을 수 있다. 도36은 9개의 인터페이스 포인트를 식별한다. 이 인터페이스 포인트와 관련된 프로토콜은:
1. 두 개의 상위계층 프로토콜이 있다. 모든 다른 운영지원 통신을 위한 워크스테이션과 ISP 상위계층과의 통신을 위한 프로토콜. 하위계층은 이서넷 상의 TCP/IP이다.
2. 상위 계층은 워크스테이션 2364와의 통신을 위한 프로토콜이며, 하위계층은 이서넷 상의 TCP/IP이다.
3,4.상위계층은 ISP 상위계층과의 통신을 위한 프로토콜이며, 하위계층은 이서넷 상의 TCP/IP이다.
5. 독점 프로토콜은 지원되는 인터페이스와 호환성이 없는 legacy 시스템이다. 단순 네트워크 관리 프로토콜을 제공하는 장비는 조정 장치에 의해서 지원된다.
6,7,8,9. 속성상 게이트웨이는 ISP 컴플라이언트(compliant) 및 넌컴플라이언트(noncompliant) 인터페이스를 지원한다. 내부 시스템을 기획하는 게이트웨이는 오더 엔트리 시스템 또는 기획 와이드 TMN 시스템과 같은 것을 포함할 수 있다.
운영지원 모델의 ISP 실현
도37은 운영지원 실현을 보여준다.
6. 일반
운영지원 모델은 운영지원 시스템의 설립을 위한 개념상의 프레임워크를 제공한다. 도37은 이 개념상의 모델의 ISP 실현을 표현한다. 이 모델의 완성에 있어서, 모든 ISP 네트워크 요소는 관리 정보 베이스(MIB) 2370 및 MIB에 있는 객체에 작용하는 에이전트 프로세스에 의해 운영지원 시스템으로 표현된다.
필드 지원 퍼스넬은 ISP 2100이 관리되는 2개의 수준이 있다.
1. 고장 추적을 위해, 네트워크 층 관리자 2372는 필드 지원에 ISP의 총체적 묘사를 제공한다. 문제점의 검출, 고립, 및 수정보완의 프로세스는 그곳에서 시작한다. 그 층으로부터, 문제점은 하나의 네트워크 요소로 고립된다. 개개의 네트워크 요소들은 네트워크 요소 관리자로부터 접근가능하며, 보다 상세한 수준의 모니터링, 제어, 구성, 및 테스팅을 허용한다. ISP의 중앙 집중 뷰는 오늘날의 ISP에는 없으나, 많은 사람들은 그 중요성을 인식하고 있다.
네트워크 층 관리자 2370은 환경설정을 위해서 ISP 와이드 뷰를 제공하고, 네트워크 요소를 일관되게 구성하기 위해 네트워크 요소 관리자 2374와 상호작용한다. 이것은 ISP의 구성이 모든 플랫폼을 가로질러 항상 일치한다는 것을 보장하는 데 도움을 준다. 하나의 장소에 있는 정보를 변화시키고, 그것을 자동적으로 ISP 와이드에 분산시키는 것은 현재의 ISP관리 프레임워크에서는 가능하지 아니한 강력한 도구이다.
서비스 생성 환경 2376에 의해 서비스 정의가 생성되면, 서비스 관리자 2378은 그것을 ISP 네트워크에 위치시키고, 네트워크가 새로운 서비스를 준비하도록 한다. 서비스를 위한 고객은 서비스 관리자를 통해 준비된다. 고객을 준비시키기 일부분으로써, 서비스 관리자는 자원 이용을 예상하고, 새로운 서비스가 고객의 서비스 사용을 취급하기 위해 부가될 필요가 있는 지를 결정한다. 그것은 그 결정을 위한 기초로써 현재사용 통계를 사용한다. 고객이 활성화되면, 서비스 관리자는 서비스가 충족되는 지 여부를 결정하기 위해 고객의 서비스 사용을 모니터링 한다. 고객의 서비스 사용이 증가함에 따라 서비스 관리자 2378은 자원을 ISP 네트워크에 부가할 필요가 있는 지의 여부를 예상한다. 이 서비스 관리 적절한 제한과 함께 다른 서비스에도 확장될 수 있다. 서비스 생성은 IN 세상의 이야기지만, 그것은 시스템의 나머지와 통합된, 그리고 이 모델의 목적의 하나인 서비스 관리자를 필요로 한다.
마지막으로 퍼스넬을 계획하기 위해 계획 관리자 2380은 ISP 와이드 자원 이용을 분석한다. 그리하여 미래의 요구를 결정하고, 미래의 서비스에 대한 가격결정을 위한 기초로써 서비스의 비용을 결정하기 위해 다른 서비스에 비용을 할당한다.
L. 물리 네트워크 모델
1. 소개
이 단락은 지능 서비스 플랫폼(ISP)의 물리 네트워크 논점을 기술한다.
a) 목적
물리네트워크 모델은:
·논리 아키텍쳐 맵핑(Mapping);
·정보 흐름; 및
·아키텍쳐의 생산 환경에 있어서 플랫폼 배치 등을 다룬다.
b) 범위
이 모델은 물리 네트워크와 관련된 용어를 정의하고, 다양한 도메인 사이의 상호작용을 기술하고, 아키텍쳐의 실현의 실시예를 제공한다.
c) 목표
이 모델의 목표는:
·다양한 네트워크를 식별하기 위해 모델을 생성하는 것;
·정보 흐름을 분류하는 것;
·표준 명명법을 제공하는 것;
·시스템 배치를 위한 규칙을 제공하는 것; 및
·미래의 테크널리지의 건설을 안내하는 것 등이다.
2. 정보 흐름
지능망(IN-Intelligent Network)의 주요한 논점의 하나는 네트워크에 설치된 다양한 플랫폼을 가로지르는 정보흐름이다. 정보의 형태를 식별하고 분류함에 의해, 네트워크는 IN의 요구를 제공한다. 일련의 호출 흐름에 있어서 고객은 IN과 상호작용한다. 호출은 음성 중심적(전통적 ISP 프로덕트에 있어서와 같이), 멀티미디어에 기초한(웹 브라우저를 사용하는 인터넷 MCI 유저에 있어서와 같이), 영상에 기초한(주문형 비디오에 있어서와 같이) 또는 이들의 조합일 수 있다.
정보는 다음과 같이 분류될 수 있다:
·내용;
·신호; 또는
·데이터.
일반적으로 IN과 상호작용하는 고객은 세 가지 정보흐름의 형태 모두를 요구할 것이다.
a) 내용
내용흐름은 이송되는 제일 중요한 정보를 가지고 있다. 이 예는 아날로그 음성, 패킷 교환 데이터, 연속적 영상, 및 전용회선 호출량 등이 있다. 이것은 IN이 최소 손실, 최소 잠재 및 최적의 비용을 통해 전달해야 하는 고객의 재산이다. 내용이 다른 정보와 함께 같은 채널에서 흐르게 하기 위해, IN 요소는 표준화되어 있기 때문에 이송망은 더 많은 연결성 줄을 지원한다.
b) 신호
신호 흐름은 네트워크에 의해 사용되는 제어정보를 가지고 있다. ISUP RLT/IMT, TCP/IP 도메인 이름 룩업 및 ISDN Q.931은 모두 이것의 예이다. IN은 이 정보를 요구, 사용, 및 생성한다. 신호 정보는 다양한 네트워크 플랫폼을 통합하고, 네트워크를 가로지르는 지능 호출 흐름을 가능하게 한다. 사실상 SCE에 기초한 IN에 있어서, 서비스 배치는 신호 정보가 망을 가로질러 흐를 것을 요구한다.
c) 데이터
데이터 흐름은 망 및 어떤 네트워크 플랫폼에 의해 생성된 중대한 요금 부과 데이터 기록을 포함하는 호출 흐름에 의해서 생성된 정보를 가지고 있다.
3. 용어
네트워크: 내용, 신호, 및/또는 데이터를 이송할 수 있는 상호연결된 일련의 네트워크 요소. MCI의 IXC 스위치 망, ISP 확장된 WAN, 및 인터넷 백본은 네트워크의 전형적 예이다. 현재의 설치들은 다른 네트워크 상에서 다른 내용을 전달하는 경향이 있다. 즉 그 각각은 특정한 내용 전송을 위해 전문화되어 있다. 테크널리지 및 고객요구 양자는 캐리어가 대부분 호출량에 보다 통일된 네트워크를 사용할 것을 요구한다. 이것은 망이 다른 내용 특징 및 프로토콜에 대해서도 같은 채널을 통해 허용할 것을 요한다. 이것의 다른 논점은 보다 단일한 내용에 독립적인 신호이다.
사이트: 같은 로컬 영역에 위치한 일련의 물리 엔티티. 현재의 ISP 아키텍쳐에서, 사이트의 예는 오퍼레이터 센터, ISNAP 사이트(ARU를 가지고 있다), 및 EVS 사이트 등이다. 정의에 의해, NT 및 DSC는 사이트가 아니다. 그들은 이송 네트워크의 일종이다. 아키텍쳐에서 지리적으로 함께 위치하며, 네트워크 인터페이스 및 링크를 따라 위치한 한 군의 서비스 엔진(SE), 특별 자원, 데이터 서버는 사이트를 형성한다.
네트워크 요소: 네트워크 인터페이스를 통해 이송 네트워크에 연결되는 물리 엔티티. 이 예는 ACP, EVS SIP, MTOC, 영상회의 예약 서버, DAP 트란잭션 서버, 및 NAS 등이 있다. 몇 년내에 웹서버, 영상 인증서버, 영상 스트리머, 및 네트워크 호출 기록 저장은 네트워크 요소에 포함될 것이다.
네트워크 인터페이스: 네트워크 요소와 이송네트워크를 연결하는 장비. DSI CSU/DSU, 10Base 이서넷 인터페이스 카드, ACD 포트 등은 네트워크 인터페이스이다. 바람직한 실시예의 아키텍쳐에 따르면, 네트워크 인터페이스는 통신을 위해 잘 이해되는 일련의 단일한 API를 제공해준다.
링크: 다른 사이트에 있는 둘 이상의 네트워크 인터페이스의 연결. 링크는 OC-12 SONET 파이버(fiber) 또는 100 mbps 이중 링 FDDI 섹션의 부분일 수 있다. 내년 내에 IN은 ISO 이서넷 WAN 허브 링크 및 기가 비트 속도의 OC- 48과 같은 네트워크 링크를 취급할 것이다.
연결: 같은 사이트에 있는 둘 이상의 네트워크 인터페이스의 연결.
도 38은 물리 네트워크 2400을 도식적으로 표현하고 있다. 사이트 2404에 네트워크 요소 2402를 가지고 있는 네트워크 2401은 네트워크 인터페이스 2406 및 하나이상의 게이트웨이 2408을 통해 상호연결되어 있다.
4. 엔티티 상호관계
도49에 표시되어 있는 엔티티 상호관계는 물리 네트워크 모델링 규칙이 존재한다. 이 규칙의 일부는 일반화되었으며, 다른 일부는 혼란을 방지하기 위해 정의가 제한되어 있다.
1. 네트워크 2401은 하나 이상의 사이트 2404에 걸치며, 하나 이상의 네트워크 요소를 가지고 있다.
2. 사이트 2404는 하나 이상의 네트워크 요소 2402를 가지고 있다.
3. 네트워크 요소 2402는 단지 하나의 사이트 2404에 위치하고 있다.
4. 링크 2420은 둘 이상의 사이트 2404를 연결한다.
5. 연결 2422는 둘 이상의 네트워크 요소를 연결한다.
6. 네트워크 요소 2402는 하나 이상의 네트워크 인터페이스를 가지고 있다.
바람직한 실시예는 MCI의 사무 고객을 위해서 프로덕트와 서비스 제공을 통합한다. 최초의 실시예는 한정된 프로덕트 세트에 중점을 두고 있다. 인터페이스에 대한 요구는 서비스의 통합에 이용하기 위해 식별되었다. 인터페이스는 유저에게 기능, 분산 목록 용량, 및 집중 메시지 데이터베이스에 대한 관리 가능성을 제공한다.
Ⅷ. 지능망
모든 플랫폼의 지원 서비스는 플랫폼에 통합되었다. 플랫폼의 통합은 서비스의 기능/작용성이 공통적 기능의 룩 앤드 필(look and feel)을 생성하도록 한다.
A. 네트워크 관리
아키텍쳐는 MCI 운영지원 그룹에 의해 원격 모니터링될 수 있도록 고안되었다. 이러한 원격 모니터링에 의해 MCI는;
·분해되고 파괴된 연결을 식별한다. 그 연결은:
- 정보(예; 객체)를 유니버설 인 박스에 전달하는 플랫폼, 서버, 또는 노드들 사이,
- 메시지를 검색하고 전달하는 것을 책임지는 플랫폼, 서버, 또는 노드들 사이,
- 유니버설 인박스(universal inbox)와 PC 클라이언트 메시지 인터페이스 사이,
- 유니버설 인박스(universal inbox)와 메시지 센터 인터페이스 사이.
- 프로파일 정보를 프로파일에 전달해야 하는 플랫폼, 서버, 또는 노드들 사이,
- 프로파일 정보를 ARU에 전달해야 하는 플랫폼, 서버, 또는 노드들 사이이다.
·분해된 응용 프로세스(application process)를 식별하고, 분해된 프로세스를 고립시킨다;
·하드웨어 오류를 식별한다; 및
·모든 응용 프로세스, 하드웨어, 또는 인터페이스 오류를 위해 MCI 모니터링 그룹에 의해 검출되고 수신될 수 있는 경보를 생성하는 것 등의 역할을 수행한다.
부가하여, 시스템 아키텍쳐 구성요소에 대한 원격 접속은 원격 모니터링 및 지원 그룹에 제공되어, 그들은 문제점의 이유를 고립하기 위한 원격 진단을 수행한다.
B. 고객 서비스
고객 서비스 팀은 모든 서비스를 지원한다. 고객 서비스는 연속적 방식으로 제공되고 아래의 사항을 포함하는 완전한 프로덕트 라이프 사이클을 포함한다:
·알파 테스트;
·베타 테스트;
·상업적 식별; 및
·고객 피드백(feed back) 또는 부가적 고객 지원 요구를 처리하는 것에 대한 확장의 식별.
포괄적이며 잘 정돈된 지원 절차는 처음부터 끝까지 완전한 고객 지원을 보장한다. 고객 서비스는 회계팀이 오더를 제출한 시점부터 고객이 회계를 취소할 때까지 제공된다. 포괄적이며 잘 정돈된 고객 지원은 아래의 사항을 수반한다:
·ARU 또는 VRU 문제점, WWW 브라우저 문제점, 또는 PC 클라이언트 문제점을 지원하는 원-스톱(one-stop), 직접접속, 고객 서비스 그룹;
·접속(VRU, WWW 브라우저, 또는 PC 클라이언트), 유저 인터페이스(ARU, WWW 브라우저, 또는 PC 클라이언트), 응용장치(APTLW 센터 또는 프로파일 관리), 또는 후위 시스템 인터페이스(유니버설 인박스, 직통회선 MCI 음성메일/팩스메일 플랫폼, 팩스 방송 시스템, 스카이텔(SkyTel) 페이징 서버, 오더 엔트리 시스템, 요금 부과 시스템, 등등) 등과 관련된 문제점을 진단하는 데 있어서 잘 훈련된 스탭;
·ARU 또는 VRU 용량, WWW 브라우저 용량, 식별된 하드웨어 송출 및 식별된 응용장치 송출에 관한 정보를 가진 데이터베이스에 대한 온라인 접속을 가진 스탭(staff);
·7 × 24 고객 지원;
·고객 서비스 그룹에 대한 직접 접속을 가진 하나의 무료번호(800 또는 888);
·대부분의 고장에 대한 제1, 제2 및 제3단계의 지원:
- 1단계 지원은 전화에 응답하는 지원이다. 이것은 고객에 의해 보고되는 가장 일반적인 질문 및 문제점을 해결할 수 있을 것으로 예상된다. 이 질문 및 문제점은 통상 접속 형태(ARU, WWW 브라우저, PC 클라이언트), WWW 브라우저 또는 PC 클라이언트를 위한 다이얼 업 통신, 설치 또는 베이직 컴퓨터(PC, 워크스테이션, 터미널) 하드웨어 질문 등을 다룬다. 부가적으로 트러블 티??(trouble ticket)을 열고 업데이트하고, 고객의 패스워드를 재활성화시킨다.
- 2단계 지원은 보다 숙련된 기술적 전문가가 필요한 경우 고객지원 그룹 내에서 제공된다;
- 3단계 지원은 문제점의 속성에 따라 고객 또는 내부 MCI 엔지니어링 또는 지원 그룹을 위하여 현장 하드웨어 지원을 위한 외부의 벤더를 포함한다.
- 4단계 지원은 시스템 엔지니어링 프로그래머에 의해 계속 제공될 것이다.
·수용 가능한 고객에게 보유 시간 및 포기 속도를 제공하는 수준을 책정하는 것;
·오더 엔트리 및 요금 부과 시스템에 대한 온라인 접속을 가진 스탭; 및
·송신 호출, 수신 호출의 평균 보유시간 및 열려진/닫혀진/올려진 트러블 티??에 관한 상세한 내용을 주말 보고하는 것.
C. 회계
회계는 현재의 MCI 절차에 의해 지원된다.
D. 위임
위임은 현재의 MCI 절차에 의해 지원된다.
E. 보고
보고는 수입 추적, 내부 및 외부 고객 설치/판매, 사용 및 프로덕트/서비스 실행을 위해 요구된다. 주말 및 월말 실천보고는 실천 하우스로부터 요구된다. 이 실천보고는 수신된 오더의 수 및 발송한 오더의 수와 상호관계시킨다. 부가하여, 보고는 WWW 사이트를 통해 프로파일 관리 또는 메시지 센터에 접속하는 다른 가입자의 번호를 식별한다.
F. 안전
안전은 MCI의 발행된 정책과 일치하도록 강제된다. 부가하여, 안전은 직통회선 MCI 프로파일, 메시지 센터, 개인 홍 페이지 캘린더, 및 개인 홈 페이지 구성에 대한 유저 접속을 증명하고 검증하기 위해 WWW 브라우저 및 ARU 인터페이스 옵션 내에 고안된다.
G. 장애 취급
문제점의 장애보고는 하나의 데이터베이스 내에 문서화되고 추적된다. 모든 장애는 네트워크 서비스 장애 취급 시스템 가이드라인에 따라서 지원된다. MCI 조직들 사이에서 정의된 어떤 서비스 수준 동의도 네트워크 서비스 장애 취급 시스템을 지원하기 위해 조직되어 있다.
소프트웨어 고정을 요하는 어떠한 장애도 장애 보고 데이터베이스에 접속되며, 문제점 추적 시스템 내에서 문제점 보고(PR - Problem report) 형태로 열린다. 이 문제점 추적 시스템은 모든 테스트 위상 중에 사용되고 모든 엔지니어링 및 지원 조직에 의해서 접속 가능하다.
Ⅸ. 교환된 개인 서비스
이 서술에서 아래의 용어가 사용된다.
Term: 표현하다.
서버: 하드웨어 및 TCP 서비스 양자.
웹서버: 네트스케이프 상업 서버 HTTP를 작동하는 AIX 4.2 시스템.
데몬(Daemon)
웰컴 서버(Welcome Server)
응용 서버(Application Server)
웰컴 서버로서 작동하는 웹서버는 안전 및 일반 모드 상태에서 네트스케이프 상업 서버 HTTP 데몬(Daemon)을 작동한다. 다양한 응용서버로 작동하는 웹서버는 단지 안전 모드에서만 데몬을 작동한다. 안전 모드는 SSLv2를 사용한다.
A. 웹서버 아키텍쳐
웹서버는 DMZ 내에 위치한다. DMZ는 웹서버 및 필요한 관련된 데이터베이스 클라이언트를 저장한다. 데이트베이스 클라이언트는 어떠한 데이터도 보유하고 있지 아니하나, 코퍼레이트 방호벽 뒤에 있는 데이터 레포지토리에 인터페이스를 제공한다.
웹공간은 이름 도출을 위해 라운드로빈 어드레싱(addressing)을 사용한다. 도메인 이름은 gallileo.mci.com 도메인을 위해 할당된 서브네트로 되어 있는 주소 공간을 가진 mci.com 도메인의 관리자에 등록된다.
도 40은 성공적 로그인으로 인도되는 사상의 연속을 보여준다.
1. 웰컴 서버 450
이 웹서버는 안전 및 일반 HTTP 데몬 양자를 작동한다. 이 서버의 중요한 기능은 로그인할 때 유저를 인증하는 것이다. 인증은 일반 및 안전 작동 모두 자바(Java) 및 스위치의 사용을 요한다. DMZ 내에는 하나이상의 웰컴 서버가 있다. 웰컴 서버에 의해서 제공되는 정보는 상태가 없다. 상태가 없다고 함은 복수의 웰컴 서버를 동기시킬 필요가 없음을 의미한다. 웰컴 서버의 최초 임무는 유저를 인증하는 것이다. 이것은 하나의 사용 토큰(TOKEN), 패스코드 인증, 및 호스타일 IP 필터링 등의 사용을 요한다. 토큰(TOKEN)의 사용은 토큰 서버 454를 사용함에 의해 행해지고, 패스코드 인증, 및 호스타일 IP 필터링은 직접적 데이트베이스 456 접속을 사용함에 의해 행해진다. 실패된 인증의 경우에는, 시도가 실패한 이유를 언급한 스크린(호스타일은 제외)이 유저에게 보여진다. 이 스크린은 유저를 최초의 로그인 스크린으로 자동적으로 보낸다.
성공적 인증 후 웰컴 서버 450의 마지막 임무는 서비스 선택 스크린을 유저에게 보내는 것이다. 서비스선택 스크린은 유저에게 적절한 응용 서버로 안내한다. 유저는 상기 응용을 선택하나, 서비스선택 페이지에 있는 HTML 파일은 응용서버를 결정한다. 이것은 웰컴서버 450이 기본적 로드(load) 균형을 유지하도록 한다.
DMZ 내에 있는 보든 웰컴 서버 450은 www.galileo.mci.com에 맵된다. DNS의 완성은 galileo.mci.com이 www.galileo.mci.com에 맵되도록 허용한다.
2. 토큰 서버 454
이것은 데이터베이스 클라이언트이지 웹서버는 아니다. 토큰 서버 454는 로그인 시도에 토큰을 발행하기 위해 웰컴 서버 454에 의해서 사용된다. 한때 검증된 발행된 토큰은 응용서버에 의한 연결을 위한 상태 정보를 추적하기 위해 사용된다. 토큰 정보는 코퍼레이트 방호벽 뒤에 있는 데이터 서버 456상의 데이터베이스 내에서 유지 보수하다.
토큰 서버 454는 아래의 임무를 수행한다:
1. 인증 위상 중에 하나의 사용 토큰을 발행한다.
2. 하나의 사용 토큰을 검증한다(다중사용을 위해 표시한다).
3. 다중-사용 토큰을 검증한다.
4. 다중-사용 토큰을 재검증한다.
토큰 서버는 유일한 토큰을 모든 새로운 접속에 발행할 것을 요한다. 이것은 발행된 토큰 값의 혼란을 피하기 위해 복수의 토큰 서버 사이에 통신 링크를 지정한다. 이 혼란은 각 토큰 서버 454에 영역을 할당함에 의해 제거될 수 있다.
토큰은 16개의 문자이며 이는 62개의 다양한 문자[0-9, A-Z, a-z]로 구성되는 군에서 선택된다. 토큰 서버에 의해서 발행되는 각 토큰에 있어서 0,1 및 2의 위치에 있는 문자는 고정되어 있다. 이 3개의 문자는 환경설정 시에 각 토큰 서버에 의해서 할당된다. 0위치의 문자는 물리 위치 식별자로 사용된다. 1위치의 문자는 서버를 식별한다. 최초에는 '0'인 2위치의 문자는 토큰 서버의 버전 번호를 식별하는 데 사용될 수 있다.
나머지 13개 문자는 전술한 62개의 문자를 사용하여 연속적으로 생성될 수 있다. 최초 시작 시에 토큰 서버는 현재 시스템의 시간을 15-10위치에 할당하고, 9-3위치의 문자를 '0'에 위치시킨다. 토큰 값은 그리고 나서 15-3위치에서 연속적으로 증가한다. 문자 부호는 'z-a', 'Z-A', '9-0'으로 갈수록 값이 작아지는 것으로 가정한다.
시스템 시간이 4바이트 값으로 계산된다면, 상기 구성은 15-10의 위치에서 62∧6에 해당하는 개수의 유일한 토큰을 생성한다. 다른 실시예에 의하면, 1초에 주어진 토큰 서버에 의해 상기 구성은 62∧7(35*10∧12) 보다 많은 토큰을 생성하지 아니한다.
토큰 영역의 사용은 표면적 동기 없이 도메인 내에서 복수의 토큰 서버의 사용을 허용한다. 이 방법은 최대 62개의 사이트를 수용하며, 각 사이트는 62개 정도의 토큰 서버를 가질 수 있다. 다른 실시예는 더 많은 사이트를 수용할 수 있다.
DMZ 내의 모든 토큰 서버는 token.galileo.mci.com에 맵된다. 최초의 실시예는 두 개의 토큰 서버를 가지고 있다. 이 토큰 서버는 물리적으로 웰컴서버와 동일하다. 즉 토큰 서비스 데몬이 같은 머신 상에서 작동하며, 상기 머신은 웰컴 서비스를 위한 HTTP 데몬을 작동한다.
웰컴 서버 450은 하나의 사용 토큰을 얻기 위하여 연결 인증을 하는 동안에 토큰 서버 454를 사용한다. 인증되면, 웰컴 서버 450은 토큰을 유효함을 표시하고, 그것을 다중사용을 위해 표시한다. 이 다중사용 토큰은 웰컴 서버에 의해 유저에게 송신되는 서비스 선택 스크린을 동반한다. 토큰 데이터베이스에 대한 고안은 아래에 상세히 설명되어 있다.
3. 응용 서버
응용서버는 유저 트란잭션을 담당하는 웹서버이다. 인증이 성공한 후 웰컴 서버의 마지막 임무는 서비스 선택 스크린을 유저에게 송신하는 것이다. 이 서비스 선택 스크린은 새로운 다중사용 토큰을 가지고 있다.
유저가 서비스를 선택할 때, 서비스 요구는 토큰을 내장한 채 적절한 응용서버에 보내어진다. 응용 서버는 토큰 서버를 사용하여 토큰을 검증하고, 유효하면 서비스가 제공된다. 토큰 서버는 같은 물리 사이트에 있는 토큰들이 발행한 토큰을 인증할 수 있다. 이것은 토큰 서버 454가 코퍼레이트 방호벽 뒤에 있는 하나의 데이터베이스 레포지토리 상에서 유지되는 데이터에 대한 데이터베이스 클라이언트이기 때문에 가능하다.
유효하지 아니한 토큰은 항상 "접속 거부" 페이지에 인도된다. 이 페이지는 웰컴 서버 450에 의해 제공된다. 접속 시도의 모든 거부는 로그된다.
응용서버의 실질적 작동은 응용 그 자체에 의존한다. DMZ내에 있는 응용서버는 ＜appName＞＜num＞.galileo.mci.com에 맵된다. 따라서 복수의 응용장치(예를 들면 프로파일 관리, 메시지 센터, 시작 카드 프로파일, 개인적 웹 공간 등)를 가진 하나의 실시예에서, 동일한 웰컴 및 토큰 서버 450 및 454가 사용되고, 더 많은 응용서버가 필요한 경우 부가된다.
다른 실시예는 같은 응용을 위한 더 많은 서버가 제공된다. 응용서버에 로드되는 작업이 그 용량을 초과할 경우에는 다른 웅용서버가 시스템의 변화를 수반하지 아니하고 부가된다. 서버 및 토큰 호스트 데이터베이스는 새로운 서버를 위한 기록을 부가하기 위하여 업데이트 된다. 호스트 이름의 ＜num＞부분은 응용서버를 구별하기 위하여 사용된다.
이 이름에 라운드 로빈(Round Robin)을 사용할 필요는 없다. 이 웰컴 서버 450은 서비스 선택 스크린을 보내기 전에 응용 서버의 이름을 결정하기 위하여 환경설정 테이블(시작 시에 로드되는 서버 데이터베이스)을 사용한다.
B. 웹서버 시스템 환경
모든 웹서버는 네트스케이프 상업 서버 HTTP 데몬을 실행한다. 응용 서버는 안전 모드 데몬만을 실행함에 비해 웰컴 서버 450은 일반 및 안전 모드 상태에서 데몬을 실행한다.
토큰 서버는 DMZ 내에서부터 연결하기 쉬운 잘 알려진 포트 상에서 작동하는 TCP 서비스를 실행한다. 토큰 서비스 데몬은 웰컴 서버 및 응용서버를 제외한 모든 시스템에 대한 접속을 거부하기 위해 tcp_포대를 사용한다. 이 인증 과정을 빨리 처리하기 위해, 모든 요구에 역 이름 맵핑을 사용하는 대신에 이 서비스에 의해 주소의 목록이 환경설정시에 로드된다. tcp_포대의 사용은 또한 토큰 서비스 활성화를 로그하기 위한 부가적 도구를 제공한다.
응용서버는 방호벽 뒤에 있는 데이터베이스 서비스를 위한 후위로써 작용한다. 중요한 임무는 토큰에 의해서 접속을 검증하고, 그 후 데이터베이스 요구를 검증하는 것이다. 데이터베이스 요구는 유저를 위해 생성, 업데이트, 현존하는 파일 또는 데이터 파일의 삭제하는 것이다. 응용 서버는 요구를 제공하기 전에 필요한 검증 및 권한 검사를 한다.
1. 웰컴 서버
웰컴 서버는 적절한 시점에 유저의 전면에 HTML 페이지를 제공한다. 이 페이지는 펄(Perl)에 기초한 공통 게이트웨이 인터페이스(CGI) 스크립트를 사용하여 생성된다. 이 스크립트는 HTTP 데몬의 일반 문서-루트(document-root) 디렉토리가 아닌 다른 디렉토리에 존재한다. CGI 스크립터가 유저에게 판독될 수 없도록 하기 위해서, 디렉토리 리스팅(listing)을 불가능하게 하고 모든 백업파일을 제거하는 것에 관한 예방조치가 취해져야한다. 도41은 웰컴 서버 450 상의 디렉토리 구조 455를 보여준다.
도41은 ＜문서-루트＞ 456이 ＜서버 루트＞ 458과 분리되어 있는 것을 보여준다. 이것은 또한 ＜문서-루트＞ 디렉토리가 접속 오류 및 웰컴 HTML 페이지만을 보유하고 있음을 보여준다.
HTTP 서버는 모든 요구를 요구되는 URL에 기초하여 "cgi" 디렉토리 460에 맵한다. CGI 스크립트는 HTML 출력을 유저에게 생성 및 송신하기 위하여 "탬플랫" ("template") 디렉토리 462로부터 HTML 템플릿을 사용한다.
＜문서-루트＞ 456으로부터 CGI 스크립트에 맵하기 위하여 URL의 사용은 악의의 유저에 의한 ＜문서-루트＞ 디렉토리 456에 대한 접속을 방해한다. 웰컴 서버에 대한 모든 접속이 웰컴 서버의 "cgi" 디렉토리에 있는 CGI 스크립트에 맵되기 때문에, 모든 스크립트의 시작 시에 인증 기능을 호출함에 의해 안전이 보장된다.
유저 인증 라이브러리(library)는 유저 식별을 인증하기 위해 펄(Perl)에서 발전된다. NASPI의 인정 위상 루틴은 토큰 검증 및 접속 모드 검출을 위해 서비스 그 자체에 기능을 부가한다.
웰컴 서버 450은 시작 시에 데이터베이스 456으로부터 운영 파라미터 정보를 그들의 환경에 입력한다. 복수의 웰컴 서버 상에서 같은 환경을 유지보수하기 위해서는, 이 정보를 공통 데이트베이스에 저장하고 있는 것이 필요하다.
a) 웰컴 페이지
웰컴 페이지는 웰컴 서버가 최초에 접속되었을 때 디폴트 페이지로 보내진다. 이것은 CGI 스크립터에 의해서 생성되지 아니하는 유일한 페이지이며, 이것은 ＜문서-루트＞ 디렉토리 456에서 유지 보수하다. 이 페이지의 역할은 다음과 같다:
·브라우저가 프레임을 디스플레이 할 수 있는지의 여부를 확인한다. 만약 브라우저가 프레임을 올바르게 디스플레이 할 수 없는 경우에, 이 페이지는 적절한 에러 메시지를 디스플레이하고 유저에게 마이크로소프트 인터넷 익스플로르(Explorer) V3.0 또는 그 후의 것을 다운로드할 것을 지시한다.
·브라우저가 자바를 실행할 수 있는 지의 여부를 확인한다. 실패할 경우에는 유저에게 마이크로소프트 인터넷 익스플로르 V3.0 또는 그 후의 것을 다운로드할 것을 지시한다.
·만약 브라우저가 성공적으로 프레임을 디스플레이하고 자바를 실행할 수 있다면, 이 페이지는 웰컴 서버 450이 로그인 페이지를 자동적으로 송신하도록 요구한다.
웰컴 페이지에 의한 세 번째 실행은 이 페이지에 내장된 자바 애플렛(JAVA Applet)에 의해 행해진다. 이것은 또한 유저 브라우저를 일반 모드에서 안전 모드로 전환한다.
b) 로그인 페이지
로그인 페이지는 cgi에 의해 생성된 페이지로서, 내장된 하나의 사용토큰, 자바 애플렛, 및 유저 ID 및 패스코드를 입력하기 위한 서식 필드를 가지고 있다. 이 페이지는 서비스를 강조하기 위해 그래픽을 디스플레이할 수 있다. 이 페이지의 처리과정은 인위적인 지연을 도입될 수 있다. 처음의 실시예에서 이 지연은 제로이다.
이 페이지로부터의 응답은 토큰, 애플렛에 의해 생성된 혼합된 토큰, 유저 ID 및 패스코드를 가지고 있다. 이 정보는 자바 애플렛에 의해 POST HTTP 요구를 사용하여 웰컴 서버에 보내어진다. POST 요구는 애플렛 사인을 가지고 있다.
만약 로그인 과정이 성공하면, 이 요구에 대한 응답은 서버 선택 페이지이다. 로그인 과정이 실패하면, 접속 실패 페이지로 안내된다.
c) 서버 선택 페이지
로그인 페이지는 cgi에 의해 생성된 페이지로서, 내장된 다중사용 토큰을 가지고 있다. 이 페이지는 또한 유저에게 유용한 서비스의 형태를 지시하기 위해 하나 이상의 그래픽을 보여준다. 몇몇 서비스는 우리의 유저에게 접속될 수 없다. 다른 실시예에서, 하나 이상의 서비스가 존재할 때, 유저 ID에 의해 조율된 유저 서비스 데이터베이스가 이 페이지를 생성하기 위하여 사용될 수 있다.
웰컴 서버는 모든 유용한 응용 서버들 사이에서 로드를 분할할 목적으로 적절한 응용서버의 이름을 내장하기 위해 이 구성정보를 이용한다. 이 로드 분할은 시작 시에 웰컴 서버에 의해 읽혀지는 환경설정 데이터에 의해 행해진다.
웰컴 서버는 각 서비스에 대한 환경설정 파일에 대한 엔트리를 기초로 하여 응용 서버를 선택한다. 이 엔트리는 선택될 개연성에 기초하녀 각 응용을 위한 응용서버의 이름을 목록화한다. 이 환경설정 테이블은 시작 시에 웰컴서버에 의해서 로드된다.
d) 접속 실패 페이지
접속 실패 페이지는 정적인 페이지이다. 이것은 유저 ID의 에러에 의해 로그인이 실패하였음을 나타내는 메시지를 디스플레이한다. 이 페이지는 15초 후에 자동적으로 로그인 페이지를 로드한다.
e) 접속 거부 페이지
접속 거부 페이지는 인증의 에러에 의해 로그인이 실패하였음을 나타내는 메시지를 디스플레이하는 정적인 페이지 한다. 이 페이지는 15초 후에 자동적으로 로그인 페이지를 로드한다. 접속 거부 페이지는 그 인증 서비스가 토큰을 인식하는 것이 실패하였을 때 응용서버에 의해서 호출된다. 이 페이지의 모든 로드는 로그되고 모니터링 된다.
2. 토큰 서버 454
웹사이트에서의 토큰 서비스는 토큰 생성 및 인증을 위한 유일한 소스이다. 토큰은공용 데이터베이스 456에 의해 저장된다. 토큰 데이터베이스는 DMZ 외부의 방호벽 뒤에 있다.
토큰 서비스는 잘 알려진 TCP 포트 상에서 서비스를 제공한다. 이 서비스는 신뢰받는 호스트에게만 제공된다. 신뢰받는 호스트의 목록은 환경설정 데이터베이스에서 유지 보수하다. 이 데이터베이스는 DMZ 외부의 방호벽 뒤에서 유지 보수하다. 토큰 서비스는 단지 시작 시에만 새롭게 하고자 하는 신호를 받았을 때만 환경설정 데이터베이스를 읽는다. 토큰 서비스는:
·로그인 시도에 대한 하나의 사용 토큰을 부여하는 것;
·하나의 사용 토큰을 검증하는 것;
·토큰을 검증하는 것; 및
·토큰을 재검증하는 것 등이다.
토큰 노화는 토큰 서비스의 로드를 감소시키기 위하여 분리된 서비스에 의해 이행된다.
토큰 서버에 대한 모든 접속은 로그되고 모니터링 된다. 토큰 서비스 그 자체는 MCI의 내부 안전 그룹으로부터 가동될 수 있는 tcp_포대 코드를 사용하여 쓰여진다.
3. 프로파일 관리 응용 서버
프로파일 관리 응용 서버는 처음의 실시예에서 실행되는 유일한 형태의 응용서버이다. 이 서버는 웰컴 서버와 같은 디렉토리에 있다. 이것은 필요한 경우 같은 시스템이 양자의 서비스를 제공하기 위해 사용되도록 한다.
C. 안전
가입자에 의해 웹서버에 기탁되는 데이터는 그들에게는 민감하다. 그들은 가능하면 그것을 보호하려고 한다. 가입자들은 웹서버를 통해 이 민감한 정보에 접속한다. 이 정보는 물리적으로 하나 이상의 데이터베이스 서버에 존재할 수 있으나, 가입자에 관한 것이라면 그것은 서버 상에 있으며, 보호되어져야 한다.
현재에는 단지 아래의 정보만이 하나의 실시예에서 보호될 필요가 있다.
다른 실시예에서 이메일, 음성메일, 영상메일, 및 개인 홈 페이지 정보를 포함한 직통회선 회계 부가적 정보에 대한 프로파일 정보가 보호된다.
아래 유형의 침입자에 대한 보호가 행해진다:
·웹에 접속하는 사람;
·다른 가입자;
·MCI 퍼스넬;
·가입자의 네트워크에 접속하는 사람;
·가입자의 시스템에 접속하는 사람;
·가입자를 도용하는 사람; 및
·서버로 가장하는 다른 시스템.
아래의 구성을 사용하여 안전에 대한 계획이 성취된다:
·로그인 시도를 위한 하나의 사용 토큰;
·검증된 토큰은 모든 트란잭션을 수반한다;
·10분 동안 사용하지 아니할 경우 토큰을 무효화하는 토큰 노화;
·토큰은 호출 머신의 IP 주소와 관련이 있다. 따라서 토큰 도용은 쉬운 옵션이 아니다;
·SSL의 사용은 고객의 디스플레이에 물리 접속을 하지 아니하고도 토큰 또는 데이터의 도용을 방지한다;
·네트스케이프 쿠키(Cookie)와 유사한 형태의 토큰 사용은 후일 쿠키를 교체할 수 있는 옵션을 제공한다. 쿠키는 토큰을 여분의 안전층을 위한 문서 속으로 숨길 수 있는 편의를 제공해준다; 및
·침입자에게 간파됨이 없이 복수의 침입자를 방어하기 위해 호스타일 IP 테이블의 사용.
상기 언급한 토큰에 의해 성취된 안전에 부가하여, 웹서버는 또 다른 안전을 위하여 데이터 관리 지역 (DMZ)에 있다. DMZ 안전은 아래에 기술되어 있다.
D. 로그인 프로세스
도42는 로그인 프로세스를 보여준다. 성공적 로그인을 이끄는 사상(event)의 연속은:
1. 유저는 www.galileo.mci.com에 대한 연결을 요구한다;
2. DNS 라운드 로빈을 사용하여 일련의 서버에서 하나의 서버가 선택된다.
3. HTML 페이지가 유저의 브라우저에 보내어진다.
4. 페이지는 자바 순응을 위해 브라우저를 검사하고 웰컴 메시지를 디스플레이한다.
5. 브라우저가 자바에 순응하지 아니하다면, 프로세스는 적절한 메시지와 함께 멈춘다.
6. 브라우저가 자바에 순응한다면, 그것은 "로그인 스크린 읽기" 요구를 www.galileo.mci.com 서버에 자동적으로 발행한다. 이 요구는 브라우저를 SSL v2로 전환한다. 이것은 브라우저가 SSL에 순응하지 아니하면 실패한다.
7. 웹서버는 아래의 사항을 수행한다:
A. 웹서버는 하나의 사용토큰을 그 내부의 토큰 서비스로부터 얻는다.
B. 웹서버는 일련의 애플렛으로부터 하나를 선택한다.
C. 웹서버는 애플렛, 토큰, 및 클라이언트 IP 주소를 데이터베이스에 기록한다.
D. 웹서버는 애플렛 및 토큰과 함께 로그인 스크린을 다시 보낸다.
8. 유저는 로그인 스크린 필드에 유저 ID 및 패스코드를 입력한다.
A. 유저 ID는 유저의 직통회선 번호이다(유저의 사업 카드에 인쇄되고 공용 도메인에 있다).
B. 패스코드는 유저에게만 알려진 6자리 디지트 번호이다.
9. 유저가 엔터를 누르면(또는 로그인 버튼을 클릭하면), 자바 애플렛은 유저 ID, 패스코드, 토큰, 및 혼합된 토큰을 다시 보낸다. 스크램블링 알고리즘은 스텝 7D에서 송신되는 애플렛에 특정되어 있다.
10. 브라우저의 IP 주소가 호스타일 IP 테이블에 있으면, 서버는 단계 7로 되돌아간다.
11. 웹서버는 로그인 요구를 단계 7C에서 기록된 것과 비교하여 인증한다.
12. 테스트가 유효하지 아니하면: 만약 이것이 같은 IP 주소에서의 세 번의 연속적 실패된 시도라면, 서버는 상기 주소를 호스타일 IP 주소에 기록한다.
13. 서버는 단계 7로 되돌아간다.
14. 테스트가 유효하면, 서버는 브라우저에게 내장된 토큰과 함께 선택 서비스를 보낸다. 토큰은 브라우저의 IP 주소와 관련되어 있지만, 그것은 이제 만료된다.
E. 서비스 선택
유저가 서비스 선택 스크린으로부터 옵션을 선택할 때, 요구는 토큰에 의해 수반된다. 도43에서 보이는 바와 같이, 토큰은 서비스가 접속되기 전에 검증된다.
F. 서비스 운영
응용서버에 의해 생성된 모든 스크린은 로그인 프로세스가 시작되었을 때 유저에게 발행된 토큰을 가지고 있다. 이 토큰은 내장된 만료 시간 및 유효 소스 IP 주소를 가지고 있다. 모든 운영 요구는 이 토큰을 요구의 일부분으로 가지고 있다.
서비스 요구는 브라우저에 의해 HTML 형태, 애플렛에 기초한 형태, 또는 하이퍼 링크(Hyper Link) 형태 등으로 보내어진다. 처음 두 예에서는, 토큰은 HTTP-POST 방법을 사용하여 히든 필드(hidden field) 형태로 다시 보내어진다. 하이퍼 링크는 내장된 토큰을 가진 HTTP-GET 방법을 사용하거나, 토큰을 대신하여 쿠키(Cookie)를 사용한다. 토큰의 포맷은 이 접근과 호환될 수 있도록 신중히 선택된다.
1. NIDS 서버
시스템에서 NIDS 서버는 라우터에 기초한 방호벽에 의해 웹서버로부터 고립된다. NIDS 서버는 NIDS 서버 상의 데이터베이스에 대한 TCP 클라이언트 접속을 허용하는 NIDSCOMM 및 ASCOM 서비스를 실행한다. NIDSCOMM 및 ASCOM 서비스는 NIDS 서버 상에 물리적으로 위치하지 아니한 데이터베이스에 대한 연결을 허용하지 아니한다.
NIDS 서버 상의 아래의 데이터베이스(C-트리 서비스)가 웰컴 서버, 토큰 서버 및 프로파일 관리 응용 서버에 의해 사용된다:
·800_PIN-1CALL(이것은 분할 데이터베이스이다);
·1CALL_TRANS;
·COUNTRY;
·COUNTRY-SET;
·COUNTRY29(maybe);
·COUNTRY-CITY(maybe);
·NPA_CITY;
·NPACITY_OA300(maybe); 및
·OP153T00.
상기 C-트리 서비스에 부가하여, 새로운 C-트리 서비스가 SERVDEF 내에서 정의될 수 있으며, 시스템에 전용된 NIDS 서버 상에서만 사용될 수 있다.
·토큰(TOKEN);
·서버(SERVERS);
·호스타일_IP(HOSTILE_IP);
·토큰_호스트(TOKEN_HOSTS); 및
·SERVER_ENV.
이 데이터베이스에 대한 아래의 기술은 각 기록의 최초 바이트에 요구되는 무명 필드(filler field)를 보여주지 아니하고, 또한 4-바이트 경계를 따라 구조 맞춤을 위해 요구되는 다른 무명 필드를 보여주지 아니한다. 이 생략은 단지 간략화를 위해서 이다. 필드 정의의 다음에 위치한 괄호 속의 숫자는 필드 값을 보유하기 위해 요구되는 바이트 수이다.
2. 토큰 데이터베이스 서비스
토큰 데이터베이스 서비스는 토큰 서버에 의해서 접속된다. 이 서비스의 중요한 기능은 새로운 기록을 생성하는 것, 주어진 토큰 값에 대한 기록을 읽는 것, 및 주어진 토큰 값에 대한 기록을 업데이트 하는 것이다.
NIDS 상에서 작동하는 분리된 크론 잡(chron job) 그 자체는 이 데이터베이스에 접속하고, 쓸모 없는 기록을 삭제한다. 이 크론 잡은 매 시간 작동한다. 이것은 데이터베이스에 대한 연속적 스캔을 행하고 만료된 토큰에 대한 기록을 삭제한다.
토큰 데이터베이스 서비스는 토큰 기록을 가지고 있다. 토큰 기록은 하나의 키를 사용하고 아래의 필드를 가진다:
1. 버전(1);
2. 프래그(flag)(하나/다중) 사용(1);
3. 토큰 값(16);
4. IP 주소(16);
5. 유저 ID(16);
6. 부여된 시간(4); 및
7. 만료된 시간(4).
주요한 필드는 토큰 값이다.
3. 서버 데이트베이스 서비스
서버 데이트베이스 서비스는 환경 설정시에 웰컴서버에 의해서 접속된다. 이 데이터베이스의 기록은 아래의 필드를 가지고 있다:
1. 응용 이름(16);
2. 응용서버 호스트 이름(32);
3. 응용서버 도메인 이름(32);
4. 가중치(weight)(1);
5. 응용 아이콘 파일 URL(64); 및
6. 응용 기술 파일 URL(64).
주요한 필드는 응용 이름, 서버 호스트 이름, 서버 도메인 이름의 조합이다. 이 데이터베이스는 웰컴 서버에 의해서 연속적으로 읽혀진다. 이 데이터베이스는 기록을 생성, 읽기, 업데이트, 및 삭제하기 위해서 웹 관리자에 의해 접속된다. 이 접속은 ASCOMM 인터페이스에 의해 접속된다. 웹관리자는 그 관리 임무를 위해 HTML 형태 및 CGI 스크립터를 사용한다.
4. 호스타일_IP 데이터베이스 서비스
이 데이터베이스는 IP 주소에 기초하여 새로운 기록을 생성하거나 현재의 기록을 읽기 위해서 웰컴 서버에 의해서 접속된다. 이 읽기 접속은 종종 일어난다. 이 데이터베이스 파일은 아래의 필드를 가지고 있다:
1. IP 주소(16);
2. 입력된 시간(4); 및
3. 만료된 시간(4).
주요한 필드는 IP 주소이다. 위 세 개의 값은 새로운 기록을 생성할 때 웰컴 서버에 의해서 정해진다. 만약 상기 엔트리가 번복될 경우에는, 번복하는 서비스는 만료된 시간 값을 ＜epoch_start＞로 변화하는 것만이 허용된다. 따라서 엔트리를 번복하도록 신호한다.
이 데이터베이스는 기록을 생성, 읽기, 업데이트, 및 삭제하기 위해서 웹 관리자에 의해 접속된다. 이 접속은 ASCOMM 인터페이스에 의해 접속된다. 웹관리자는 그 관리 임무를 위해 HTML 형태 및 CGI 스크립터를 사용한다.
고객 서비스는 이 데이터베이스에 접속하기 위해 특별히 진전된 도구를 사용하며, 접속은 단지 코퍼레이트 방호벽 내에서부터 허용된다.
NIDS 상에서 작동하는 크론 잡(chron job)은 또한 이 데이터베이스에 접속하고, 쓸모 없는 기록을 삭제한다. 이 크론 잡은 모든 그 활성화를 로그한다. 이 로그는 항상 웹 관리자에 의해 종종 실행된다.
5. 토큰_호스트 데이터베이스 서비스
토큰_호스트 데이터베이스 서비스는 토큰 서버에 의해서 신뢰되는 호스트의 IP 주소를 목록화한다. 이 데이터베이스는 토큰 서비스에 의해 환경설정시에 읽혀진다. 이 데이터베이스내의 기록은 아래의 필드를 가자고 있다:
1. IP 주소(16);
2. 권한(1);
3. 호스트 이름(32);
4. 호스트 도메인 이름(32);
5. 호스트 기술(64).
주요한 필드는 IP 주소이다. 권한 2진수 프래그는 접속 수준을 결정한다. 저수준의 접속은 단지 현재의 토큰에 대한 검증/재검증 명령만을 허용한다. 고수준의 접속은 하나의 사용 토큰을 부여 및 검증하는 명령도 제공한다.
이 데이터베이스는 기록을 생성, 읽기, 업데이트, 및 삭제하기 위해서 웹 관리자에 의해 접속된다. 이 접속은 ASCOMM 인터페이스에 의해 접속된다. 웹관리자는 그 관리 임무를 위해 HTML 형태 및 CGI 스크립터를 사용한다.
6. SERVER_ENV 데이터베이스 서비스
이 데이터베이스 서비스는 웰컴 및 응용 서버에 의해서 시작 시에 읽혀진다. 이것은 이 서버를 위해 시작 환경을 정의한다. 하나의 실시예에서, 단지 하나의 필드(및 단지 웰컴 서버만을 위해)만이 사용되는 것으로 고안된다. 이것은 다른 실시예에서 확장된다.
이 데이터베이스가 가지고 있는 기록은 아래의 필드이다:
1. 순서번호(4);
2. 응용 이름(16);
3. 환경 이름(32); 및
4. 환경 값(64).
주요한 필드는 순서번호이다. 환경 값은 환경이름에 의해 다른 환경 변수에 참고될 수 있다. CGI 스크립트에 의해 이 값은 적절한 실행 시간에 평가된다. 웰컴 서버는 가짜의 응용이름 "웰컴"이 할당된다.
이 데이터베이스는 기록을 생성, 읽기, 업데이트, 및 삭제하기 위해서 웹 관리자에 의해 접속된다. 이 접속은 ASCOMM 인터페이스에 의해 접속된다. 웹관리자는 그 관리 임무를 위해 HTML 형태 및 CGI 스크립터를 사용한다.
7. 크론 잡(chron job)
NIDS 서버는 크론 잡을 실행한다. 이 잡은 매 시간 실행하도록 계획되어 있다. 이 잡의 주요한 임무는 아래와 같다:
1. 호스타일 IP 데이터베이스를 스캔하고, 모든 기록에 대한 상황을 보고한다. 이 보고는 모든 기록을 가지고 있다. 반복되는 침입자에 대한 추적의 목적은 이 보고에 기초한다.
2. 호스타일 IP 데이터베이스를 스캔하고, 만료 시간으로서 ＜epoch_time＞을 가진 기록에 대한 상황을 보고한다.
3. 호스타일 IP 데이터베이스를 스캔하고, 쓸모 없는 기록을 삭제한다.
4. 토큰 데이터베이스를 스캔하고, 모든 기록에 대한 상황을 보고한다. 이 보고 포맷은 각 엔트리를 스캔하기 보다는 호출량 보고에 연결된다.
5. 토큰 데이터베이스를 스캔하고, 쓸모 없는 기록을 삭제한다.
G. 표준
아래의 코딩 표준에 발전되었다:
1. HTML 룩 앤드 필 표준;
2. 자바 룩 앤 필 표준(HTML 룩 앤 필 표준으로부터 파생되었고 이것은 사이트의 페이지에 공통 룩 앤드 필을 강요하기 위해 사용되는 새로운 계통의 라이브러리(library)이다); 및
3. HTML프로그래밍 표준.
H. 시스템 관리
시스템 관리 임무는 시스템 관리자에 대한 적어도 아래의 시스템 운영 파라미터의 보고를 요구한다:
·시간 소인이 찍힌 시스템 상태 및 디스크 사용;
·시간 소인이 찍힌 네트워크 운영 파라미터;
·시간 소인이 찍힌 웹 페이지 사용 및 접속 통계;
·토큰 사용 통계;
·호스타일_IP 경보 및 통계;
아래의 도구 및 유용물이 DMZ 서버 상에 있다:
·시간 동기;
·도메인 이름 서버;
·시스템 로그 모니터링;
·알람 보고; 및
·아전 셀.
시스템은 아래의 상황에 대해서 알람을 생성한다;
·토큰의 부정확한 사용;
·호스타일_IP 테이블 변경;
·토큰 만료; 및
·로그인 시도.
이 알람은 다른 수준으로 생성될 것이다. 웹서버는 아래의 개략적 가이드라인을 사용한다.
1. 서버는 루트 환경 내에서 작동한다.
2. 관리자는 공개되는(새로운) 서비스를 테스트하기 위해서 비표준 포트 상에서 공개되는 서버를 시작시킬 수 있다.
3. 공개되는 서버는 시작 작동 중에 인터넷으로부터 접속 가능하다.
4. 관리자는 공개되는 소프트웨어를 숙영지에서 생산지로 하나의 명령을 사용하여 이동시킬 수 있는 옵션을 가지고 있다. 이것이 우연히 일어난 것이 아님을 확인하기 위한 적절한 검사가 있다.
I. 프로덕트/확장
바람직한 실시예는 그래피컬 유저 인터페이스를 제공함에 의해 직통회선 MCI 고객이 그들의 프로파일에 대한 부가적 제어를 가능하게 하고, 공통 메시지 시스템에 대한 제어도 가능하게 한다. 바람직한 실시예의 능력에 접속할 수 있는 용량은 직통회선 MCI 프로파일 및 공통 메시지 시스템의 형태로 존재한다. 유저는 기능/작용성을 업데이트함에 그의 응용장치를 보완할 수 있다. 이 응용장치는 바람직한 실시예의 통합에 의해 제공되는 미래의 용량을 가능하게 할 것이다.
유저는 단지 하나의 위치와 연결함에 의해 그의 모든 메시지를 접속할 수 있다. 팩스, 이메일, 페이지 및 음성 메시지는 집중메시지 인터페이스를 통해 접속될 수 있다. 메시지를 검색하기 위해, 유저는 메시지 센터 인터페이스를 통해 집중메시징 인터페이스를 호출할 수 있다. 집중메시지 인터페이스는 유저에게 통신을 쉽고 효율적으로 관리할 수 있게 한다.
유저 인터페이스는 두 개의 구성요소, 즉 유저의 응용 프로파일 및 메시지 센터를 가지고 있다. 인터페이스는 PC 소프트웨어(즉 PC 클라이언트 메시지 인터페이스), ARU, VRU, WWW 브라우저를 통해 접속 가능하다. 인터페이스는 응용장치의 상용화 및 메시지의 관리를 지원한다.
실시예를 위한 기능/작용성 필요조건은 아래에 제시되어 있다. VRU 인터페이스 및 그것의 용도, 즉 유저 인터페이스, 메시지 관리 및 프로파일 관리가 최초에 기술되어 있으며, WWW 브라우저 및 PC 클라이언트 인터페이스가 그 후에 기술되어 있다.
J. 인터페이스 기능 필요조건
전위는 유저 및 스크린 디스플레이 서버 사이에 있는 인터페이스로 작용한다. 유저는 시스템에 접속하여 그의 프로파일 및 메시지를 접속할 수 있다. 유저 인터페이스는 프로파일을 업데이트하고 그의 메시지를 접속하기 위해 사용된다. 유저의 프로파일 정보 및 유저의 메시지는 다른 위치에 있을 수 있으며, 따라서 인터페이스는 양위치를 연결할 수 있어야 한다. 프로파일 및 메시지 용량은 인터페이스의 개별적 구성요소이며, 서로 다른 필요조건을 가지고 있다.
유저 인터페이스를 통해, 유저는 실행시간 내에 그의 프로파일을 프로파일 관리를 통해 업데이트할 수 있다. 응용 프로파일은 유저 회계 디렉토리 전위에 있으며, 그곳에서 모든 유저 회계 정보가 가상의 위치에 놓여 있다. 또한 유저는 그의 메시지 센터를 통해 그의 메시지(음성메일, 팩스메일, 이메일, 페이저 재호출)를 관리할 수 있다. 이 메시지 센터는 집중메시지 데이터베이스 전위에 있으며, 이곳에서 메시지의 내용에 관계없이 모든 유저의 메시지가 놓여진다.
3개의 유저 인터페이스가 지원된다:
·ARU 또는 VRU에 대한 DTMF 접속;
·WWW 사이트에 대한 WWW 브라우저 접속; 및
·메시지 서버에 대한 PC 클라이언트 접속.
ARU로부터 유저는 프로파일을 업데이트하고, 음성메일 메시지 및 페이저 재호출 메시지를 검색하고, 팩스메일 및 이메일에 대한 메시지 헤더(송신자, 주제, 날짜/시간) 정보를 검색한다. PC 클라이언트를 통해 유저는 메시지 검색 및 메시지 조작에 한정된다. WWW 브라우저는 유저에게 프로파일 관리 및 메시지 검색을 위한 포괄적 인터페이스를 제공한다. WWW 브라우저를 통해 유저는 그들의 프로파일(직통회선 MCI, 정보 서비스, 목록 관이, 글로벌 메시지 취급, 개인 홈 페이지)을 업데이트하고 모든 형태의 메시지를 검색한다.
1. 유저 회계 프로파일
유저는 응용프로파일을 통해 회계정보에 접속할 수 있다. 유저 회계 디렉토리에 있는 응용프로파일은 유저와 그의 회계정보 사이에 지능 인터페이스를 제공한다. 유저 회계 디렉토리는 개개의 유저의 회계정보를 접속한다. 유저들은 그들의 회계를 업데이트하기 위해 디렉토리를 읽고 쓸 수 있다. 디렉토리는 고객 서비스 대리인이 고객을 도와줄 때 특정한 회계를 찾는 것을 가능하게 하는 검색 기능을 제공한다.
고객이 전화번호를 입력하면, 유저 회계 정보는 그 등록을 반영하고, 유저는 그의 유저 회계 프로파일을 통해 접속하고 기능을 업데이트할 수 있다. 만약 고객이 취소한다면, 유저 프로파일 디렉토리는 정보는 이것을 반영하고, 서비스는 유저의 응용 프로파일에서 제거될 것이다.
요약하면, 유저 회계 디렉토리는 유저의 서비스 각각에 대한 회계정보를 제공한다. 그러나, 유저 회계 디렉토리는 직통회선 MCI 프로파일, 정보 서비스 프로파일, 글로벌 메시지 취급, 목록 관리 및 개인 홈 페이지 프로파일 등에 한정하는 것은 아니다. 이 정보는 유저의 응용장치에 대한 기능/작용성을 결정하고, 유저에게 그의 응용장치를 상용화하는 데 필요하며, MCI가 그의 지속적으로 변화하는 통신 요구를 충족시키게 하는 확장성을 제공한다.
3. 메시지의 데이터베이스
메시지의 통합은 중요한 기능중의 하나이다. 유사내용 또는 비유사내용의 메시지는 하나의 가상의 위치에서 통합된다. 호출을 통해 메시지 센터는 내용 또는 접속에 상관없이 유저에게 그의 메시지의 개관을 제공한다. 인터페이스 메시징(messaging) 용량을 통해 유저는 주소록 및 분산 목록을 유지 보수할 수 있다.
이 메시지 데이터베이스는 중앙 집중 정보 기억장치이며, 유저를 위한 메시지를 저장한다. 메시지 데이터베이스는 공통 객체 저장 용량을 제공하고, 데이터 파일을 객체로 저장한다. 메시지 데이터베이스에 접속함에 의해 유저는 음성메일, 팩스메일, 이메일, 페이저 재호출 메시지 등을 검색한다. 부가하여, 공통 객체 저장 용량을 사용함에 의해, 메시지 분산은 매우 효율적이다.
K. 자동응답 장치 (ARU) 용량
1. 유저 인터페이스
ARU 인터페이스는 직통회선 MCI 프로파일 관리, 정보 서비스 프로파일 관리, 메시지 검색 및 메시지 분산을 수행할 수 있다. ARU를 통해 제공되는 DTMF 접속은 시스템 내에 있는 다른 구성요소를 가로질러 지속적으로 적용된다. 예를 들면 DTMF 키패드를 통한 알파벳 문자의 입력은 유저가 주식 시세 정보 또는 분산 목록에 팩스 메시지를 방송하는 것에 접속하는지에 관계없이 같은 방식으로 행해진다.
음성메일 콜백 자동 재다이얼은 DTMF 음성메일을 남기는 게스트로부터 콜백 번호를 남길 것을 촉구 및 수집하고, 메시지를 검색했을 때 게스트의 콜백 번호로 자동적으로 회답 호출을 보내는 용량을 제공한다. 콜백을 마치는 즉시, 가입자는 원래의 위치로 되돌아갈 수 있다.
음악 온-홀드(On-Hold)는 게스트가 전화를 끊지 않고 기다리는 동안 음악을 제공한다.
파크 앤드 페이지(Park and Page)는 게스트에게 게이트웨이를 통해 직통회선 MCI 가입자에게 페이지할 수 있고, 가입자가 페이지되는 동안에 끊지 않고 기다리는 옵션을 제공한다. 가입자는 페이지를 검색하고 끊지 않고 기다리는 게스트와 연결할 것인지를 선택할 수 있는 자신의 직통회선 MCI에 호출한다. 가입자가 게스트와 호출을 연결하는 것을 실패한다면, 게스트는 음성메일을 남길 수 있는 옵션을 수신한다. 만약 가입자가 정의된 옵션과 같은 음성메일을 가지고 있지 아니하다면, 게스트에게 종료의 메시지가 전달될 것이다.
※ 주의 : 게스트는 끊지 않고 기다리는 동안 음성메일을 남길 수 있는 옵션을 언제나 선택할 수 있다.
파크 앤드 페이지를 탑재한 호출 스크리닝(Call Screening)은 가입자에게 파크 앤드 페이지에 대해 게스트에게 응답할 수 있는 기능을 제공한다. 이것은 가입자에게 호출을 연결하기 전에 그들이 게스트에게 이야기할 것인지 또는 음성메일을 남길 것인 지의 여부를 선택할 수 있는 기능을 제공한다. 특히, 게스트는 파크 앤드 페이지 옵션을 선택할 때, ARU에 의해 그들의 이름을 기록하도록 촉구된다. 가입자가 파크 앤드 페이지에 응답할 때, ARU 프롬프트가 "당신은 누구로부터 호출을 받았습니다"라는 말을 듣게 되고, 호출자와 연결하거나 음성메일을 전송하는 옵션을 제공받게 된다. 만약 가입자가 정의된 옵션과 같은 음성메일을 가지고 있지 아니하다면, 게스트에게 종료의 메시지가 전달될 것이다. 게스트는 끊지 않고 기다리는 동안 음성메일을 남길 수 있는 옵션을 언제나 선택할 수 있다.
양방향 페이저 환경설정 제어 및 파크 앤드 페이지에 대한 응답
상기 시스템은 또한 ARU가 호출을 음성메일 또는 최종 메시지에 호출을 라우팅하는 것을 지시함에 의해 또는 보류를 계속할 것임을 지시함에 의해, 양방향 페이저에 의해 제출되는 명령을 통해 가입자가 파크 앤드 페이지 통지에 응답하는 것이 허용된다.
테스트 페이저 지원
상기 시스템은 가입자가 게이트웨이를 통해 직통회선 MCI 가입자를 페이지할 수 있고, 텍스트 페이저에 의해 검색되는 메시지를 남기는 것을 허용한다. 구체적으로는, 적절한 옵션을 선택하면, 게스트는 네트워크 MCI 페이징 또는 스카이텔 메시지 센터로 전송되고, 그곳에서 오퍼레이터는 가입자의 텍스트 페이저에 의해 검색되는 텍스트에 기초한 메시지를 수신하고 생성한다.
착신 전환
이 시스템은 직통회선 MCI 호출이 라우팅된 전화의 수신자가 직통회선 MCI 라우팅 순서에 따라 다음 착신 번호로 호출을 라우팅할 수 있는 옵션을 제공해준다. 특히 피호출자는 직통회선 MCI ARU 게이트웨이로부터 프롬프트를 수신한다. 이 프롬프트는 호출이 직통회선 MCI에 의해 상기 피호출자의 번호로 라우팅 되었음을 지시하고, 피호출자에게 이 호출을 수신할 것인지 또는 라우팅 순서에 따라 다음 착신 번호(또는 목적지)로 호출을 라우팅할 것인지에 대한 옵션을 제공한다. 피호출자에게 제공되는 옵션은:
·호출을 받아들이는 옵션;
·호출을 다음 착신 번호로 보내는 옵션; 및
·호출이 시간 경과 후(행위가 요구되지 아니함) 다음 착신번호로 나아가는 것 등을 포함한다.
2초보다 더 적은 # 재발신
실시예는 # 키를 2초보다 적게 누름에 의해 외부호출을 재발신하는 기능을 직통회선 MCI 게이트웨이로부터 제공한다. 현재에는 직통회선 MCI는 가입자가 호출을 재발신하기 위해서 #키를 2초 또는 그 보다 오래 누를 것을 요한다.
L. 메시지 관리
1. 다중 미디어 메시지 통지
가입자는 현재 메시지의 회계를 음성메일, 팩스메일, 이메일, 페이징을 포함한 복수의 미디어를 통해 수신할 수 있다. 구체적으로는 가입자는 ARU 스크립트가 "당신은 3개의 음성메일, 2개의 팩스메일, 10개의 이메일 메시지를 새로 받았습니다"라고 말하는 것을 들을 수 있다.
2. 다중 미디어 메시지 조작
가입자는 직통회선 MCI ARU 게이트웨이를 통해 유니버설 인박스에 접속하는 것이 허용된다. 이곳에서 가입자는 다중 미디어(음성메일, 팩스메일, 이메일, 페이징)를 통해 수신된 메시지에 대한 기본적 조작을 하게된다.
가입자는 음성메일 관리자 및 페이저 관리자를 검색할 수 있고, 팩스메일 및 이메일 메시지에 대한 메시지 헤더(우선, 송신자, 주제, 날짜/시간, 크기) 정보를 검색할 수 있다. 부가하여, 가입자는 ARU 인터페이스로부터 개관된 메시지를 저장, 전달, 삭제할 수 있다. 전달 기능은 메시지를 음성메일 또는 팩스메일 형태로 분산하는 것에 한정된다. 음성메일 메시지만이 음성메일로써 전달된다. 팩스메일, 이메일, 페이저 메시지는 팩스메일로써 전달된다. 그러나, 이메일 및 페이저 메시지는 G3 포맷으로 전환되는 것은 필요하다. 메시지를 팩스메일로 전달함과 더불어, 가입자는 메시지를 분산 목록 및 팩스 방송 목록에 송신할 수 있다.
3. 텍스트 투 스피치(Text to Speech)
시스템은 팩스메일, 이메일, 또는 페이저 메시지로써 수신된 텍스트 메시지를 음성으로 전환할 수 있다. 이 음성은 직통회선 MCI 게이트웨이를 통해 다시 재생될 수 있다. 처음에는 텍스트-투-스피치 용량은 메시지 헤더(우선, 송신자, 주제, 날짜/시간, 크기) 정보에 한정될 것이다.
먼저 어떤 메시지 헤더를 들을 지의 여부를 선택하고, 그후 어떤 전체 메시지를 듣고 싶은 지를 선택하는 옵션이 가입자에게 제공된다. 전체 메시지에 대해서 텍스트-투-스피치 용량을 지원하지 아니하는 메시지 유형은 팩스메일이 유일하다. 즉 팩스메일에 있어서 그 팩스메일 헤드에 대해서만 상기 텍스트-투-스피치 용량을 지원된다. 팩스메일 헤드 정보는 송신자의 ANI, 팩스메일이 수신된 날짜/시간 및 팩스메일의 크기를 포함한다.
4. 팩스머신으로의 이메일 전달
가입자는 직통회선 MCI ARU 게이트웨이를 통해 검색되고 개관된 이메일을 가입자가 정한 착신번호로 전달할 수 있다. 구체적으로, 가입자는 직통회선 MCI ARU 게이트웨이를 통해 이메일 메시지를 개관할 수 있다. 메시지를 개관한 후에, 가입자는 이메일을 정해진 착신번호로 전달할 지의 여부를 물어보는 프롬프트를 수신하거나, 또는 즉흥적인 번호를 입력하는 옵션을 가진다. 이 옵션을 선택하고 착신번호를 지시함에 의해, 이메일 메시지는 G3 포맷으로 전환되고 정해진 착신번호로 전송된다. 2진 파일인 이메일 연결장치는 지원된다. 만약 연결장치가 착신 팩스머신에 연결되지 아니한다면, 텍스트 메시지는 2진 연결장치가 전달되지 아니한다는 것을 수령자에게 제공해야한다. 이메일을 팩스머신으로 전달하더라도, 상기 메시지는 유니버설 인박스로부터 삭제되지 아니한다.
5. 메시지 수신의 페이저 통지
가입자는 메시지 미디어에 의해 가입자의 유니버설 인박스에 현재 존재하는 메시지의 수를 알려주는 페이저 통지를 가입자가 정한 간격으로 수신할 수 있다. 구체적으로는, 가입자는 가입자의 유니버설 인박스에 현재 존재하는 음성메일, 팩스메일, 이메일, 페이저 메시지의 수를 알려주는 페이저 메시지를 수신하는 통지 스케줄을 직통회선 MCI ARU 게이트웨이를 통해 설정할 수 있다.
6. 음성메일의 전달 확인
가입자가 전달한 음성메일 메시지가 착신지에 성공적으로 전달되지 아니한 경우에, 시스템은 가입자에게 확인 음성 메시지를 수신할 수 있도록 한다.
7. 메시지 우선 순위 결정
시스템은 게스트가 메시지에 우선순위를 설정할 수 있도록 한다. 가입자가 메시지의 회계를 받았을 때, 긴급 메시지는 보통 메시지의 앞에 색인된다. 이 조건은 단지 음성메일에만 적용되며 팩스메일은 적용되지 아니한다. 이것은 유니버설 인박스가 직통회선 MCI 음성메일에 대한 적절한 우선 순위를 제공함에 의해 이루어진다.
M. 정보 서비스
ARU 인터페이스를 통해, 유저는 정보 서비스로부터 내용을 수신할 수 있다. 이것은 WWW 브라우저 인터페이스를 통해 환경 설정될 수 있다. 정보 내용은 인바운드(inbound) 서비스 및 아웃바운드(outbound) 서비스 형태로 제공된다. WWW 브라우저(즉, 프로파일 관리)를 통해 정의된 정보 내용은 인바운드(inbound) 정보 내용으로 정의되고:
·주식 시세 및 경제 뉴스; 및
·헤드라인 뉴스에 한정된다.
가입자는 또한 ARU 인터페이스를 통해 부가적 정보 내용에 접속할 수 있다. 그러나 이 정보는 WWW 브라우저 인터페이스(즉, 프로파일 관리)를 통해 환경 설정될 수 없다. 부가적 정보 내용은 아웃바운드(outbound) 정보 내용으로 정의되고:
·주식 시세 및 경제 뉴스;
·헤드라인 뉴스;
·기후;
·스포츠 뉴스 및 스코어;
·홈드라마 업데이트;
·천체 정보;
·복권 (Lottery) 결과;
·오락 소식; 및
·여행자 안내 등으로 구성된다.
인바운드(inbound) 정보 내용의 환경 설정 파라미터는 아래에 정의되어 있다. 아웃바운드(outbound) 정보 내용의 검색은 DTMF 키패드를 통한 알파벳 문자의 입력을 지원한다. 알파벳 문자의 입력은 목록 관리를 위해 DTMF를 통해 입력된 알파벳 문자와 같은 방식이어야 한다.
여행자 안내에 대한 접속은 다른 아웃바운드(outbound) 정보 서비스와 결합되어 있으므로, 가입자는 하나의 800/8XX 번호로 다이얼하기만 하면 된다. 800/8XX 호출은 선택되는 정보 내용에 따라 다른 착신으로 확장될 수 있다.
N. 메시지 저장 요구
메시지 저장 조건은 아래에 정의된 메시지 저장 요구와 일치한다.
O. 프로파일 관리
직통회선 MCI 프로파일 관리
가입자는 직통회선 MCI 회계 프로파일을 개관하고, 업데이트 및 불러들일 수 있다. ARU 인터페이스를 통한 직통회선 MCI 프로파일 관리 용량은 WWW 브라우저를 통해 제공된 제출과 일치하며, 아래의 요구를 지원한다:
·새로운 직통회선 MCI 프로파일을 생성하고 이 프로파일에 이름을 할당한다;
·직통회선 MCI 프로파일을 불러들인다;
·음성은 직통회선 MCI 프로파일 이름에 주석을 단다;
·현재의 직통회선 MCI 프로파일을 ;
·직통회선 MCI 프로파일을 생성하고 업데이트 하는 규칙에 기초한 논리회로를 지원한다(예를 들면 음성메일과 같이 단지 하나의 호출 라우팅 옵션의 선택은 음성메일에 대한 오버라이드 라우팅(override routing)을 불러들일 것이다);
·직통회선 MCI 번호를 가능하게 한다;
·오버라이드 라우팅 번호를 가능하게 하고 정의한다;
·팔로우미(FollowMe) 라우팅을 가능하게 하고 정의한다;
·최종 라우팅(이전에는 대체 라우팅이라 함)을 가능하게 하고 정의한다;
·음성메일 및 페이저;
- 단지 음성메일만;
- 단지 페이저만;
- 최종 메시지;
·둘 이상의 호출 라우팅 옵션(팔로우미(FollowMe), 음성메일, 팩스메일, 또는 페이저)이 가능하다면 메뉴 라우팅을 불러들인다;
·팩스메일 전달의 디폴트 번호를 정의한다;
·음성메일에 대한 페이징 통지를 활성화한다;
·팩스메일에 대한 페이징 통지를 활성화한다;
·긴급 전달을 위해 음성메일을 분류하는 게스트 옵션을 제공한다;
·아래의 사항에 대해 호출 스크리닝 파라미터를 정의한다;
- 이름 및 ANI에 대해;
- 단지 이름에 대해;
- 단지 ANI에 대해;
·파크 앤드 페이지를 가능하게 하거나 또는 불가능하게 한다.
P. 호출 라우팅 메뉴 변화
시스템은 또한 가입자가 기존의 착신 번호 중에서 바꾸고 싶지 아니한 번호를 다시 입력하지 아니하고 호출 라우팅 착신번호를 수정 보완할 수 있는 용량을 제공한다. 구체적으로는, 라우팅 번호 중에서 어느 하나라도 바꾸고 싶다면, 직통회선 MCI 라우팅 수정보완 용량은 가입자가 모든 착신번호를 다시 입력할 것을 요한다. 그러나 이 기능은 가입자가 바꾸고 싶은 번호만을 입력하고, 바꾸고 싶지 아니한 번호에 대해서는 #키를 입력하면 된다.
Q. 양방향 페이저 환경설정 제어 및 파크 앤드 페이지에 대한 응답
시스템은 양방향 페이저에 의해 제출된 명령을 통해 미리 정의된 직통회선 MCI 프로파일을 가능하게 하거나 불가능하게 할 수 있다.
R. 개인 인사말
시스템은 가입자가 ARU로부터 들려지거나 또는 개인 홈 페이지에 디스플레이되는 개인 인사말을 개관하고 업데이트할 수 있게 한다. 각 인사말은 분리되어 유지 보수되고 각 인터페이스(ARU 또는 개인 홈 페이지)를 통해 가동될 수 있는 기능에 상용화될 수 있다.
S. 목록 관리
시스템은 또한 가입자에게 목록을 생성하고 업데이트할 수 있게 하고, 목록에 대한 음성 주석 이름을 생성 가능하게 한다. 팩스방송 목록 관리 용량은 단일한 목록 데이터 베이스를 제공하기 위해 직통회선 MCI 목록 관리 용량과 통합된다. ARU 인터페이스로부터 가입자는 목록의 일부를 개관, 업데이트, 부가 또는 삭제할 수 있다. 부가하여, 가입자는 목록을 삭제하거나 생성할 수 있다. ARU 인터페이스는 음성메일 및 팩스메일 메시지를 분산하기 위하여 목록을 사용할 수 있다.
분산 목록에 대한 접속은 알파벳 목록 이름을 지원하며, 따라서 목록은 목록 코드 이름에 한정되지 아니한다. DTMF를 통해 ARU에 목록 이름에 대한 알파벳 문자의 입력은 정보서비스를 위해 DTMF를 통해 입력한 알파벳 문자와 같은 방식이다. 목록 관리 요구는 아래에 상세히 기술되어 있다.
메시지 조작 용량을 제공함과 아울러, PC 클라이언트는 주소록 및 목록에 대한 접속을 제공한다. 유저는 주소록 및 음성, 팩스, 이메일 및 페이징 메시지를 위한 관리 분산 목록을 수정 보완할 수 있다. 하나의 실시예에서, PC 클라이언트를 통해 생성되고 유지 보수되는 목록은 WWW 브라우저 또는 ARU 인터페이스를 통해 생성되고 유지 보수되는 목록과 통합되지 아니한다. 그러나, 다른 실시예에서는 그런 통합이 행해진다. 가입자는 PC 클라이언트로부터 분산목록으로 메시지를 송신할 수 있다. 이것은 PC클라이언트와 목록 관리 데이트베이스 사이의 양방향 인터페이스를 요하며, 그것에 의해 콤마로 PC 클라이언트는 범위가 정해진 또는 DBF로 포맷된 파일을 목록의 데이트베이스로 전달한다.
유저는 그의 인터페이스 PC 소프트웨어를 통해 수령자 주소정보를 생성하거나 수정 보완하다 수 있다. 유저는 10 디지트 ANI, 음성 메일박스 ID, 팩스 메일박스 ID, 페이징 번호 및 이메일 주소(MCI메일 및 인터넷)를 포함한 복수 형태의 주소를 그의 주소록에 기록할 수 있다.
T. 글로벌 메시지 취급
ARU 인터페이스로부터, 가입자는 어떠한 형태의 메시지가 유니버설 인박스로부터 접속될 수 있는지를 정의할 수 있다. 글로벌 메시지 취급요구는 아래에 정의된 요구와 일치한다.
X. 지능 전화 및 관련된 서비스
지금까지는 인터넷에 대한 소개가 논의되었으므로 인터넷 전화에 대해서 기술하겠다. 그러나 인터넷 전화는 몇몇 영역에서만 진전이 있었다. 아래에는 6개의 주요 영역으로 나뉘어 인터넷 전화의 요약이 기술되어 있다.
첫 번째 영역은 인터넷 전화 서비스에 대한 접속으로 구성되어 있다. 이 영역은 위성, 다이얼 업 서비스, T1, T3, DS3, OC3, 및 OC12 전용라인, SMDS 네트워크, ISDN B-채널, 다중속도 ISDN, 다중 B-채널로 결합된 ISDN 시스템, 이서넷, 토큰 링, FDDI GSM, LMDS, PCS, 셀방식 네트워크, 프레임 전달, 및 X.25와 같은 메카니즘을 사용하는 인터넷에 대한 접속 및 사용을 포함한다.
두 번째 영역은 인터넷 전화를 공유하는 것을 포함한다. 멀티미디어 데이터는 고신뢰성 및 처리 잠재력으로 인해 아주 쉽게 회선교환망을 이용할 수 있다. 이것은 공용 데이터, URL 데이터를 공용하는 것, 데이터 회의, 공용 화이트보딩(Whiteboarding), 자원 협동, 및 ISDN 유저-유저 시그널링 등을 포함한다.
세 번째 영역은 인터넷 전화를 라우팅하는 것을 다룬다. 이것은 하루중의 시간, 주중의 날짜, 한달 중의 날짜, 년 중의 날짜, 및 신호원의 지리적 위치, 신호원의 네트워크 위치, 신호원의 시간 영역 등을 포함한다. 라우팅의 분석은 유저 데이터, 목적지, 전화번호, 신호원 회선, 전달 서비스의 유형, 미리 가입된 기능 라우팅, ANI, 및 IP 주소 등을 포함한다. 또한 VNET 계획, 영역특권, 디렉토리 서비스, 및 서비스 제어 포인트 등은 라우팅 인터넷 전화에 속한다.
네 번째 영역은 서비스 품질을 다룬다. 이 영역은 교환망, ISDN, 동적 수정보완, 인터넷 전화, RSVP, 및 중첩 네트워크 서비스 등을 포함해야 한다. 부가하여, 이 영역은 하이브리드 인터넷/전화 스위치, 이서넷 기능, ISDN 기능, 아날로그 로컬 루프 및 공용 전화, 및 예약 및 사용 서비스에 대한 요금 부과를 포함한다.
다섯 번째 영역은 디렉토리 서비스, 프로파일, 및 통지로 구성된다. 그 예는 분산 디렉토리, 파인딩-미(finding-me) 및 팔로우-미 서비스(follow-me) 서비스, 전화의 디렉토리 관리, 및 유저 인터페이스 등이다. 호출자 인증 안전은 또한 포함된다. 계층적 및 객체 지향 프로파일은 디렉토리 서비스 유저 프로파일, 네트워크 프로파일 데이터 구조, 서비스 프로파일, 및 오더 엔트리 프로파일을 따라 존재한다.
여섯 번째 영역은 하이브리드 인터넷 전화 서비스로 구성된다. 이 영역은 객체 지향 메시징, 인터넷 전화 메시징, 인터넷 회의, 인터넷 팩싱, 정보 라우팅, 음성 통신, 및 인트라네트(intranet)(한 회사 내에 존재하는 것과 같은) 등을 포함한다. 다른 서비스는 오퍼레이터 서비스, 관리 서비스, 페이징 서비스, 요금 부과 서비스. 무선 통합, 메시지 방송, 모니터링 및 리포팅 서비스, 카드 서비스, 영상메일 서비스, 압축, 권한 부여, 인증, 코드화, 전화 응용 설치자, 요금 부과, 및 데이터 수집 서비스 등을 포함한다.
일곱 번째 서비스는 하이브리드 인터넷 미디어 서비스로 구성되며, 이것은 복수의 유저를 포함하는 협동작업의 영역을 포함한다. 유저는 음성, 데이터, 영상 상에서 공동 작업할 수 있다. 이 영역은 하이브리드 네트워크 내에서 미디어 회의를 포함한다. 그리고 넓게 보면 예약 메카니즘, 오퍼레이터에 의해 보조되는 회의, 및 회의 내용의 소개 등이 관련되어 있다. 이 가상 공간에서의 회의는 미래에 그 중요성이 증가될 것이다. 다음 세대 대화방은 시뮬레이션 오피스 환경으로 꾸며진 가상회의 공간을 그 특징으로 할 것이다.
A. 인터넷 미디어를 위한 시스템 환경
1. 하드웨어
본 발명의 바람직한 실시예에 따르면, 본 발명의 시스템은 IBM PS/2, 애플 매킨토시 컴퓨터 또는 UNIX에 기초한 워크스테이션 등과 같은 퍼스널 컴퓨터(PC)에 적용될 수 있다. 바람직한 실시예와 일치하는 대표적인 하드웨어 환경은 워크스테이션 99의 전형적 하드웨어 구성을 설명하는 도1A에 도해되어 있다. 그리고 이 하드웨어 구성은 마이크로프로세서와 같은 중앙 처리 장치(CPU) 10 및 시스템 부스(bus) 12에 의해 상호연결된 복수의 다른 장치를 가지고 있다. 도1A에 표시된 워크스테이션은 램(RAM - Random Memory Access) 14, 롬(ROM - Read Only Memory) 16, 통신망(예를 들면 데이터 처리망), 프린터, 및 디스크 저장장치 등을 부스에 연결하는 I/O 어댑터 18, 키보드, 마우스, 스피커, 마이크로폰 등의 연결용 유저 인터페이스 22, 및/또는 접촉식 스크린을 부스에 연결하는 다른 유저 인터페이스 장치(표시하지 않음), 및 디스플레이 장치를 부스에 연결하는 디스플레이 어댑터 36 등을 포함한다. 워크스테이션은 매킨토시 윈도우 NT 또는 윈도우/95 운영 시스템(OS), IBM OS/2 운영시스템, 맥 시스템/7 OS, 또는 UNIX 운영시스템 등과 같은 운영 시스템을 그 위에 가지고 있다. 당해 분야의 전문가는 상기 언급한 것 외에 본 발명이 플랫폼 및 운영 시스템 상에 실행될 수 있다는 것을 이해할 수 있을 것이다.
2. 객체 지향 소프트웨어 도구
바람직한 실시예는 자바, C 및 C++ 언어를 사용하여 쓰여졌고, 객체 지향 프로그래밍 방법을 사용하였다. 객체 지향 프로그래밍(OOP)은 복잡한 응용을 발전시키는 데 있어서, 그 사용이 점점 증가되고 있다. OOP가 소프트웨어 고안 및 개발의 주류가 됨에 따라, 다양한 소프트웨어 해결책은 OOP의 이로운 점을 이용하기 위한 적응을 요구한다. OOP의 원칙이 전기 메시징 시스템의 메시징 인터페이스에 적용될 필요가 있으며, 따라서 메시징 인터페이스에 대한 일련의 OOP 클래스 및 객체가 제공될 수 있다.
OOP는 객체를 사용하여 문제점을 분석하고, 시스템을 고안하고, 프로그램을 구축하는 단계를 포함하는 컴퓨터 소프트웨어를 개발하는 프로세스이다. 객체는 데이터 및 관련된 구조와 절차의 집합을 동시에 가지고 있는 소프트웨어 패키지이다. 소프트웨어 패키지가 데이터 및 관련된 구조와 절차의 집합을 동시에 가지고 있기 때문에, 특정의 임무를 수행하기 위해 다른 부가적 구조, 절차, 또는 데이터를 요구하지 아니하는 자체 충족형 구성요소이다. 그러므로 OOP는 컴퓨터 프로그램을 그 각각이 특정한 임무를 수행하는 객체라고 명명되는 거대한 자율 구성요소의 집합으로 보이게 한다. 데이터, 구조, 및 절차를 하나의 구성요소 또는 모듈에 함께 묶는 이 개념은 요약화(Encapsulation)라고 불려진다.
일반적으로, OOP 구성요소는 재사용가능한 소프트웨어 모듈이며, 이 모듈은 객체 모델에 따르는 인터페이스를 제공하고, 실행시간에 구성요소 통합 아키텍쳐를 통해 접속된다. 구성요소 통합 아키텍쳐는 다른 프로세스 공간에 있는 소프트웨어 모듈이 각각의 다른 용량 및 기능을 이용할 수 있도록 하는 일련의 아키텍쳐럴 메카니즘이다. 이것은 그 상에 아키텍쳐를 설치하는 공통 구성요소 객체 모델을 가정함에 의해 통상 행해진다. 객체와 객체의 클래스를 구별할 필요가 있다. 객체는 객체 클래스의 하나의 예이며, 이것은 종종 하나의 클래스라고 불려진다. 객체의 클래스는 하나의 청사진으로 간주될 수 있으며, 그것으로부터 많은 객체가 형성될 수 있다.
OOP는 프로그래머가 다른 객체의 일부분인 객체를 생성할 수 있게 한다. 예를 들면, 피스톤 엔진을 표현하는 객체는 피스톤을 표현하는 객체와 성분관계에 있다고 일컬어진다. 실제로는 피스톤 엔진은 피스톤, 밸브 및 다른 복수의 구성요소를 포함한다. 피스톤이 피스톤 엔진의 한 요소라는 사실은 논리적으로 그리고 의미론적으로 OOP내에서 두 개의 객체로 표현될 수 있다.
OOP는 또한 다른 객체로부터 파생 객체(derived object)의 생성을 허용한다. 만약 두 개의 객체가 있다면, 즉 피스톤 엔진을 표현하는 하나의 객체 및 피스톤이 세라믹으로 이루어진 피스톤 엔진을 표현하는 다른 하나의 객체로 구성되어 있다면, 두 객체 사이의 관계는 성분의 관계가 아니다. 세라믹 피스톤 엔진은 피스톤 엔진을 구성하지 아니한다. 오히려 그것은 그 피스톤이 세라믹으로 구성되어 있다는, 즉 피스톤 엔진에 비해 하나의 한정을 더 가진 단순히 피스톤 엔진의 한 종류이다. 이와 같은 경우, 세라믹 피스톤 엔진을 표현하는 객체는 파생 객체라 불리어지고, 이것은 피스톤 엔진을 표현하는 객체의 모든 특징을 가지고 있으며 다른 하나의 한정이 부가되어 있다. 세라믹 피스톤 엔진을 표현하는 객체는 피스톤 엔진을 표현하는 객체로부터 파생된다. 두 객체의 관계는 계승(inheritance)이라고 한다.
세라믹 피스톤 엔진을 표현하는 객체 또는 클래스는 피스톤 엔진을 표현하는 객체의 모든 특징을 계승받을 때, 그것은 피스톤 엔진에 정의된 표준 피스톤의 열적 특성을 계승받는다. 그러나, 세라믹 피스톤 엔진 객체는 금속 피스톤 엔진의 열적 특성과는 전혀 다른 세라믹 고유의 열적 특성을 덮어쓴다. 그것은 원래의 것을 뛰어넘고 세라믹 피스톤과 관련된 새로운 기능을 사용한다. 다른 종류의 피스톤 엔진은 다른 특성을 가지고 있으나, 같은 기본적 기능(예를 들면, 엔진에 있어서 피스톤의 개수, 점화 순서, 윤활제 등)을 가지고 있다. 각 피스톤 엔진 객체에 있어서 이러한 기능의 각각에 접속하기 위해서는, 프로그래머는 같은 이름을 가진 같은 기능을 식별할 것이나, 피스톤 엔진의 각 유형은 같은 이름 뒤에 다른/덮어쓰는 기능의 성취를 가질 수 있다. 다른 기능의 성취를 같은 이름 뒤에 숨길 수 있는 능력은 폴리모르피즘(polymorphism)이라 불리고, 이것은 객체 사이의 통신을 매우 단순화한다.
성분관계, 요약화, 계승 및 폴리모르피즘의 개념을 이용하여, 객체는 현실 세계의 모든 것을 표현할 수 있다. 사실상, 현실의 논리적 지각은 객체 지향 소프트웨어에 있어서 객체가 될 수 있는 물건의 종류를 결정하는 것에 한정된다. 몇몇의 전형적 카테고리는 다음과 같다:
객체는 교통 흐름 시뮬레이션에 있어서의 자동차, 회선 고안 프로그램에 있어서의 전기적 구성요소, 경제 모델에 있어서의 어느 나라, 항공제어 시스템에서의 항공기와 같은 물리객체를 표현할 수 있다.
객체는 윈도우, 메뉴 또는 그래픽 객체와 같은 컴퓨터-유저 환경의 요소를 표현할 수 있다.
객체는 퍼스넬 파일 또는 도시의 위도 및 경도의 테이블과 같은 목록을 표현할 수 있다.
객체는 유저에 의해 정의된 시간, 각, 및 복소수 또는 평면상의 점과 같은 데이터 유형을 표현할 수 있다.
어떤 논리적으로 구별 가능한 물질을 표현하는 객체의 이 거대한 용량을 이용하여, OOP는 소프트웨어 개발자가 현실(예를 들면, 물리 엔티티, 프로세스, 시스템 또는 물질의 성분)의 모델인 컴퓨터 프로그램을 고안하고 완성할 수 있게 한다. 객체가 어떠한 것이라도 표현할 수 있기 때문에, 소프트웨어 개발자는 미래에는 거대한 프로젝트의 구성요소로서 사용될 수 있는 객체를 생성할 수 있다.
만약 OOP 소프트웨어 프로그램의 90%가 기존의 재사용 가능한 객체로부터 만들어지고, 증명된 현재의 구성요소로 구성되어 있다면, 새로운 소프트웨어 프로젝트의 나머지 10%는 스크래치로부터 기록되고 테스트되어야 한다. 90%가 미리 테스트된 재사용가능한 객체로부터 왔기 때문에, 에러가 발생할 수 있는 잠재적 도메인은 프로그램의 10%이다. 따라서, OOP는 소프트웨어 개발자가 다른 미리 건설된 객체로부터 객체를 건설할 수 있다.
이 프로세스는 조립부품 및 하위 조립부품에서부터 만들어진 복합 기계와 매우 유사하다. 그러므로 OOP 테크널리지는 소프트웨어를 현존하는 구성요소(소프트웨어에게는 객체임)로부터 건설한다는 점에 있어서 소프트웨어 엔지니어링을 하드웨어 엔지니어링과 거의 동일하게 만든다. 이것은 소프트웨어의 질을 개선시킬 뿐만 아니라 개발의 속도도 증가시킨다.
프로그래밍 언어는 요약화, 계승, 폴리모르피즘 및 성분관계와 같은 OOP 원칙을 지원하는 것을 시작하고 있다. C++ 언어의 출현과 더불어, 복수의 상업적 소프트웨어 개발자는 OOP를 채용하고 있다. C++은 OOP 언어로서, 빠르고 기계에 적용 가능한 코드이다. 또한 C++은 상업적 응용 및 시스템-프로그래밍 프로젝트에 적합하다. C++은 OOP 프로그래머들 사이에서 지금 가장 각광받는 선택이지만, 스몰토크(Smalltalk), 코먼 리스프 객체 시스템(CLOS - Common Lisp Object System), 및 에이펠(Eiffel) 등과 같은 다른 OOP 호스트가 있다. 부가적으로, OOP 용량은 보다 많은 전통적 컴퓨터 프로그래밍 언어(예를 들면 파스칼)가 부가될 수 있다.
객체 클래스의 이점은 아래와 같이 요약될 수 있다:
객체 및 대응되는 클래스는 복잡한 프로그래밍 문제점을 복수의 작고 단순한 무제로 분해한다.
요약화는 데이터 조직을 통해 서로 통신할 수 있으며, 작고 독립적인 객체로 데이터 추상화(data abstraction)를 강요한다. 요약화는 또한 객체 내의 데이터가 우발적 손실을 입는 것을 방지하면서, 다른 객체가 객체의 요소 기능 및 구조를 호출함에 의해 데이터와 상호작용할 수 있게 한다.
서브클래싱(subclassing) 및 계승(inheritance)은 시스템 내에서 유용한 표준 클래스로부터 새로운 종류의 객체를 파생시킴에 의해 객체를 확장 및 수정 보완하는 것을 가능하게 한다. 그러므로 새로운 용량이 스크래치로부터 출발하지 아니하고도 생성될 수 있다.
폴리모르피즘(polymorphism) 및 다중 계승(multiple inheritance)은 다른 프로그래머가 복수의 다른 클래스의 특성을 혼합 및 배합하고, 예상 가능한 방식으로 관련된 객체와 협력할 수 있는 전문적 객체(specialized object)를 생성하는 것을 가능하게 한다.
클래스 계층구조 및 제한 계층구조는 현실세계 객체 및 그들 사이의 관계를 모델링하는 데 있어서 확장 가능한 메카니즘을 제공해준다.
재사용가능한 클래스의 라이브러리(library)는 많은 상황에 있어서 유용하지만, 몇 가지 한계는 있다. 예를 들면:
복잡성. 복잡한 시스템에 있어서, 관련된 클래스에 대한 클래스 계층구조는 수십 개의 또는 수백 개의 클래스에 의해 혼란스럽게 될 수 있다.
제어의 흐름. 클래스 라이브러리의 도움으로 기록된 프로그램은 흐름의 제어(즉 특정 라이브러리로부터 생성된 모든 객체 사이의 상호작용의 제어)를 책임지고 있다. 프로그래머는 어떤 객체를 위해, 어떠한 기능을 언제 호출해야 하는지를 결정하여야 한다.
노력의 중첩. 클래스 라이브러리는 프로그래머가 복수의 작은 코드를 사용 및 재사용할 수 있게 하지만, 각 프로그래머는 이것을 다른 방식으로 조합한다. 두 명의 다른 프로그래머는 수백 개의 작은 결정에 따라 프로내부 구조는 상당히 다르지만 서로 동일한 두 개의 프로그램을 작성하기 위하여 같은 클래스 라이브러리를 이용할 수 있다. 결과적으로, 유사한 코드는 약간 다른 방식으로 유사한 것을 행하는 것으로 끝나고, 함께 하는 것보다 더 잘 작용하는 것은 아니다.
클래스 라이브러리는 매우 신축성이 있다. 프로그램이 보다 복잡해짐에 따라, 더 많은 프로그래머가 기본적 문제점에 대한 기본적 해결책을 계속해서 발견하도록 강요된다. 클래스 라이브러리 개념의 상대적으로 새로운 확장은 클래스 라이브러리의 프레임워크를 가지는 것이다. 이 프레임워크는 보다 복잡하고, 상호협동하는 클래스의 집합으로 구성되어 있다. 이 클래스는 작은 스케일의 패턴 및 특정한 도메인 내에서 공통 요구 및 고안을 이행하는 주요한 메카니즘을 가지고 있다. 프레임워크는 퍼스널 컴퓨터를 위해 메뉴, 윈도우, 대화 상자 및 다른 표준 유저 인터페이스 요소를 디스플레이하는 잡일로부터 응용 프로그래머들을 자유롭게 하기 위하여 개발되었다.
프레임워크는 또한 프로그래머가 작성한 코드와 다른 프로그래머가 작성한 코드들 사이의 상호작용에 대한 사고방식을 변화시켰다. 절차형 프로그래밍의 초기단계에 있어서, 프로그래머는 어떤 임무를 수행하기 위해서 운영 시스템에 의해서 제공되는 라이브러리를 요구했으나, 기본적으로 프로그램은 페이지의 처음부터 끝까지 실행해 나가고, 프로그래머가 유일하게 흐름의 제어에 대한 책임을 지고 있다. 이것은 급료, 셈 계산, 한쪽방향으로만 실행되는 프로그램을 가지고 문제점을 해결하는 데 있어서 적절하다.
그래픽컬 유저 인터페이스의 개발은 이 절차형 프로그래밍 배열을 뒤집기 시작했다. 이 인터페이스는 프로그램 논리가 아니라 유저로 하여금 프로그램을 유도하고 언제 어떠한 실행이 수행되어야 하는지를 결정하도록 하였다. 오늘날 대부분의 퍼스널 컴퓨터 소프트웨어는 마우스, 키보드 및 다른 외부 사상의 소스를 제어하고, 유저가 수행하는 실행에 따라 적절한 프로그래머의 코드를 호출하는 사상 루프(event loop)에 의해서 이것을 성취한다. 프로그래머는 사상이 일어나는 순서를 이제는 더 이상 결정하지 아니한다. 반면에, 프로그램은 불시에 그리고 불규칙하게 호출되는 분리된 조각으로 나뉘어진다. 상기 방식과 같이 제어를 유저에게 양보함에 따라, 개발자는 사용되기 쉬운 프로그램을 만들 수 있다. 그럼에도 불구하고, 개발자에 의해 작성된 프로그램의 개별적 조각은 어떤 임무를 수행하기 위해서 운영 시스템에 의해서 제공되는 라이브러리를 호출하고, 프로그래머는 그것이 사상 루프(event loop)에 의해서 호출된 후 각각의 조각 내에서 프로그래머가 흐름의 제어를 결정한다. 응용 코드는 시스템의 꼭대기에 위치해 있다.
사상 루프(event loop) 프로그램은 프로그래머로 하여금 모든 응용에 대해서 개별적으로 작성될 필요가 없는 복수의 코드를 작성하기를 호출한다. 응용 프레임워크(application framework)의 개념은 사상 루프의 개념을 더 확장했다. 기본 메뉴, 윈도우, 및 대화 상자를 구성하는 모든 너트 및 볼트를 취급하는 것, 그리고 이 모든 것을 함께 작동하도록 하는 것 대신에, 응용 프레임워크를 사용하는 프로그래머는 응용 코드 및 기본적인 유저 인터페이스 요소를 적절히 작동시키는 것부터 시작한다. 그리고 그들은 몇몇의 일반적 용량의 프레임워크를 특정한 용량의 의도된 응용장치로 교체함에 의해 그곳으로부터 건설한다.
응용 프레임워크는 프로그래머가 스크래치로부터 작성해야 하는 코드의 전체 양을 감소시킨다. 그러나, 프레임워크는 윈도우를 디스플레이하고, 복사 및 붙이기를 지원하고, 그리고 기타의 일반적 응용장치이기 때문에, 프로그래머는 사상 루프가 허용하는 것보다 더 많이 제어를 양보할 수 있다. 프레임워크 코드는 거의 모든 사상 취급, 흐름의 제어를 관리하며, 그리고 프로그래머의 코드는 프레임워크가 그것을 필요로할 때(예를 들면, 데이터의 생성 또는 조작) 호출된다.
프레임워크 프로그램을 작성하는 프로그래머는 제어를 유저에게 양보할 뿐만 아니라 네트워크 내의 상세한 흐름의 제어도 프레임워크 내에 양보한다. 이 접근은 주문형 코드가 유사한 문제점에 반복하여 생성되는 고립 프로그램에 반대되는 상호 협동하는 보다 복잡한 시스템의 제어를 허용한다.
따라서, 상기 언급한 바와 같이, 프레임워크는 기본적으로 주어진 문제점 도메인에 대해 재사용 가능한 고안 해결책으로 구성된 상호 협동하는 클래스의 집합이다. 프레임워크는 통상 디폴트 behavior를 정의하는 객체를 제공하고, 프로그래머는 적절한 시점에 응용 코드를 호출하기 위하여 디폴트 behavior의 몇 개를 계승하고 다른 behavior를 덮어씀에 의해 프레임워크를 사용한다.
프레임워크와 클래스 라이브러리 사이에는 중요한 세 가지 차이점이 있다:
1. 기능 대 프로토콜.
클래스 라이브러리는 기본적으로 당신의 프로그램 내에서 이 개개의 기능이 필요할 때 호출할 수 있는 기능의 집합이다. 반면에 프레임워크는 기능뿐만 아니라 프로토콜 또는 프레임워크가 제공하는 것과 대비하여 프로그래머가 제공할 것으로 예상되는 것에 대한 규칙을 포함하며, 기능이 결합될 수 있는 방식을 제어하는 일련의 규칙을 제공한다.
2. 호출 대 덮어씀.
클래스 라이브러리에 있어서, 프로그래머가 작성한 코드는 객체를 실증하고 그 요소의 기능을 호출한다. 프레임워크와 같은 방식으로 객체를 실증하고 호출하는 것은 가능하나(즉 프레임워크를 클래스 라이브러리로 취급하는 것이 가능하다), 프레임워크의 재사용 가능한 고안을 완전히 이용하기 위해서, 프로그래머는 프레임워크에 의해 호출되고 덮어쓰는 코드를 작성한다. 프레임워크는 그 객체 사이에서의 제어의 흐름을 관리한다. 프로그램을 작성하는 것은 서로 다른 조각들이 어떻게 서로 협동해야 하는지를 특정하기보다는, 프레임워크에 의해 호출되는 다양한 소프트웨어의 조각에 책임을 분배하는 것을 수반한다.
3. 실행 대 고안(Implementation versus design)
클래스 라이브러리에 있어서, 프로그래머는 단지 실행을 재사용하나, 프레임워크에 있어서는 고안을 재사용한다. 프레임워크는 관련된 프로그램의 패밀리와 소프트웨어의 조각이 작동하는 방법을 구현한다. 이것은 주어진 도메인에 내의 다양한 특정 문제점을 해결하는 데 적용될 수 있는 일반적 고안 해결책을 제공한다. 예를 들면 같은 프레임워크에 생성된 두 개의 서로 다른 유저 인터페이스가 꽤 다른 인터페이스 문제점을 해결할 수 있음에도 불구하고, 단일한 프레임워크는 유저 인터페이스가 작동하는 방법을 구현할 수 있다.
B. 인터넷 상에서의 전화
인터넷 상에서의 음성은 취미 생활자의 저렴한 필수품이 되었다. 몇몇 회사는 이 테크널리지를 발전시켜 PSTN과 상호작용하는 것을 포함하였다. 이것은 특히 IDDD 장에 있어서 MCI 및 BT와 같은 확립된 캐리어를 위해 도전 및 기회 양자를 제공한다. 이 논의는 상기 진전된 테크널리지를 기초로 하여 캐리어 클래스 서비스가 제공될수 있는 방법을 조사한다. 특히 관심의 대상이 되는 것은 1 플러스 다이얼링(1 plus dialing)을 사용하여 PSTN과 인터넷 사이에 상호작용하는 방법을 가능하게 하는 것이다.
예비적 논의로 PC 투 PC(PC to PC) 및 PSTN 투(to) 인터넷 음성 게이트웨이의 연결을 지원하기 위한 기술적 요구가 고려된다. 또한 PC에서 PSTN으로 또는 그 역으로 호출이 전달되는 방법이 고려된다. 또한 인터넷을 장거리 네트워크로 사용하여 PSTN 투 PSTN 통신의 경우가 조사된다.
현재의 PSTN 서비스를 보완하며, 더 낮은 서비스 품질에 대해 더 낮은 가격을 제공하는 서비스가 제공될 수 있는 방법을 보여준다. 긴 안목으로 볼 때, 인터넷 전화에 대한 품질의 지속적 개선 및 그 개선이 전통적 음성 서비스와 경쟁할 수 있는지가 논점이 된다.
1. 소개
1970년대 중반에, 인터넷 상에서의 음성 전송에 대한 실험이 미국 DARPA(Defence Advanced Research Project Agency)에 의해 후원되는 연구 프로그램의 일부로써 행해졌다. 1980년대 중반에, UNIX에 기초한 워크스테이션이 일반 음성/영상 회의 세션(session)을 수행하기 위해 사용되었다. 1980년대 후반에, 이러한 실험은 보다 대규모이며 음성 및 영상의 단방향 멀티캐스팅으로 확대되었다. 1995년에 보칼텍(VocalTec)이라는 작은 회사(www.vocaltec.com)가 인터넷에 연결된 멀티미디어 PC 사이에서 양방향 음성 통신을 제공할 수 있는 저렴한 소프트웨어 패키지를 소개하였다. 그 결과로 인터넷 상에서의 전화에 새로운 장이 펼쳐졌다.
최초의 소프트웨어 패키지 및 중간적 후속 패키지는 취미생활자에게 도구를 제공했다. 인터넷 중계 대화방에 기초한 회의 장소는 음성 전송을 위해 종단간에 점대점 연결을 설정하기 위해 사용되었다. 이것은 대화방에서 종종 일어나는 것과 같이 우연한 미팅을 야기하였으며, 또는 당사자가 이메일 또는 다른 수단에 의해 미리 조정한다면 미리 정해진 미팅을 야기하였다.
a) 작동 방법
멀티미디어 PC 및 인터넷 연결을 가진 유저는 작은 소프트웨어 패키지를 로딩함에 의해 인터넷 전화 용량을 가질 수 있다. 보칼텍에 있어서, 패키지는 수정된 대화 서버에 기초하여 회의 장소(IRC 서버)에 연결한다. IRC에서 유저들은 IRC에 연결된 다른 유저의 목록을 본다.
유저는 그의 이름에 클릭함에 의해 다른 유저를 호출한다. IRC는 그 응답으로 피호출자의 IP 주소를 송신한다. 인터넷의 다이얼-인 유저를 위해서, IP 주소가 다이얼-인 시간에 할당되고, 결과적으로 다이얼-인 세션 사이에 변화한다. 만약 목적지가 음성연결이 아직 되어있지 아니하다면, 그 PC는 링 신호를 울릴 것이다. 피호출 유저는 마우스 클릭을 통해 호출에 응답하고, 호출자는 피호출자의 IP 주소로 호출내용을 직접적으로 송신하기 시작한다. PC 내에 설치되거나 그에 결합된 멀티미디어 마이크로폰 및 스피커는 스피커폰으로 사용된다. 스피커의 음성은 인터넷을 통한 전송을 위해 디지털화되고, 압축되고, 패킷화된다. 반대편에서 그것은 PC의 스피커를 통해 압축이 풀리고 음성으로 변화된다.
b) 관계
인터넷 상에서의 전화는 유저에게 거리 및 국경에 무관하며, 저비용의 서비스를 제공한다. 인터넷 접속의 현재의 비용(시간당 저렴한 가격, 또는 정액제)으로, 호출자는 인터넷에 연결된 다른 PC 유저와 음성 대화를 할 수 있다. 피호출자는 자기의 인터넷 접속에 대한 비용을 지불함에 의해 대화의 비용을 부담한다. 양 종단 중 어느 하나 또는 모두가 전용회선에 의해 인터넷에 연결된 LAN이라면, 호출은 부가적 비용이 면제된다. 상기 모두는 전통적 장거리, 아마도 국제 통화와 대조를 이룬다.
c) 서비스 품질
인터넷을 통과하는 음질은 좋은 편이나, 전통적 전화 통화보다는 좋지 아니하다. 아울러, 대화 중에 상당한 지연이 있다. 스피커를 일시 중단하려는 시도는 문제점을 야기할 수 있다. 지연 및 품질의 변화는 거리 및 가용 용량의 결과이며, 압축, 버퍼링(buffering) 및 패킷하는 시간의 함수와도 관련이 있다. 음성 전송에 있어서의 지연은 몇 가지 인자에 기인한다. 가장 중요한 인자들 중의 하나는 사용되는 사운드 카드이다. 최초의 사운드 카드는 반이중 방식(half duplex)이였으며, 기록된 음성의 재생을 위해 고안되었다. 중단되지 아니하는 음성 재생의 보장을 도와주는 긴 음성 데이터 버퍼는 실시간 지연을 인도하였다. 스피커폰 응용을 위해 고안된 전이중 방식 카드가 유통됨에 따라 사운드카드에 기초한 지연은 점점 감소하고 있다.
다른 지연은 접속 라인 속도(통상 다이얼업 인터넷 접속에 대해서 14.4-28.8 Kbps) 및 인터넷 내에서의 패킷 전달 지연에 기인한다. 그리고 디지털화되고 코드화된 음성 패킷에 채우는 것에도 기인한다. 예를 들면 90 ms의 디지털화된 음성을 패킷에 채우기 위해서는 응용장치는 디지털화하기 위한 음성을 수신하기 위해서 적어도 90 ms를 기다려야 한다. 보다 짧은 패킷은 패킷-필링(filling) 시간을 감소시키나, 패킷 패이로드(payload) 데이터에 대한 패킷 헤더의 비율을 증가시킴에 의해 오버헤드(overhead)를 증가시킨다. 증가된 오버헤드는 응용 장치에 대한 대역폭의 요구를 증가시킨다. 따라서 짧은 패킷을 사용하는 응용장치는 14.4Kbps 다이얼 업 연결에 작동하지 아니한다. LAN에 기초한 PC는 보다 적은 지연을 경험하나, 모든 사람이 성가신 다양한 지연에 종속된다.
마지막으로 음성 코덱(codec)에서 기인한 지연이 있다. 코덱 지연은 코드화 또는 해독하는 데 있어서 5에서 30 ms까지 다양하다. 인터넷 전화와 관련된 보다 긴 대기시간에도 불구하고, 가격이 온당하며, 그리고 이런 형태의 음성통신은 점점 유행을 타고 있다.
2. 상업적 서비스를 위한 IP 전화(Phone)
IP 전화 테크널리지는 전통적 전화 시스템이 그것을 좋아하는지 또는 싫어하는지에 관계없이 존재한다. 국제 음성호출을 위해 인터넷을 사용하는 것은 전통적 국제 장거리 자동전화(IDDD) 수입 흐름에 잠재적 위협이 되고 있다. 몇 년이 지난 후에 상당한 수입의 영향이 있다고 하더라도, 규제에 바탕을 둔 국가의 경계 내에서를 제외하고는 그것은 포기될 수 없다. 전통적 전화 시스템에 의한 가장 좋은 방어는 그들 스스로 강력한 방식으로 상기 서비스를 제공하는 것이다. 그렇게 하기 위한 조건으로 발전된 호출 설치 설비 및 PSTN에 대한 인터페이스가 요구된다.
PC 투 PC 연결을 촉진시키는 것은 분리된 전화 설비에 접속하지 아니하고 인터넷 데이터 패킷 통신과 음성 대화를 동시에 행하는 경우에 매우 유용하다. 단지 하나의 접속회선을 가진 다이얼 업 인터넷 가입자는 그러한 상황에 직면할 수 있다. 비용에 대한 고려도 PC 투 PC 전화의 사용을 자극한다. 일반 전화기를 상호연결하기 위하여 장거리 네트워크를 대신하여 인터넷이 사용될 수 있을 때, 이 테크널리지의 사용은 크게 증가할 것이다. 세계에서 멀티미디어 인터넷에 연결된 PC의 수(천만으로 추정)는 가입자 회선의 수(66억으로 추정)에 비하여 소수이다. 이 서비스는 몇몇 회사가 계획하고 있다.
각 종단점 조합이 가능하다는 것이 아래의 단락에서 기술되어 있다. 가장 중요한 논점은 PSTN과 인터넷 게이트웨이의 연결에 관련되어 있다. 특히 관심의 대상이 되는 것은 PSTN 호출자로 하여금 피호출자에 대한 원스텝(one-step) 다이얼링을 할 수 있도록 하는 것이다. 아래에 기술된 원스텝 다이얼링 해결책은 북미 번호계획(numbering plan)의 문맥 내에 있다. 기본적으로 네 가지 경우나 있는 바:
1. PC 투 PC;
2. PC 투 PSTN;
3. PSTN 투 PC; 및
4. PSTN 투 PSTN 등이다.
첫 번째 경우에는 오늘날의 IP 전화 소프트웨어에 의해 주소 지정된다. 두 번째 및 세 번째는 유사하지만 같지 아니하며, 각각은 PS와 인터넷 사이에 게이트웨이를 요구한다. 마지막 경우는 두 PSTN 전화를 위해 인터넷을 장거리 네트워크로 사용한다.
a) PC 투 PC
(1) 디렉토리 서비스
PC 투 PC 인터넷 전화를 용이하게 하기 위해서는, 호출자에 의해 제공되는 이름에 기초해 피호출자의 IP 주소를 찾는 디렉토리 서비스가 필요하다. 초기의 인터넷 전화 소프트웨어는 수정된 인터넷 채트 서버(chat server)를 회의 장소로 제공한다. 최근에 인터넷 전화 소프트웨어는 채트 서버를 인터넷 전화 유저를 특정하게 식별(아마도 이메일 주소에 의해)하는 디렉토리 서비스로 대체하였다. 호출을 수신하기 위해, 고객은 디렉토리 서비스에 등록하고, 그들이 인터넷에 연결하거나 또는 호출에 응답하고자 할 때 그들의 위치(IP 주소)를 디렉토리 시스템에 알려준다. 자동적 통지를 위한 가장 좋은 방법은 소프트웨어가 시작할 때 디렉토리 서비스에 통지하는 프로토콜에 대해서 IP 전화 소프트웨어 벤더가 동의하는 것이다. 옵션으로, IP 스택(stack)이 시작할 때 IP 전화 소프트웨어를 자동적으로 불러들이는 방법을 찾는 것은 바람직할 것이다.
디렉토리 서비스는 확장성을 위해 인터넷 도메인 이름 시스템과 약간 닯은 분산형 시스템으로 계획되어 있다. 이것은 유저 식별을 위해 the user@foo.com 포맷을 의미하는 것은 아니다.
이론적으로 단지 피호출자만이 등록될 것을 요한다. 만약 호출자가 등록되어 있지 아니하다면, 호출에 대한 요금은 피호출자에게 부과(콜렉트 콜)될 수 있을 것이다. 반대로, 우리는 호출자도 또한 디렉토리에 등록되어야 하고 상기 메카니즘을 통해 요금이 부과되어야 한다고 주장할 수 있다(이것은 우리가 등록에 대한 요금을 부과하고, 콜렉트 콜을 요구하는 복잡성을 피하기 때문에 바람직하다). 통화 지속이 아니라 호출 설정에 대한 요금이 일반적 인터넷 요금보다 더 많이 부과된다. 통화 지속에 대한 요금은 다이얼업 인터넷 유저에게 미리 적용되고, 다이얼 업 및 전용 사용에 대한 인터넷 사용요금은 멀지 않아 적용될 것이다.
등록된 유저로부터의 콜렉트 콜은 시장 요구를 충족시키기 위해 필요할 수 있다. 피호출자가 콜렉트 콜을 받아들일 것인 지 또는 거부할 것인지를 결정하는 메카니즘과 더불어, 피호출자에 대한 그런 호출을 식별하기 위한 구성도 고안되어야 한다. 디렉토리 서비스는 이러한 기능을 지원하는 피호출 소프트웨어(the called software)의 능력을 버전 번호에 의해 추적할 것이다. 콜렉트 콜(호출자가 미등록임을 가정)의 경우에, 호출자는 그가 선택하는 어떤 사람이라도 될 수 있다. 디렉토리 서비스는 피호출자가 증명되지 않은 호출자임을 알 수 있도록 하기 위해 호출자가 임시적으로 "할당된" 주체가 될 것을 요구한다. IP 주소는 반드시 고정될 필요가 없기 때문에 상대방을 식별하기 위하여 그 주소에 의존할 수 없다.
(2) 상호운용성
오늘날 유통되고 있는 거의 모든 IP 전화 소프트웨어 패키지는 음성 정보를 교환하기 위해 서로 다른 음성 코드화(encoding) 및 프로토콜을 사용한다. 유용한 연결을 촉진시키기 위해서, 디렉토리는 사용되는 인터넷 전화 소프트웨어의 형태 및 버전을 저장해야 한다. 이 작업을 효과적으로 하기 위해, 소프트웨어 벤더는 이 정보를 자동적으로 디렉토리 서비스에 보고할 것이다. 이 정보는 호출이 있을 경우 상호운용성을 결정하기 위해 사용될 수 있다. 만약 당사자들이 상호운용성이 없다면, 적절한 메시지가 호출자에게 송신되어야 한다. 대체 방법으로, 또는 소프트웨어 형태의 등록에 부가하여, 교섭 프로토콜(negotiation protocol) 진행중의 상호운용성을 결정하기 위해 고안될 수 있으나, 모든 패키지는 그것을 말해야 한다.
IP 전화 코드화 사이의 변환이 최종 유저에게 받아들일 수 있을 정도로 수행될 수 있을 지에 대한 의문이 존재한다. 그런 서비스는 지속 및/또는 그것과 관련된 볼륨 요금(volumn fee)을 가질 수 있고, 그 사용을 제한할 수 있다. 또한 개선기간이 경과한 후에, 단지 몇 개의 구성만이 남고, 아마 그들은 최소 공통 분모 압축 및 시그널링 프로토콜을 통해 상호운용성을 가질 것이라고 예상할 수 있다. 지금까지 우리가 접촉한 모든 IP 전화 소프트웨어 벤더들은 상호운용성을 허용하는 에스페란토(Esperanto)를 선호한다. 만약 이것이 일어난다면, 변환 서비스의 수명이 짧아지고, 그것을 만드는 것은 경제적으로 매혹적이지 아니할 것이다.
우리는 주요한 소프트웨어 벤더가 필요한 상호운용성을 제공하는 "공통" 압축 구성 및 시그널링 프로토콜에 대한 일치를 추구하는 것을 도와줄 수 있다. 주요한 벤더가 이 방법을 지지한다면, 다른 벤더도 따라할 것이다. 이것은 인텔, 마이크로소프트, 네트스케이프, 및 보칼텍 등이 다음 달에 H.323 표준을 지지한다는 최근의 선언에 의해 벌써 일어나고 있다. 이것은 호출 설정 시에 자동적으로 확인될 수 있다. 디렉토리 서비스는 어떤 소프트웨어의 어떠한 버전이 상호운용할 수 있는 지를 기억하고 있다. 이 기능성을 촉진시키기 위하여, 존재의 자동적 통지는 현재의 소프트웨어 버전을 포함한다. 이런 방식의 업그레이드는 디렉토리 서비스에 동적으로 기록된다. 등록 정보가 소프트웨어 패키지 사이를 지나갈 수 있도록 하고, 따라서 유저가 패키지를 교체한다면 등록정보를 새로운 응용장치에 옮길 수 있도록 하기 위하여 몇몇 구성은 정의되어져야 한다. 유저가 같은 등록 정보를 가진 두 개의 응용장치를 가지고 있는 것에 대해서 반대할 이유가 없다. 디렉토리 서비스는 유저가 자동적 출석 통지의 일부분으로써 무엇을 실행하고 있는지를 알고 있을 것이다. 이것은 유저가 둘 이상의 IP 전화 패키지를 동시에 작동할 수 있는 경우에 한하여 문제점을 야기한다. 만약 시장이 이러한 능력을 요구한다면. 디렉토리 서비스는 이것을 다루기 위하여 보완될 수 있다. 상기 문제점은 상호작용하는 IP 전화 소프트웨어 패키지 사이에 교섭 방법을 사용함에 의해 또한 극복될 수 있다.
(3) 호출 프로그레스 시그널링(Call Progress Signaling)
만약 유저가 디렉토리 시스템을 사용하여 도달할 수 있으나 현재 음성 연결에 사용중이라면, 호출 대기 메시지(호출자 ID, PSTN 호출에 있어서는 사용될 수 없는 어떤 것과 함께)가 피호출자에게 송신되고, 대응되는 메시지가 호출자에게 반송된다.
만약 유저가 디렉토리 시스템을 사용하여 도달할 수 있으나 현재 음성 소프트웨어를 실행시키고 있지 아니하다면(IP 주소는 응답하나, 응용장치는 아닌 경우), 적절한 메시지가 호출자에게 보내어진다. (옵션으로, 호출 시도를 경보하기 위해서 이메일이 피호출자에게 보내어질 수 있다. 부가적 옵션은 호출자로 하여금 음성 메시지를 입력하도록 하고 음성 메일을 이메일에 부속시킬 수 있다. 상기 서비스는 호출자에게 바쁜, 도달할 수 없는, 작동중이나 호출대기를 무시한 등과 같은 것을 표시하라고 신호할 수 있다. 팩스 또는 페이징과 같은 피호출자에 대한 다른 통지 방법 또한 제공될 수 있다. 각각의 경우에 있어서, 통지는 호출자의 실체가 알려진 경우 그것을 포함할 수 있다.)
디렉토리 시스템이 분산되면, 로컬 정보에 기초해서 접촉이 이루어지지 아니한다면다른 카피를 요구하는 것이 필요하다. 이 시스템은 다양한 형태의 통지를 가질 수 있으며, 이러한 형태의 파라미터를 제어할 수 있다.
(4) 당사자 식별
중요한 의문은 피호출자가 마지막으로 보고한 곳에 있지 아니한 경우(어딘가로 사라진 경우) 디렉토리 시스템이 어떻게 이러한 사실을 아느냐 하는 것이다. 다이얼 인(dial in)되는 당사자는 디렉토리 서비스에게 상태의 변화를 알리는 능력 없이 다양한 방식(다이얼드(dialed) 라인을 끊거나. PC를 끄거나, 터미널 서버가 파괴되는 경우 등)에 의해서 네트워크를 빠져나갈 수 있다. 더욱 나쁜 것은, 어떤 유저는 네트워크를 방치하고, 음성 응용장치를 가진 다른 유저가 같은 IP 주소가 할당될 수 있다. (새로운 유저가 자동적 출석 통지를 가진 등록된 유저라면 문제점이 없다. 왜냐하면 디렉토리 서비스는 중복된 IP 주소를 발견할 수 있기 때문이다. 디렉토리 서비스의 분산 부분에 있어서 약간의 타이밍 문제점이 있을 수 있다.) 그러므로 디렉토리 서비스가 고객이 마지막으로 보고한 곳에 아직 있는지를 결정할 수 있는 몇몇 구성이 있어야 한다.
이것에 대한 하나의 접근은 등록 시에 응용장치와 공유된 비밀을 실행하는 것이다. 디렉토리 시스템이 소프트웨어(자동적 출석 통지 또는 호출 개시)에 의해 접촉되면, 또는 디렉토리 시스템이 최근에 알려진 위치에서 피호출자를 접촉하려고 시도하면, 그것은 응용장치에 챌린지(challenge)(채트와 같은)을 송신하고, 응답을 증명한다. 그런 구성은 "나는 지금 여기에 없다"라는 선언의 요구를 제거하거나, 또는 메시지의 쓸모 없는 보유를 제거한다. 고객은 디렉토리 시스템에 대한 통지에 대해서 염려하지 않고 그의 IP 전화 응용장치를 끄거나 연결을 언제든지 해제할 수 있다. 만약 다중 IP 전화 응용장치가 디렉토리 시스템에 의해 지원된다면, 그 각각은 챌린지를 다르게 할 수 있다.
(5) 다른 서비스
코드화된 인터넷 전화 대화는 부호설정 메카니즘의 수를 최소화하기 위해 소프트웨어 벤더들로부터의 일치를 요구한다. 이것은 디렉토리 시스템을 위한 또 다른 상호운용성의 해결 기능이다. 디렉토리 서비스는 공공의 주요한 응용 장치를 위한 지원을 제공하고, 적절한 증명 기관에 의해 발행되는 공공의 주요 증명서를 제공할 수 있다.
유저는 PC가 현재 온라인 되어 있지 아니하다면 그의 PC는 다이얼 아웃(dial out)되어야 한다라고 디렉토리 서비스에 지정할 수 있다. 다이얼 아웃에 대한 요금은 착신호 전환(call forwarding)을 위해 POTS에서 발생하는 것과 같이 피호출자에게 부과된다. 다이얼 아웃에 대한 호출 명세 기록(CDR - call detail record)은 IP 전화 시스템 내에 있는 엔티티(피호출자)의 호출 항목과 관련될 것을 요한다. 이것은 코드화된 음성을 PCM으로 변환을 요구하지 아니한다는 점에 있어서 PC 투 PSTN의 경우와 다르다는 것을 주의할 필요가 있다. 사실 다이얼 아웃은 PPP 상에서 TCP/IP를 사용한다. 다이얼 아웃이 실패한다면, 적절한 메시지가 반송된다.
다이얼 아웃은 국내 또는 국제적일 수 있다. 국제적인 경우에는 비용 때문에 실용적이지 아니하다. 그러나, 이 경우를 제외하는 이유가 없으며, 이것을 수행하기 위해서 부가적 기능성이 요구되는 것도 아니다.
b) PC 투 PSTN
PSTN 투 인터넷 게이트웨이는 다양한 벤더에 의해 제공되는 소프트웨어와 상호작용하기 위해 PCM을 다중 코드화 구성(multiple encoding scheme)으로 변환하는 것이 요구된다. 공통 압축 구성은 그것이 장착된다면 사용될 수 있다. 가능하다면, 질적인 측면에서 가장 좋은 구성이 사용되어야 한다. 많은 경우에 있어서, 그것은 벤더의 독점적 버전이다. 그것을 성취하기 위해서는 텔코(telco)는 선택된 벤더로부터 테크널리지를 라이센스할 필요가 있다. 몇몇 벤더는 텔코 플랫폼 상에서 그들의 구성이 작동하도록 하기 위해 필요한 작업을 할 것이다.
(1) 국내의 PSTN 목적지
PC 호출자는 PSTN에 호출하기 위해서 등록될 필요가 있다. 이거에 대한 유일한 예외는 인터넷으로부터 콜렉트 콜이 허용되는 경우이다. 이것은 요금 부과에 있어서 복잡함을 부가한다. PSTN 목적지를 호출하기 위해서, PC 호출자는 국내의 E.164 주소를 특정한다. 디렉토리 시스템은 상기 주소를 NPA-MXX에 기초한 인터넷 다이얼 아웃 장치에 맵한다. 다이얼 아웃 장치가 목적지에 근접해있고 따라서 로컬 호출이 되리라는 것이 예상된다. 그러나, 첫 번째 문제점은 로컬 다이얼 아웃 장치가 없는 경우에 이것을 어떻게 처리하는냐 하는 것이다. 또 다른 문제점은 만약 로컬 다이얼 아웃 장치가 가득차 있거나, 또는 가동될 수 없는 경우에 이것을 어떻게 처리하는냐 하는 것이다. 이것에 대한 3가지 접근 방법이 있다. 첫 번째 접근은 다이얼 아웃 서비스를 로컬 호출이 가능한 경우에만 제공하는 것이다. 두 번째 접근은 장거리 호출이 위치되어야 한다는 사실을 알리고, 이 비용의 발생을 허용할 것인 지의 여부를 질문하는 메시지를 호출자에게 반송하는 것이다. 세 번째 접근은 그것과 관계없이 그리고 아무런 통보도 하지 아니하고, 호출을 위치시키는 것이다. 각 접근방법은 다이얼 아웃 호출의 비용(PSTN CDR)을 호출 발신자(디렉토리 서비스를 경유하여)의 요금 부과 레코드와 상호 연관시키는 방법이 요구된다.
세 번째 접근 방법은 고객 지원 로드를 부가하고, 그리고 불행한 고객을 야기할 수 있다. 첫 번째 접근은 단순하나 제한적이다. 대부분의 유저는 비용을 매우 의식할 수 있으며, 따라서 첫 번째 접근 방법이 만족스러울 수 있다. 두 번째 접근방법은 고객이 어떠한 비용을 감수하더라도 호출을 위치시키는 경우에 대비한 확장성을 제공할 수 있으나 운영에 있어서의 복잡성을 야기할 수 있다. 가능한 절충안은 첫 번째 접근 방법을 사용하는 것이며, 따라서 로컬 다이얼 아웃의 경우에는 호출이 거부된다. 우리는 또한 호출이 장거리 호출에 귀결되더라도, 이를 상관하지 아니하는 호출에 대해서는 부속물을 부가할 수 있다. 이런 경우에는 최초에 호출이 거부된 자가 호출이 장거리 호출에 귀결되더라도, 이를 상관하지 아니하는 경우에는 부속세트를 이용하여 두 번째 호출을 시도할 수 있다. 재정이 여유 있는 고객에 대해서는 모든 PSTN 호출이 부속세트를 가지고 행해질 수 있다.
국내의 PSTN 호출을 위치시키는 것은 미국 외부의 인터넷 위치에서 발신된 인터넷 호출을 위한 국제적 호출 요구를 지원한다.
(2) 국제적 PSTN 목적지
국제적 PSTN에 대한 호출을 행하는 방법은 두 가지가 있다. 첫 번째는 국제적 호출이 국내의 다이얼 아웃 스테이션으로부터 위치되는 것이다. 이것은 고객이 그 스스로 국제 전화 호출을 행하는 것보다 돈을 절약하는 것이 아니기 때문에 매혹적인 방법이 아니다. 두 번째는 인터넷이 목적지 나라에 호출을 전달하고, 그리고 로컬 다이얼 아웃이 그 곳에서 행해지는 것이다. 이것은 국제적 목적지에 있는 캐리어에 의한 동의가 있어야 하기 때문에 문제점이 될 수 있다. 이런 경우는 다음의 두 가지 옵션에 의해 생존 가능하다. 첫 번째 옵션은 목적지 나라에 있는 로컬 캐리어를 파트너로 사용하는 것이다. 두 번째 옵션은 목적지에 있는 인터넷 서비스 제공자 또는 인터넷에 연결된 몇몇의 다른 서비스 제공자를 사용하는 것이다.
c) PSTN 투 PC (PSTN to PC)
이 경우는 그것의 완성을 위해서 몇몇 응용장치가 제공되고 있지만, 그것에 대한 관심은 떨어진다.
PC 투 PSTN 경우에서 나타난 바와 같이, PSTN 투 인터넷 게이트웨이는 다양한 벤더로부터의 소프트웨어와 상호작용하기 의하여 PCM을 다중 코드화 구성으로 변환하는 것을 지원할 필요가 있다. 디렉토리 시스템은 피호출 PC를 식별하기 위하여 요구된다. 자동적 출석 통지는 피호출자를 도달 가능하게 유지하는 데 있어서 중요하다. PSTN 호출자는 디렉토리 서비스에 등록할 필요가 없는데, 그 이유는 호출자 요금 부과는 PSTN 정보를 기초로 해서 행해지기 때문이다. 호출자는 항상 일정하며, 요금을 부과하고 호출을 되돌려 보내는 데 사용될 수 있는 E.164 주소를 가지고 있다. 아마도 우리는 누가 호출을 하고 있는지를 표시하기 위해 호출번호를 피호출자에게 전달할 수 있다. 호출 번호는 기술적 또는 개인의 프라이버시 때문에 항상 가동될 수 있는 것은 아니다. PC 소프트웨어에게 PSTN 호출이 도착했고, 그리고 E.164 번호를 제공하거나 또는 이것이 가동될 수 없음을 표시하는 것은 가능하다.
상기 서비스는 호출 전화에 요금을 부담시키는 것을 기초로 한다. 이것은 인터넷이 마치 장거리 호출의 일부분인 것과 같이 행해질 수 있다. 이것은 두 번째 발신음을 사용함으로서 가능하다. 만약 800 또는 로컬 다이얼 서비스가 사용된다면, 호출자가 요금 부과 정보를 입력하는 것이 필요하다. 반면에 900 서비스는 PSTN 호출자에 기초한 요금 부과를 가능하게 할 것이다. 위 두 가지 경우 중 어떠한 경우에도, 요금 부과 정보 후에 또는 900 번호를 다이얼링 한 후에 호출자가 목적지 전화 번호를 특정할 필요가 있다.
공개된 주요 논점은 호출자가 목적지를 두 번째 발신음에 특정하는 방법이다. 터치 톤(touch tone)이 가장 잘 가동될 수 있다. 엔트리를 단순화하기 위해, 우리는 E.164 주소를 각 디렉토리 엔트리에 보낼 수 있다. 실제 전화 번호(PSTN 투 PSTN)와의 혼동을 피하기 위해, 상기 번호는 디렉토리 제어 하에 있을 것이 요구된다. 충분한 용량을 가지고 있다면 700 번호가 사용될 수 있다. 대안으로 특정한 지역 코드가 사용될 수 있다. 터치톤(touch tone) 패드(PAD)를 사용하는 철자법은 유저에게 덜 친숙한 접근이다.
3. 인터넷에서의 전화 번호
가장 좋은 접근은 지역코드가 할당되는 것이다. 이것은 미래의 옵션을 개방된 상태로 유지할 뿐 아니라, 처음부터 보다 단순한 다이얼링을 허용한다. 합리적인 지역코드가 주어진다면, PSTN 호출자는 직접적으로 인터넷 상에 있는 PC의 E.164 주소를 다이얼 할 수 있다. 전화 시스템은 호출을 MCI POP에 라우팅할 수 있으며, 그 곳에서 PSTN-투-인터넷 음성 게이트웨이로 다시 라우팅될 수 있다. 피호출 번호는 호출을 PC가 온라인 상태이고 도달 가능하다면 PC에 위치시키기 위하여 사용될 수 있다. 이것은 PSTN 호출자로 하여금 인터넷을 PSTN의 일부분인 것처럼 간주하고 다이얼링하는 것을 허용한다. 두 번째 발신음 및 요금 부과 정보의 입력은 불필요하다. 호출에 대한 요금은 호출 PSTN 스테이션에 부과되고, 요금은 목적지 PC 대답하는 경우에 한하여 발생한다. 다른 캐리어에게는 특정 지역코드가 할당될 것이며, 그리고 디렉토리는 호환성이 유지되어야 한다.
국내에서 발신된 호출에 있어서, 호출자에게 부과하기 위해 필요한 모든 요금 부과 정보는 입수될 수 있으며, 제3자에 대한 지능망 서비스 기능 또는 다른 요금 부과 방법은 두 번째 발신음을 통해 가동될 수 있다.
4. 다른 인터넷 전화 캐리어
번호 휴대가 요구되는 경우에 이 모든 것은 보다 복잡해진다. 인터넷에 국가코드를 할당하는 것이 바람직할 수 있다. 이것은 국내 다이얼링을 보다 복잡하게 할 수 있지만(1+10개의 번호 외에도 다른 것을 다이얼링 하는 것은 상기 서비스의 사용을 매우 감소시킬 수 있다.), 그것은 몇 개의 바람직한 이점이 있다. 여하튼 간에 지역코드의 할당과 국가코드의 할당은 상호 배타적이지 아니하다. 국가코드의 사용은 다이얼링을 지리적으로 단일 표준으로 만든다.
5. 국제적 접속
미국 내에 있는 인터넷에 들어가기 위해 미국에 대한 국제적 호출을 행하는 것은 있음직하지 아니하는 것같다. 그러나, 만약 이것이 일어난다면, 시스템은 어떠한 기능성의 부가하지 않고도 호출자에 기초한 요금 부과를 행하는 충분한 정보를 가지고 있을 것이다.
또 다른 가능성은 미국 바깥에서 입중계 호출(incoming call)을 취급하기 위해, 그리고 미국 또는 인터넷 상의 어느 다른 나라에 되돌아가기 위해 그 나라에 있는 인터넷에 들어가는 것을 설치할 수 있다(파트너 관계로서)는 것이다. 만약 상기 파트너가 로컬 캐리어일 경우에는, 상기 파트너는 STN 호출자에게 요금을 부과하기 위하여 필요한 정보를 가지고 있을 것이다.
a) 콜렉트 콜
PSTN에서 PC로의 콜렉트 콜은 몇 단계를 거친다. 첫 단계는 PSTN에서 인터넷 게이트웨이로의 호출이 콜렉트 콜일 것을 요한다. 이 콜렉트 콜은 PC 투 PC와 같은 방식으로 신호된다. 호출자가 PSTN에 기초하였음을 표시하고, 가능하다면 호출하는 E.164 주소를 포함하는 것이 필요할 것이다.
b) PSTN 투 PSTN
PSTN과 인터넷 게이트웨이 사이에 음성을 전달하기 위한 음성 압축 및 프로토콜 구성의 선택은 전적으로 캐리어의 제어 하에 있다. 제공되는 압축 수준을 변화시킴에 의해 다양한 수준의 서비스가 제공될 수 있다. 각 수준에 따라 다른 요금이 부과될 수 있다. 호출자는 아마도 미리 다른 800 번호 서비스를 다이얼링함에 의해 품질 수준을 선택할 수 있다.
인터넷을 통한 호출을 행하는 데 있어서 호출자와 피호출자 어느 누구도 디렉토리 서비스에 등록할 필요가 없다. 호출자는 PSTN-to-인터넷 게이트웨이에 다이얼링하고, 두 번째 발신음을 수신하고, 터치톤을 사용하여 요금 부과 정보 및 목적지 국내 E.164 주소를 특정한다. 900 서비스도 또한 사용될 수 있다. 디렉토리 서비스(이것은 분리된 시스템일 수 있으나, 디렉토리 서비스는 PC 투 PSTN 다이얼 아웃 경우를 취급하기 위하여 미리 기능을 맵했었다)는 가능하다면 로컬 호출을 제공하기 위해 아웃 다이얼러(dialer)에 호출을 맵한다. 호출자에게 요금은 부과되고, 아웃 다이얼(out dial) 호출의 호출 명세는 인바운드(inbound) 호출자의 호출 명세와 관련될 필요가 있다.
의문은 상기의 PC 투 PSTN의 경우와 같이 피호출 번호에 가장 가까운 다이얼 아웃 장치가 장거리 또는 시외 호출을 야기할 경우 이를 취급하는 방법이다. 통지가 음성에 의해서 행해져야 하고 장거리 또는 시외 호출 다이얼 아웃을 행하는 것에 대한 인증은 터치 톤(touch tone)에 의해서 행해져야 한다는 점에 있어서 지금의 상황은 다르다. 장거리 다이얼 아웃의 경우에, 인터넷은 모두 생략될 수 있고 호출은 전적으로 PSTN 상으로 진행할 수 있다. 이 경우 인터넷을 사용하는 것이 경제적인지는 명백하지 않다.
(2) 원스텝 다이얼링
목적지 PSTN 번호가 입력될 필요가 있고, 전통적 장거리 네트워크 대신에 인터넷을 통해 목적지가 도착되어야 한다는 것이 표시되어야 한다는 것이 문제점이다.
이 선택 기준은 아래의 방법 중 어느 하나에 의해 전달될 수 있다:
1. 캐리어의 인터넷인 새로운 10XXX 번호의 할당.
2. 가입.
첫 번째 방법은 캐리어가 인터넷을 장거리 캐리어로써 선택할 수 있도록 한다. 두 번째 방법은 인터넷을 디폴트 장거리 네트워크로 만든다. 두 번째 경우에 있어서, 고객은 10XXX 코드를 다이얼링함에 의해 캐리어의 전통적 장거리 네트워크로 되돌아 갈 수 있다.
첫 번째 방법은 호출자가 여분의 5개 디지트를 다이얼링해야 한다는 결점을 가지고 있다. 비록 많은 사람이 돈을 절약하기 위하여 이것을 수행할지라도, 여분의 다이얼링을 요구하는 것은 이 서비스의 유저 수를 감소시킬 것이다. 두 번째 방법은 여분의 디지트를 다이얼링할 필요가 없으나, 인터넷을 장거리 네트워크로 대부분 사용하겠다는 가입자의 약속을 요구한다. 따라서 서비스 품질과 가격 중 어느 것을 선택하느냐가 선택의 결정요소이다.
PSTN 투 PSTN 경우에 있어서, 다른 가격에 다른 등급의 서비스를 제공하는 것을 고려하는 것은 가능하다. 이 등급은 코드화 구성과 적용되는 압축의 양(대역폭)의 조합을 기초로 하며, 낮은 대역폭 사용에 대해서는 낮은 비용이 요구될 것이다.
서비스 등급을 바람직하게 나타내기 위해서, 3개의 10XXX 코드가 사용될 수 있다. 가입에 의해, 특정한 등급은 미리 약정될 수 있으며, 다른 서비스 등급은 10XXX 코드에 의해 선택될 수 있다.
(3) 서비스 품질
서비스 품질은 두 개의 주요 인자에 의해서 측정될 수 있다. 첫 번째는 호출자의 음성을 인식할 수 있는 능력인 음질이고, 두 번째는 PSTN에서는 존재하지 아니하는 지연이다.
첫 번째 관점에 있어서, 우리는 오늘날 유용한 대부분의 제공물이 수용 가능한 음질을 제공한다고 말할 수 있다. 그러나 지연은 다르다. PC 투 PC 유저는 0.5초에서 2초 정도의 지연을 경험한다. 상기한 바와 같이(소개 부분), 대부분의 지연은 사운드 카드 및 저속 다이얼 접속에 기인한다. PSTN 투 PSTN 서비스에 있어서는 이 둘의 인자가 제거될 수 있다.
PSTN 투 인터넷 게이트웨이 경우에 있어서, DSP의 사용은 압축 및 프로토콜 처리 시간을 매우 낮춘다. 게이트웨이에 대한 접속은 PSTN 측에서는 64 kbps이고 인터넷 측에서는 거의 이서넷(ethernet)이다. 게이트웨이는 통상 백본 근처에 위치하기 때문에 이서넷 상의 라우터는 T3 라인에 의해 백본에 연결된다. 이 조합은 매우 낮은 지연을 갖는 서비스를 제공할 것이다. 몇몇 버퍼링이 백본에서의 다양한 지연을 제거하기 위해 필요할 수 있으며, 이것에 의해 국내 캐리어 백본에서 0.25초 이하의 지연으로 유지될 수 있다.
서비스 품질은 대역폭 사용과 관련된 음성 인식에 의해서 차별화된다. 필요하다면 보다 낮은 지연 편차를 보장하기 위해, 제안된 IETF 자원 예약 설정 프로토콜(RSVP - Resource reSerVation setup Protocol)이 사용될 수 있으나, RSVP의 부가에 의한 복잡함이 해결되어야 한다. 또한 대규모 인터넷 전화를 위한 RSVP의 확장성에 관한 문제점이 존재한다.
(4) 비용
장거리 음성 전송을 위해 교환전화망 대신에 인터넷을 사용하는 것이 실질적으로 더 경제적이냐 하는 의문이 있다. 현재에는 그러한 방식으로 가격이 책정되어 있으나, 현시가가 실질 비용을 나타내는 것인가? 라우터는 전화 회선 보다 확실히 더 싸다. 그리고 IP 소프트웨어가 사용하는 10 kbps(근본적으로 반이중 방식)는 전이중 방식(full duplex) 64 kbps DS0의 전용 128 kbps보다 더 적다. 이러한 비교에도 불구하고 상기 의문은 여전히 존재한다.
비록 라우터가 전화 회선보다 훨씬 싸지만, 라우터는 훨씬 적은 용량을 가지고 있다. 작은 빌딩 블록(building block)을 사용하여 대규모의 네트워크를 건설하는 것은 비싸고 최고점에 빨리 도달한다. 우리는 인터넷 백본이 종단 라우터들에 의해 과부하되는 것을 보아왔으며, 그리고 그들은 성공적 인터넷 전화 제공물이 가져다주는 상당한 호출량의 증가를 아직도 더 경험해야 할 것이다. 여기서 우리는 두 가지를 이야기 할 수 있다.
1. 현재의 인터넷 백본은 성공적 인터넷 전화 서비스와 관련된 주요한 호출량 증가를 지탱할 수 없는 것같다. 우리는 라우터의 테크널리지가 개선되기를 기다릴 필요가 있다.
2. 두 번째 논점은 대역폭의 사용에 관한 것이다. 10 kbps 반이중 방식(양당사자가 동시에 말한다면 약간 더 많으나, 침묵의 경우에는 훨씬 적은)은 64 kbps 전이중 방식 전용 용량보다 상당히 적다. 두 가지 관점이 이 논쟁에 주목된다.
첫째, 대역폭은 여분의 광섬유(spare fiber)가 있을 때에 싸다. 마지막 스트랜드(strand)가 사용되어지면, 그 다음 비트/초는 매우 비싸게 된다. 두 번째로, 대역폭이 매우 비싼 해양 통신 라우팅에 있어서, 우리는 벌써 9.6 kbps로 음성의 대역폭 압축을 하고 있다. 이것은 10 kbps의 인터넷 전화에도 근본적으로 동일하다. 어떻게 IP 용량이 POTS보다 훨씬 싸게 가격이 책정될 수 있을까? 가격 차이는 부분적으로 인터넷의 보조 내력과 관련되어 있다는 것이 그것에 대한 해답이다. 인터넷의 비용 문제를 다루는 인터넷 백본 제공자에 의해 진행 중인 하나의 프로세스가 있다. 이 프로세스의 본질은 인터넷이 사용 요금을 요구한다는 인식이다. 이러한 요금은 벌써 다이얼 업 유저에게 적용되고 있으나, 전용 연결을 가진 유저에게는 통상 적용되지 아니한다.
만약 PC 투 PC 인터넷 전화가 성행하면, 유저는 그들의 PC를 장시간 연결 상태로 유지하려고 할 것이다. 이것은 그들이 호출을 수신하기에 적합하게 만들 것이다. 그것은 또한 포트에서의 다이얼의 보유 시간을 증가시킬 것이다. 이것은 인터넷의 재정 및 반복되는 비용에 상당한 영향을 미칠 것이다.
(5) 요금
디렉토리 서비스는 상기한 기능을 제공하여야 하고, 서비스에 대한 요금 부과를 위한 정보를 충분히 수집하여야 한다. 요금은 디렉토리 서비스, 등록(가입비 + 월기본요금), 호출 설정 등에 대해서 부과될 수 있으며, 통화 지속에 대해서는 그러하지 아니하다. 통화지속에 대해서는 인터넷 다이얼 인 유저에게 미리 부과되며, LAN에 결합된 유저에게 통합적으로 부과되어 있다. 인터넷 서비스의 사용요금은 가까운 기간 내에 부과될 것이다. 통화 지속 요금은 입중계 또는 출중계 PSTN 세그먼트(segment)를 위해 가능할 수 있다.
입중계 PSTN 호출은 특정된 지역코드를 사용함에 의해 장거리 세그먼트로 요금이 부과될 수 있다. 다른 직접적 요금 부과 옵션에는 900 호출 및 전화 카드(또는 신용카드) 요금 부과 옵션 등이 있다.
모든 호출자가 디렉토리 서비스에 등록되어야 한다는 요구는 콜렉트 콜의 즉각적 필요성을 제거할 것이다. 이것은 IP 전화 서비스의 대부분의 유저는 호출의 수신 및 발신 양자를 원할 것이기 때문에 커다란 장애가 아니다. 호출자는 E.164 주소를 가진 엔트리와 같은 목록에 없는 엔트리를 가질 수 있으나, 이름은 그러하지 아니하다. E.164 주소가 주어진 호출자는 현재의 전화 시스템에 있어서와 같이 상대방을 호출할 수 있다(PSTN 또는 PC로부터).
상이한 압축 수준이 다른 품질의 음성 재생을 제공하기 위해 사용될 수 있으며, 그리고 약간의 인터넷 통과 자원을 동시에 사용할 수 있다. PC 투 PC 연결을 위해, 양 종단에 있는 소프트웨어 패키지는 사용되는 대역폭을 교섭할 수 있다. 이 교섭은 디렉토리 서비스를 통해 용이하게 될 수 있다.
(6) 기술적 논점
IP 전화 벤더가 등록, 자동적 출석 통지 및 증명 용량을 이행하도록 조정하는 것이 필요하다. 우리는 서비스 요구를 전달하는 능력을 부가하는 것이 필요하다. 이것은 장거리일지라도 PSTN에 대한 다이얼 아웃 호출을 수행하도록, 그리고 결정되어야 하는 다른 것을 특정하는 콜렉트 콜에 대한 권한 부여를 포함한다.
디렉토리에 대한 등록은 아래에 설명되는 필수적 기능이다. 분산형 디렉토리 서비스에 대한 DNS 모델은 이 기능 요구를 용이하게 하는 것같다. 가상의 E.164 번호를 디렉토리에 할당하는 것은 만약 실제적인 지역코드가 사용된다면 가장 잘 작동할 것이다. 만약 각 캐리어가 하나의 지역코드를 가지고 있다면, 이것은 디렉토리 시스템 사이의 상호작용을 훨씬 쉽게 할 것이다. 번호 휴대가 요구된다면 복잡성이 부가되는 것이 명백하다.
바람직한 실시예와 일치하는 IP 전화는 적어도 가까운 미래에는 계속 사용되고 있을 것이다. 이 테크널리지에 기초한 캐리어 수준 서비스의 조합 및 라우터의 용량에 있어서의 성장은 인터넷을 장거리 호출의 상당부분을 담당하도록 할 것이다.
케이블 모뎀과 같은 가정에서 보다 고속의 인터넷 접속은 양질의 IP 전화 서비스를 보다 쉽게 획득할 수 있도록 한다. 영상의 부가는 상기 서비스의 필요성을 보다 배가시킨다.
인터넷을 통한 팩스 서비스는 관심의 대상이다. 이것은 상기 언급한 음성 서비스와 유사하다. 팩스 프로토콜에 관련된 논쟁은 팩스 서비스를 보다 어려운 제공물로 만든다. 디지털 브릿지를 사용한 인터넷 사에서의 회의는 음성 및 영상 서비스를 보다 매혹적으로 만든다. 이것은 인터넷 세계에서 개발된 멀티캐스팅(multicasting) 테크널리지를 이용함에 의해 행해질 수 있다. 멀티캐스팅을 사용함에 의해, 그런 서비스를 제공하는 비용은 감소될 것이다.
C. 인터넷 전화 서비스
도 1C는 바람직한 실시예와 일치하는 인터넷 전화 시스템의 구성도이다. 프로세싱은 상대방이 전화번호를 다이얼링하고 응답함에 의해 전화 200이 호출을 개시하기 위해 사용되어질 때 시작한다. 전화 200은 통상 2선식(two-wire) 가입자 루프를 경유하여 연결되며, 이 루프를 통해 아날로그 음성 신호가 양방향으로 전달된다. 당해 기술분야의 보통의 기술자는 광섬유, ISDN, 또는 다른 수단에 의해 전화가 연결될 수 있다는 것을 쉽게 이해할 수 있을 것이다, 위의 방법에 대한 대안으로, 유저는 컴퓨터 210, 페이징 시스템, 영상 회의 시스템, 또는 다른 전화 케이블 장치 등을 통해 전화번호를 다이얼링할 수 있다. 이 호출은 지역 벨 오퍼레이팅 회사(RBOC) 중앙 스위치의 다른 이름인 국부 교환 캐리어(LEC)에 들어간다. 상기 호출은 LEC에 의해 MCI와 같은 상호교환 캐리어의 전용 공통 사무 회선(CBL - Common Business Line) 230에서 종료된다. CBL에 대한 종료의 결과로 MCI 스위치 221은 응답상태 표시를 수신한다.
스위치 221은 상기 응답상태에 대해 데이터 접속점(DAP)인 네트워크 제어 시스템(NCS)에 DAL 핫라인 절차 요구를 개시함에 의해 응답하게 된다. 스위치 221은 단일 DSI 상에서 작동하는 것을 보여주기 위하여 단순화되었으나, 복수의 라인 사이에 교환이 실제로 일어나고, 따라서 수천 명의 개별적 가입자가 스위치를 통해서 최종 목적지로 라우팅 될 수 있다고 이해되어야 한다. DAP 240은 라우팅 응답을 발신 스위치 221에 되돌려주고, 이것에 의해 이 발신 스위치 221은 호출을 목적지 스위치 230 또는 231에 라우팅 할 것을 지시한다. 호출의 라우팅은 트란잭션 정보를 특정 스위치 ID 및 특정 종료 트렁크 그룹으로 변환하는 DAP 240에 의해서 수행되고, 이 스위치 ID 및 특정 종료 트렁크 그룹은 목적지 스위치 230 또는 231에 도달시키기 위해 필요한 루트에 해당한다. 하이브리드 네트워크의 또 다른 실시예는 인터넷 접속 설비를 스위치 232에 통합한다. 이 통합체는 스위치 232가 인터넷 295에 직접적으로 결합할 수 있도록 하고, 이것은 네트워크를 인터넷 295에 연결하기 위한 필요한 포트의 수를 감소시킨다. DAP는 이 응답정보를 호출을 정확한 종료 스위치 230 또는 231에 라우팅하는 발신 스위치 221에 송신한다. 그리고 나서 종료 스위치 230 또는 231은 DAP의 라우팅 정보에 기초해서 호출을 ISN 250 또는 직접적으로 모뎀 풀 270에 라우팅하는 정확한 종료 트렁크 그룹을 찾는다. 만약 호출이 지능 서비스망(ISN) 250을 목적지로 한다면, DAP는 스위치에게 스위치 230에서 종료할 것을 지시한다.
다이얼링된 번호의 분석에 기초해서, ISN은 호출을 자동 음성 장치(ARU) 252에 라우팅한다. ARU는 음성, 팩스, 모뎀 호출을 구별한다. 만약 호출이 모뎀이 형태라면 유저를 인증하기 위한 인증 서버 291에 연결하기 위해 호출을 모뎀 풀 271에 라우팅된다. 만약 호출이 인증되면, 호출은 UDP/IP 또는 TCP/IP LAN 281 또는 다른 미디어 통신망을 통해 기본 인터넷 프로토콜 플랫폼(BIPP - Basic Internet Protocol Platform) 295로 전달되고, 이것은 또 다른 프로세싱 및 컴퓨터 또는 다른 미디어 장치에 최종적으로 전달된다.
만약 호출이 음성이라면, ARU는 호출자에게 카드번호 및 목적지 번호를 촉구한다. 카드 검증 데이터베이스를 사용하여 카드 번호가 검증된다. 카드 번호가 검증되면, 그리고 목적지 번호가 미국 내라면(국내 호출), 호출은 현재의 MCI 음성 라인 상을 통해 라우팅될 것이다. 만약 목적지 번호가 국제적이라면, 호출은 코덱(CODEC) 260으로 라우팅되고, 그 곳에서 음성을 TCP/IP 또는 UDP/IP로 변환하고, 그것을 LAN 280을 경유하여 인터넷 295에 송신한다. 호출은 목적지 게이트웨이를 통해 라우팅되고, 그리고 나서 최종적으로 전화 또는 다른 전화 등이 가능한 장치에 라우팅된다.
도 1D는 바람직한 실시예와 일치하는 하이브리드 스위치의 구성도이다. 참고 번호는 도1C와 일치하며, 부가적 블록 233이 부가된다. 블록 233은 스위치를 직접적으로 인터넷 또는 다른 통신 수단에 연결하기 위한 연결 장치를 가지고 있다. 연결 장치에 대한 명세는 도 1E에서 제공된다. 도1D의 하이브리드 스위치가 도1C의 스위치와 다른 주요한 차이점은 스위치 221이 직접적으로 인터넷 295에 연결될 수 있다는 것이다.
도1E는 도1D에서 설명된 연결 장치의 구성도이다. 메시지 부스 234는 스위치 조직 을 내부 네트워크 236 및 237에 연결한다. 동적 전화 연결(DTC) 238 및 239는 복수의 DS1 라인 232-235에서 발신되는 신호에 대한 데묵싱(demuxing)을 교대로 제공하고, 내부 네트워크 236 및 237은 이것을 교대로 수신한다. DS1 라인은 T1 라인 상에서 전통적 비트 포맷(bit format)으로 언급된다.
빨리 분산되는 전화/미디어 환경을 수용하기 위해, 실시예는 다른 내부 네트워크 237을 위해 분리된 스위치 연결을 사용한다. 풀드 스위치(pooled switch) 248, 249, 251, 254, 261-268로부터 수신된 전화/멀티미디어 신호를 취급하기 위해 스펙트럼 주변 모듈(SPM - Spectrum Peripheral Module) 247이 사용된다. 풀드 스위치 매트릭스는 제어 라인을 통한 스위치 명령을 통을 통해 SM 247에 의해 관리된다. SM 247은 서비스 제공자의 호출 처리 시스템과 통신하며, 이 시스템은 어떠한 라인이 어떠한 형태의 하이브리드 스위치를 요구하는 지를 결정하는 역할을 담당한다. 예를 들면, 팩스 전송은 전송을 디지털화된 음성이 아니라 디지털 데이터로 식별하는 톤(tone)을 생성한다. 디지털 데이터 전송을 확인한 후, 호출 처리 시스템은 호출 회로망에게 특정한 입력 라인이 풀드(pooled) 스위치 매트릭스를 통해 적절한 처리 특징을 가진 대응되는 라인에 대한 연결을 허용할 것을 지시한다. 따라서, 예를 들면, 인터넷 연결은 TCP/IP 모뎀 라인 268에 연결될 수 있으며, 이것에 의해 신호가 내부 네트워크 237을 통해, 메시지 부스 234를 통해 발신 스위치 221에 전달되기 전에 신호의 적절한 처리가 보장될 수 있다.
스위치를 인터넷에 직접적으로 연결하는 것을 용이하게 하는 것 외에도, 풀드 스위치 매트릭스는 현재의 통신 프로토콜 및 미래의 통신 프로토콜 수용하기 위해 스위치의 확장성을 증가시킨다. 메아리 제거 수단 261은 효율적으로 스위치에 배치되어 메아리를 제거한다. 상대적으로 작은 수의 메아리 제거기가 상대적으로 많은 수의 개별적 전송라인을 효율적으로 서비스한다. 풀드 스위치 매트릭스는 스위치의 어느 방향에서 나오는 접속측 전송 또는 네트워크측 전송이라도 OC 3 데묵스(demux), DSP 처리 또는 다른 전문적 처리로 동적으로 라우팅한다.
게다가, 도1E에 보이는 바람직한 실시예는 부가적 시스템 효율성을 제공한다. 음성 또는 데이터 회선 스위치의 어느 한쪽 상에 있는 포트 장치에 있어서, 다중처리 단계를 조합하여, 광섬유 케이블을 포트 장치의 다중처리된 출력에 직접 연결하는 것을 가능하게 하는 것이 그 예이다. 또한 다양한 통신 포트를 결합하기 위한 경로를 대체하기 위해, 리던던시(redunduncy)는 CEM 248/249 및 RM 251/254 상에서 유용한 대체 루트를 통해 스위치에 배치된다.
도1D의 스위치 221은 인터넷 295에 연결되는 데, 그 과정은 다음과 같다.
인터넷 295로부터의 라인은 모뎀 포트 268을 통해 스위치에 들어가고, 그리고 인터넷 네트워크 237 및 메시지 부스 234를 통해 스위치 221로 정보가 전달되기 전에 데묵스(demux) 및 다른 오퍼레이션을 수행하는 풀드 스위치 매트릭스에 들어간다. 모듈 261-268은 다양한 통신 부문으로부터 주변에 결합하기 위하여 플러그 앤드 플레이(play and play) 요양을 제공한다.
도1F는 바람직한 실시예와 일치하는 하이브리드(인터넷-전화) 스위치의 구성도이다. 하이브리드 스위치 221은 공용 교환 전화망(PSTN - Public switched telephone network) 상의 스위치를 인터넷 네트워크 상의 TCP/IP 또는 UDP/IP 포트로 교체한다. 하이브리드스위치 221은 PSTN 네트워크 인터페이스(247, 260), 고속 인터넷 네트워크 인터페이스(271, 272, 274), 일련의 디지털 신호 처리기(DSP)(259, 263), 시분할 다중처리 부스 262 및 고속 데이터 부스 275로 구성된다.
하이브리드 인터넷 전화 스위치221은 라우터 아키텍쳐와 회선 교환 아키텍쳐의 결합에 의해 발생한다. PSTN 인터페이스 275에 도달하는 호출은 ISDN 유저 파트(ISUP - ISdn User Part) 시그널링을 사용하여 개시된다. 피호출 번호와 선택적인 호출번호를 가지고 있는 최초 주소 메시지(IAM-Initial Address Massage)를 가지고 있는 PSTN 인터페이스 257은 최초 주소 메시지를 호스트 처리기 270으로 전송한다. 호스트 처리기 270은 기점의 PSTN 네트워크 인터페이스, 피호출 번호 및 다른 최초 주소 메시지 파라미터를 검사하고, 그리고 호출을 위한 출중계 네트워크 인터페이스를 선택한다. 출중계 네트워크 인터페이스의 선택은 라우팅 테이블에 기초하여 행해진다. 스위치 221은 라우팅 지시를 요구하기 위해 인터넷 상의 외부 서비스 제어 포인트(SCP - Service control Point) 276에 질문할 수 있다. 국부적 스위치 221에서 파생되거나, 또는 SCP로부터 파생된 라우팅 지시는 특정한 목적지에 도착하는 용도로 사용하는 서브네트(subnet)의 면에서 정의될 수 있다.
라우터와 같은 방식으로, 각 네트워크 인터페이스는 서브네트 주소를 사용하여 라벨링(labeling)될 수 있다. IP 주소는 컴퓨터가 위치하는 서브네트 주소를 가지고 있다. PSTN 주소는 IP 주소를 가지고 있지 아니하며, 따라서 서브네트는 PSTN 지역코드 및 교환에 맵된다. 스위치 221은 IP 주소 및 PSTN 주소에 대한 루트를 선택하는 데, 이것은 목적지 서브네트 또는 로컬 스위치에 보다 가까이 있는 패킷을 가지고 있는 서브네트에 대한 인터페이스를 선택함에 의해 이루어진다.
호출은 또 다른 PSTN 인터페이스 258을 경유하여 스위치를 빠져나가거나, 또는 고속 인터넷 네트워크 인터페이스 273을 경유하여 스위치를 빠져나갈 수 있다. 만약 호출이 PSTN 인터페이스 258을 경유하여 스위치를 빠져나가면, 이 호출은 표준 PCM 음성 호출의 형태로 빠져나가거나, 또는 압축된 디지털 음성을 전달하는 모뎀 호출의 형태로 빠져나간다.
호출은 표준 PCM 음성 호출의 형태로 스위치 221을 빠져나가면, PCM 음성은 TDM 부스 260을 사용하여 PSTN 인터페이스 257에서 PSTN 인터페이스 258로 스위치된다. 유사하게, PCM 음성은 TDM 부스 260을 사용하여 PSTN 인터페이스 258에서 PSTN 인터페이스 257로 스위치된다.
호출이 압축된 디지털 음성을 전달하는 모뎀 호출의 형태로 스위치를 빠져나가면, 스위치 221은 PSTN 인터페이스 258을 통해 PSTN 번호로 아웃바운드(outbound) 호출을 개시할 수 있으며, 그리고 TDM 부스 260을 가로질러 모뎀으로 작용하는 DSP 자원 259를 연결할 수 있다. 목적지와 모뎀 세션이 확립되면, PSTN 인터페이스 257 상에 있는 입중계 PCM 음성은 음성을 압축하는 음성 코덱으로 작용하는 DSP 자원 263에 연결될 수 있다. 음성 포맷의 예는 ITU G.729 및 G.723을 포함한다. 압축된 음성은 DSP 263 상에 있는 점대점 프로토콜(PPP) 패킷으로 패킷되며, 그리고 PSTN 인터페이스 258 상으로 모뎀 전달을 위해 DSP 259로 전송된다.
호출이 고속 인터넷 인터페이스 272 상에 있는 스위치 221을 빠져나가는 경우에는, 스위치 221은 PSTN 인터페이스 257을 PCM 음성을 압축하는 음성 코덱으로 작용하는 DSP 자원 263에 연결할 수 있으며, 그리고 음성을 인터넷 네트워크 상으로 전송하기 위해 UDP/IP 패킷으로 패킷한다. 고속 데이터 부스 275를 통해 UDP/IP 패킷은 DSP 자원 263으로부터 고속 인터넷 인터페이스 272에 전송된다.
도1G는 하이브리드 인터넷 전화 스위치 221과 관련된 소프트웨어 프로세스를 보여주는 구성도이다. 인터넷 네트워크 인터페이스 296 상에서 수신된 패킷은 패킷 분류기 293으로 전송된다. 패킷 분류기 293은 패킷이 일반 IP 패킷, 또는 라우팅 프로토콜(ARP, RAPP, RIP, OSPF, BGP, CIDR) 또는 관리 프로토콜의 일부분인지의 여부를 결정한다. 라우팅 및 관리 프로토콜 패킷은 라우팅 데몬 294로 전달된다. 라우팅 데몬 294는 패킷 분류기 293 및 패킷 스케줄러 298의 사용을 위해 라우팅 테이블을 유지 보수한다. 일반 IP 패킷으로 분류된 패킷은 패킷기/디패킷기(packetizer/depacketizer) 292 또는 패킷 스케줄러 298로 전송된다. PCM 음성으로 전환되는 패킷은 packetizer/depacketizer 292로 전송된다. packetizer/depacketizer는 패킷 내용을 받아들이고, 그것을 압축된 음성을 PCM 음성으로 변환하며, 이 PCM 음성을 PSTN 인터페이스 290으로 전송하는 코덱 291로 전달한다.
다른 인터넷 장치로 송신되는 일반 IP 패킷은 패킷 분류기 293에 의해 패킷 스케줄러 298로 전달되며, 이 스케줄러는 라우팅 테이블에 기초해서 패킷에 대한 출중계 네트워크 인터페이스를 선택한다. 패킷은 선택된 출중계 네트워크 인터페이스로 향하기 위한 아웃바운드(outbound) 패킷 큐(queue) 상에 놓여지며, 그리고 패킷은 인터넷 상으로 전달하기 위해 네트워크 인터페이스 296으로 전송된다.
D. 호출 처리
이 단락은 네트워크 문맥 내에서 호출이 처리되는 방법을 기술한다.
1. VNET 호출 처리
도10A는 LEC로 구성되는 공중 교환망(PSTN) 1000을 설명하고 있으며, 이 LEC를 통해 호출자는 전화 1021 또는 컴퓨터 1030을 사용하여 복수의 MCI 스위치 1011, 1011 등을 포함하고 있는 교환망에 접속하게 된다. 전화 호출을 라우팅하기 위한 디렉토리 서비스 및 다른 정보는 공용 분기 교환(1041, 1040) 및 PSTN 사이에 공유되는 디렉토리 서비스 1031에 의해서 제공된다.
이 일련의 시나리오는 VNET 호출을 수신 또는 발신하기 위해 가입자로 하여금 PC 및/또는 전화를 사용하게 한다. 이 서비스에서 가입자는 아래의 장비를 가질 수 있다.
·전화. VNET 라우팅을 사용하는 전화는 MCI의 네트워크에서 유용하다. 이와 같은 경우, 가입자의 VNET 번호를 사용하여 MCI PSTN 네트워크에 도달하는 VNET 호출은 현재 행해지고 있는 것과 동일하게 DAP를 사용하여 라우팅된다.
·인터넷 전화를 할 수 있는 PC. 호출은 로그인 상태 및 VNET 유저의 현재의 IP 주소를 추적하는 인터넷 또는 인트라넷 디렉토리 서비스를 사용하여 PC로부터 또는 PC로 라우팅된다.
·PC 및 전화는 호출을 수신 및 발신하기 위하여 사용될 수 있다. 이런 경우에, 유저 프로파일은 DAP 및 디렉토리 서비스로 하여금 입중계 호출을 PC로 송신 할 것인지 또는 전화로 송신할 것인지를 결정하도록 하는 정보를 가지고 있다. 예를 들면, 유저는 PC가 로그인 되었을 때에는 호출을 항상 PC로 송신하고, 그렇지 아니한 시간에는 전화로 송신하도록 할 수 있다. 또는, 유저는 일반적 작업 시간에는 호출을 항상 PC로 송신하고, 그렇지 아니한 시간에는 전화로 송신하도록 할 수 있다. 호출을 전화 또는 PC, 어디로 송신할 것인지를 결정하는 이런 유형의 제어는 가입자에 의해서 제어된다.
아래의 시나리오가 이런 유형의 서비스에 적용된다.
1. 디렉토리 서비스가 착신 PC의 위치에 대해서 질문을 받는 PC 투 PC 호출:
·인트라넷을 이송 장치로 사용하는 인트라넷에 연결된 PC들;
·양쪽 PC 모두 다이얼 업 접속에 의해 코퍼레이트 인트라넷에 연결된 PC;
·양쪽 PC 모두 인트라넷을 통해서 연결되는 분리된 인트라넷 상의 PC;
·양쪽 PC 모두 다이얼 업 연결을 통한 인터넷 상의 PC;
·코퍼레이트 인트라넷에 직접 연결된 하나의 PC 및 인터넷에 다이얼 업 연결된 다른 PC;
·코퍼레이트 인트라넷에 다이얼 업 연결된 하나의 PC 및 다이얼 업 연결된 다른 PC;
·양쪽 PC 모두 PSTN을 통해서 연결되는 분리된 인트라넷 상의 PC
·한쪽 PC 또는 양쪽 PC 모두 다이얼 업 접속에 의해 코퍼레이트 인트라넷에 연결된 PC;
·한쪽 PC 또는 양쪽 PC 모두 인터넷 서비스 제공자에 연결된 PC;
·인-네트워크(in-network) 요소로 한쪽 또는 양쪽 모두 ITG인 것.
2. 디렉토리 서비스가 착신 VNET가 전화인 것을 결정하도록 요구하는 PC 투 전화 호출. PC는 그리고 나서 호출을 착신 전화에 위치시키기 위해 인터넷 게이트웨이와 접촉한다.
·ITG를 아웃-네트워크(out-network) 요소로 가지며, PSTN에 연결된 전용 ITG를 사용하는 인트라넷 상의 PC. 목적지 전화는 PBX에 연결된다.
·상기 인트라넷 상의 PC는 또한 인터넷을 통해 접속되어야 하는 공용 ITG를 사용하는 PC일 수 있다.
·상기 인트라넷 상의 PC는 다이얼 업 접속을 사용하여 코퍼레이터 인트라넷에 연결되는 PC일 수 있다.
·ITG를 인-네트워크 요소로 가지며, PSTN에 연결된 전용 ITG를 사용하는 인트라넷 상의 PC. 목적지 전화는 PBX에 연결된다.
·상기 인트라넷 상의 PC는 또한 인터넷을 통해 접속되어야 하는 공용 ITG를 사용하는 PC일 수 있다.
·상기 인트라넷 상의 PC는 다이얼 업 접속을 사용하여 코퍼레이터 인트라넷에 연결되는 PC일 수 있다.
·ITG를 인-네트워크 요소로 가지며, PSTN에 연결된 전용 ITG를 사용하는 인트라넷 상의 PC. 목적지 전화는 PSTN에 연결된다.
·상기 인트라넷 상의 PC는 또한 인터넷을 통해 접속되어야 하는 공용 ITG를 사용하는 PC일 수 있다.
·상기 인트라넷 상의 PC는 다이얼 업 접속을 사용하여 코퍼레이터 인트라넷에 연결되는 PC.
·상기 ITG는 인-네트워크 요소일 수 있다.
·인트라넷을 통해 전달되는 호출을 가지는 PBX에 연결된 전용 ITG를 사용하는 인트라넷 상의 PC.
·상기 PC는 인터넷 또는 인트라넷 상으로 전달되는 목적지 전화와 다른 위치에 있다.
·상기 PC는 코퍼레이터 인트라넷에 다이얼 업 연결을 사용할 수 있다.
3. DAP 또는 PBX가 호출을 라우팅하기 위해서 착신 IP 주소 및 ITG를 식별하는 인터넷 디렉토리 서비스를 자극하는 전화 투 PC 호출. 상기 호출은 PSTN을 통해 ITG로 라우팅되고, ITG에서 목적지 PC로 연결된다.
가능한 변수:
PC 투 전화과 같은 변수가 있을 수 있다.
4. DAP 또는 PBX가 디렉토리 서비스로 하여금 가입자의 전화 또는 PC 중 어디에 착신할 것인지를 결정하도록 하는 전화 투 전화 호출.
가능한 변수:
·양쪽 전화 모두 PBX 상에 있다;
·어느 한쪽의 전화는 PBX 상에 있으며, 다른 전화는 PSTN 상에 있다; 및
·양쪽 전화 모두 PSTN 상에 있다.
이 변수들 각각에 있어서, DAP 및 디렉토리 서비스는 단일한 엔티티 또는 분리된 엔티티일 수 있다. 또한 디렉토리 서비스는 전용 서비스일 수 있거나 또는 공용 서비스일 수 있다. 각각의 시나리오는 호출 흐름 서술을 참조하여 아래에 기술되어 있으며, 바람직한 실시예와 일치한다. 호출 흐름도의 각 요소와 관련되어 있는 블록 요소는 실시예를 이해하는 데 있어서 도움을 주기 위해서 아래에 제공되어 있다.
2. 블록 요소의 설명
E. 재사용 가능한 호출 흐름 블록들
1. VNET PC는 공동의 인트라넷(intranet)으로 접속되며 디렉토리 서비스에 로그 인 한다.
1 .PC 사용자는 그들의 컴퓨터를 IP 네트워크에 접속하는데, 컴퓨터를 켜고 IP 텔레포니 서비스 패키지를 시작한다. 소프트웨어 패키지는 컴퓨터를 "온-라인"으로 등록하고 호출을 수신할 수 있도록 디렉토리 서비스에 메시지를 보낸다. 상기 온-라인 등록 메시지는, 아마 대부분 안전을 위하여 암호화된 형식으로 디렉토리 서비스에 보내어 질 것이다. 상기 암호화는 PC와 디렉토리 서비스간에 할당된 공유 키에 바탕을 둘 것이다. 상기 메시지는 다음의 정보를 포함하고 있다:
·상기 컴퓨터의 어드레스를 지정하는데 사용될 수 있는 가상 전용 네트워크 번호 또는 상기 컴퓨터의 어떠한 종류의 식별. 상기 VNET 시나리오에서, 이것은 PC를 사용하는 개인에게 할당된 VNET 번호이다. 상기 정보는 상기 사용자와 연결된 고객 프로파일을 식별하는데 사용되어 질 수 있다. 이것은 또한 이름, 피고용자 ID 또는 디렉토리 서비스가 VNET 고객 프로파일에 연결할 수 있는 어떠한 독특한 ID와 같은 어떠한 식별일 수도 있다.
·VNET 번호에 의하여 식별되어지는 사용자를 인증하기 위한 어떠한 다른 기구 또는 패스워드.
·상기 컴퓨터를 상기 네트워크에 접속하기 위하여 사용되어지고 있는 포트를 식별하는 IP 어드레스. 상기 어드레스는 상기 컴퓨터에의 접속을 설정하기 위하여 다른 IP 텔레포니 소프트웨어 패키지에 의하여 사용될 것이다.
·상기 메시지는 IP 텔레포니에 사용되어지는 PC 또는 소프트웨어 패키지의 상세와 소프트웨어 또는 PC의 구성/능력에 관한 추가적인 정보를 포함할 수 있다. 일 예로, 어떠한 타입의 압축 알고리즘이 사용되고 있는가 또는 그들에게 접속되는 다른 사용자의 능력에 영향을 미칠 수 있거나 또는 접속 동안 특별한 기능을 사용할 수 있는 소프트웨어 또는 하드웨어 의 다른 능력을 호출 PC가 아는 것은 중요할 수 있다.
상기 "온-라인" 메시지를 수신하는 디렉토리 서비스의 위치는 상기 고객을 위한 데이터 분산 구현에 의하여 결정될 것이다. 어떠한 경우에는, 이것이 VNET 서비스를 이용하는 단체 또는 회사를 위한 전용 데이터베이스일 수도 있고 다른 경우에는, 이것이 서비스 공급자의 모든 고객을 위한 국내 또는 전세계적인 데이터베이스일 수도 있다. 상기 로케이션은 PC상에서 실행되는 텔레포니 소프트웨어 패키지에 구성 배치된다.
2. 디렉토리 서비스가 PC로부터 상기 메시지를 수신 할 때, 이것은 사용자 프로파일을 찾는 VNET 번호를 사용하거나 프로파일에서의 패스워드를 수신 패스워드와 비교함으로써 사용자를 확인한다. 일단 사용자가 확인되면 디렉토리 서비스는 사용자가 "온 라인" 되었고 특정 IP 어드레스에 위치한다는 것을 나타내기 위하여 VNET 번호(또는 다른 고유 ID)와 관련된 프로파일 엔트리를 갱신할 것이다. 상기 디렉토리 서비스는 로그인 요청 중에 보내어진 구성 데이터를 가진 프로파일을 갱신한다. 성공적인 갱신과 동시에 디렉토리 서비스는 메시지가 수신되었고 처리되었음을 나타내는 응답을 특정 IP 어드레스로 돌려보낸다. 이러한 수신 통지 메시지는 추가적 명령을 낼 때 디렉토리 서비스와의 안전한 연락을 보장하기 위하여 안전 또는 암호 키를 또한 포함할 수 있다. PC가 상기 응답 메시지를 수신 할 때 그것은 가상의 또는 청취 가능한 인디케이터를 통하여 사용자에게 알리는 것을 택할 수 있다.
온-라인 등록을 위한 변환
본 장에서 먼저 보여진 호출 흐름 세그먼트는 PC 온-라인 등록을 보여 주었는데, 여기에서 상기 PC는 로그-온을 위하여 패스워드를 디렉토리 서비스에 단순히 보낸다. 상기 로그-온 절차를 위한 변환은 후속 호출 흐름 세그먼트일 수 있는데, 여기에서 상기 디렉토리 서비스는 수하(challenge)를 내놓고 PC 사용자는 로그-인 시퀀스를 완결시키기 위하여 수하에 대하여 응답하여야 한다. 로그-온 시퀀스상의 상기 변환은 본 서류에 포함되어 있는 어떠한 호출 흐름에서도 나타나지는 않으나 사용되어질 수는 있다.
1.PC 사용자는 그들의 컴퓨터를 IP 네트워크에 접속하고, 컴퓨터를 작동시키고, 그리고 IP 텔레포니 소프트웨어 패키지를 시작한다. 상기 소프트웨어 패키지는 컴퓨터를 "온-라인"으로 등록하고 호출을 수신하기 위하여 메시지를 디렉토리 서비스에 송신한다. 상기 온-라인 등록 메시지는 대부분 보안을 위하여 암호화된 포맷으로 디렉토리 서비스에 송신될 것이다. 상기 암호화는 상기 PC와 디렉토리 서비스 사이에서 공유 키이에 기초할 것이다. 상기 메시지는 다음과 같은 정보를 포함한다:
·상기 컴퓨터를 번지 지정하는데 사용될 수 있는 상기 컴퓨터 또는 가상 전용 네트워크의 어떠한 종류의 식별. 상기의 VNET 시나리오에서 이는 상기 PC를 사용하는 개인에게 할당된 VNET 번호이다. 상기 정보는 상기 사용자와 관련된 커스터머 프로파일을 식별하는데 사용되어질 것이다. 상기 정보는 상기 정보는 또한 상기 디렉토리 서비스가 VNET 커스터머 프로파일과 관련을 시킬 수 있는 이름, 피용자 ID 또는 어떠한 고유 ID와 같은 어떠한 식별일 수 있다.
·상기 컴퓨터를 상기 네트워크에 접속하는데 사용되어지고 있는 포트를 식별하는 상기 IP 어드레스. 상기 어드레스는 상기 컴퓨터에 접속을 설정하는 다른 IP 텔레포니 소프트웨어 패키지에 의하여 사용되어질 것이다.
·상기 메시지는 IP 텔레포니에 사용되어 지는 소프트웨어 및 PC의 상세와 소프트웨어 및 PC의 구성/능력에 관한 추가적인 정보를 포함할 수 있다. 예를 들면, 호출 PC가 사용되어지고 있는 압축 알고리즘의 형식 및 사용자에 접속되는 다른 사용자의 능력에 영향을 미치거나 접속 동안 특별한 특징을 사용할 수 있는 소프트웨어 및 하드웨어의 다른 능력을 아는 것은 중요할 수 있다.
상기 "온-라인" 메시지를 수신하는 디렉토리 서비스의 로케이션은 상기 커스터머를 위한 데이터 분산 실행에 의하여 결정될 수 있다. 어떠한 경우에는, 상기 디렉토리 서비스의 로케이션은 VNET 서비스에 가입한 회사 또는 단체를 위한 전용 데이터베이스일 수 있고, 다른 경우에는 서비스 프로바이더(MCI)의 모든 커스터머를 위한 국가적 또는 전세계적일 수 있다. 상기 로케이션은 PC 상에서 실행되는 상기 텔레포니 소프트웨어 패키지에 구성 배치된다.
2. 상기 시나리오에서 상기 PC는 개시 등록 메시지에 패스워드를 제공하지 않는다. 이는 디렉토리 서비스가 수하(challenge)/응답 등록 프로세스를 사용하기 때문이다. 상기 경우에, 상기 디렉토리 서비스는 상기 PC에 제공될 수하를 계산하기 위하여 공유 키이를 사용할 것이다.
3. 상기 PC는 상기 수하를 수신하고 상기 수하를 상기 PC 사용자에게 제공한다. 상기 PC 사용자는 수하에 대한 응답을 계산하고 상기디렉토리 서비스에 상기 응답을 다시 송신하기 위하여 공유 키이를 사용한다.
4. 상기 디렉토리 서비스가 사기 PC로부터 상기 응답을 수신할 때, 상기 디렉토리 서비스는 사용자를 타당성 검사한다. 일단 상기 사용자가 타당성 검사 되면, 상기 디렉토리 서비스는 상기 사용자가 "온-라인" 되었고 특정 IP 어드레스에 위치하는 것을 나타내기 위하여 VNET 번호(또는 다른 고유 ID)와 관련된 프로파일 엔트리를 갱신할 것이다. 상기 디렉토리 서비스는 또한 로그인 요청동안 송신된 구성배치 데이터를 가지는 프로파일을 갱신할 것이다. 성공적인 갱신이 있은 후, 상기 디렉토리 서비스는 상기 메시지가 수신되었고 처리되었음을 나타내는 특정 IP 어드레스로의 응답을 송신한다. 상기 수신 통보 메시지는 추가적인 명령을 발행할 때 디렉토리 서비스와의 안전한 통신을 보장하기 위하여 어떠한 종류의 보안 또는 암호화된 키이를 포함할 수 있다. 상기 PC가 상기 응답을 수신할 때, 상기 PC는 가시 또는 가청 표시기를 통하여 사용자에게 통지할 것을 선택할 수 있다.
2. VNET PC는 VNET 트랜스레이션을 위하여 디렉토리 서비스에 질문한다.
1. PC는 VNET 넘버에의 접속을 시도하기 위하여 인터넷 텔레포니 소프트웨어 패키지를 사용한다. 상기 접속을 설정하기 위하여 PC 사용자는 VNET 넘버(또는 이름, 피고용인 ID와 같은 또 다른 독특한 ID)로 다이얼 호출한다. 일단 텔레포니 소프트웨어 패키지가 상기 호출을 VNET 방식의 호출로 확인하면, 디렉토리 서비스에 트랜스레이션 요청을 보낸다. 최소한, 상기 트랜스레이션 요청은 다음의 정보를 포함한다.
·상기 요청을 보내는 IP 어드레스
·상기 요청을 보내는 VNET 넘버
·다이얼 호출된 컴퓨터의 VNET 넘버(또는 다른 ID)
·접속을 위한 요청된 구성. 예를 들면, 호출 PC는 텔레포니 소프트웨어 패키지 내부에 화이트-보드 가능 출력의 사용을 원할 수 있으며 접속을 설정하기 전에 착신 PC 상에 상기 가능 출력을 검증하기를 원할 수 있다. 만약 VNET 넘버가 PC로 번역되지 않는다면, 상기 구성 정보는 어떠한 잇점도 제공할 수 없으나 상기 요청을 보낼 때 사용자는 VNET 넘버가 PC 또는 전화로 번역되는지에 대하여 알 지 못한다.
2. 디렉토리 서비스가 상기 메시지를 수신 할 때, 상기 디렉토리 서비스는 VNET 넘버를 사용하여 상기 VNET 넘버와 관련된 사용자가 온-라인 되는지를 결정하며 컴퓨터가 접속될 수 있는 위치의 IP 어드레스를 확인한다. 상기 디렉토리 서비스는 또한 일 경로 지정의 시간, 주 경로 지정의 시간, ANI 스크리닝(screening) 등과 같은 특징을 포함하고 사용할 수 있다.
만약 VNET 넘버가 온-라인 된 PC로 번역된다면, 디렉토리 서비스는 착신 PC를 위한 프로파일 상에서 사용할 수 있는 구성 정보와 상기 요청상의 구성 정보를 비교할 것이다. 상기 디렉토리 서비스가 상기 발신 PC로부터의 번역 요청에 대한 응답을 돌려보낼 때 상기 응답은 다음의 사항을 포함할 것이다.
·착신 PC의 등록된 "온-라인" IP 어드레스. 이것은 발신 PC가 착신 PC에 접속하는데 사용될 수 있는 IP 어드레스이다.
·착신 PC의 가능 출력을 지시하는 구성 정보와 혹은 가능 출력이 발신 및 착신 PC간에 호환 가능한 어떠한 정보.
만약 VNET 넘버가 PSTN을 통하여 다이얼 되어야하는 넘버로 번역한다면, PC로의 응답 메시지는 다음을 포함할 것이다.
-MCI의 PSTN상으로 상기 호출을 하는데 사용될 수 있는 인터넷 텔레포니 게이트웨이의 IP 어드레스. 상기 게이트웨이의 선택은 선택 알고리즘의 번호에 바탕을 둘 수 있다. 사용되는 ITG와 호출자간의 이러한 관련은 디렉토리 서비스 내에 포함되는 프로파일에서의 정보에 바탕을 두고 만들어진다.
-착신 폰(phone)에 접속하기 위하여 ITG에 의하여 다이얼 된 VNET 번호. 상기 호출 흐름의 경우에 이것은 착신 폰의 VNET 번호이다. 이것은 호출이 DAP에 의하여 마련된 경로선택 기구와 현행 VNET 번역을 사용하는 것을 허용한다.
만약 VNET 번호가 고객의 PBX에 접속된 사적인 ITG를 통하여 도달할 수 있는 폰으로 번역되면 디렉토리 서비스는 다음과 같은 것으로 돌아올 것이다.
-착신 폰을 서비스하는 PBX에 접속된 ITG 게이트웨이의 VNET 번호. 착신 폰과 서빙 PBX에 접속된 ITG와의 상기 연결은 디렉토리 서비스에 의하여 마련된다.
-PBX로 호출을 할 때 ITG에 의하여 다이얼 되는 VNET 번호. 대부분의 경우에 이것은 단지 확장 번호일 것이다.
3. ITG에 대한 PC의 접속
1. PC는 ITG에 "접속" 메시지를 보내기 위하여 텔레포니 소프트웨어 패키지를 사용한다. 이러한 IP 어드레스는 일반적으로 VNET 번역에 대한 응답에서 디렉토리 서비스로 되돌아온다. 상기메시지의 특정 포맷 및 컨텐트는 메시지를 송신하는 소프트웨어 또는 상기 메시지를 수신하는 상기 ITG 소프트웨어에 의존한다. 상기 메시지는 상기 PC의 사용자를 식별하는 정보를 포함할 수 있거나 요청된 접속과 관련된 파라미터를 상세히 기술하는 정보를 포함할 수 있다.
2. 상기 ITG는 호출이 수신되었음을 나타내는 수신 통보와 함께 메시지에 대한 응답을 함으로써 상기 접속 메시지에 대해 응답한다. 호출 셋업의 본 단계는 ITG 호출 PC에는 필요하지 않을 수도 있으나, 본 단계는 상기 PC가 ITG 또는 또 다른 PC에 접속되었는지 여부에 관계없는 일관된 호출 셋업 절차를 유지하는 시도로 보여진다. PC에 접속될 때, 상기 절차의 본 단계는 상기 호출 PC가 착신 PC가 울리는지 아는 것을 허용한다.
3. 상기 ITG는 상기 호출을 받아들인다.
4. 음성 경로는 상기 PC 사이에서 설정된다.
4. PC에 대한 ITG 접속
1. ITG는 PC로 "접속" 메시지를 송신하기 위하여 자기의 텔레포니 소프트웨어를 사용한다. 상기 ITG는 접속되는 PC의 IP 어드레스를 알아야한다. 상기 메시지의 특정 포맷 및 컨텐트는 메시지를 송신하는 상기 ITG 소프트웨어 또는 메시지를 수신하는 상기 PC 소프트웨어에 의존한다. 상기 메시지는 ITG로부터 제공되는 정보로서 상기 호출을 식별하는 정보를 포함 할 수 있거나 상기 호출에 대한 요청된 구성 배치를 상세히 설명하는 정보를 포함할 수 있다.
2. 단계 1로부터의 메시지는 상기 PC에 의하여 수신되고 상기 메시지의 수신은 상기 PC가 상기 호출을 상기 PC 사용자에게 제공하고 있음을 나타내는 메시지를 상기 ITG에게 다시 송신함으로써 수신 통보가 된다.
3.상기 PC 사용자는 호출에 응답하고 상기 호출이 받아 들여졌음을 나타내는 메시지가 발신 PC로 다시 송신된다.
4. 음성 경로는 상기 ITG 및 상기 PC 사이에서 설정된다.
5. PC에 대한 VNET 호출 흐름 설명
PC 12 1051 사용자는 컴퓨터를 인터넷 프로토콜(IP) 네트워크 1071에 접속하고, 상기 컴퓨터를 키고, IP 텔레포니 소프트웨어 프로토클 시스템을 시작한다. 상기 시스템 소프트웨어는 상기 컴퓨터를 "온-라인"으로 등록하고 호출 수신 가능으로 등록하는 메시지를 디렉토리 서비스 1031에 전송한다. 상기 메시지는 상기 컴퓨터를 상기 네트워크에 접속하는데 사용되고 있는 접속을 식별하는 IP 어드레스를 포함한다. 상기 어드레스는 상기 컴퓨터에의 접속을 설정하는 다른 IP 텔레포니 소프트웨어 패키지에 의하여 사용되어 질 수 있다. 상기 어드레스는 상기 컴퓨터 1051을 번지 지정하는데 사용되어질 수 있는 가상 전용 네트워크 또는 상기 컴퓨터의 식별로 구성되어 있다. VNET 시나리오에서는, 상기 어드레스는 상기 PC를 사용하는 개인에게 할당된 VNET 번호이다. VNET은 전화 번호의 특정 세트가 호출을 교환할 수 있는 번호의 전용 네트워크로서 지원되는 곳인 가상 네트워크를 나타낸다. 다수의 기업체가 현재 기업체간 호출을 배치하고 수신하기 위한 전용 통신 채널으로서 이용되는 트렁크(trunk)에 통신 시간을 매입하고 있다. 또한 상기 어드레스는 이름, 피용자 ID 또는 어떠한 다른 고유 ID와 같은 어떠한 식별일 수 있다.
상기 메시지는 IP 텔레포니에 이용되는 PC 11 1051의 하드웨어 구성 배치 또는 시스템 소프트웨어의 상세에 관한 추가적인 정보를 포함할 수 있다. 예를 들면, 호출 PC가 어떠한 타입의 알고리즘이 지원되고 현재의 통신에서 실행되고 있는가와, 접속하는 다른 사용자의 능력에 영향을 미치거나 접속동안 특별한 기능을 사용할 수 있는 소프트웨어 및 하드웨어의 다른 능력을 아는 것은 중요하다.
6.인터넷상의 인터넷 텔레포니 게이트웨이의 인터넷 클라이언트에 대한 최상의 선택의 결정
도 10B는 바람직한 실시 예에 따른 인터넷 루팅 네트워크를 도시한다. 만약 인터넷상의 의뢰인 컴퓨터 1080의 인터넷 텔레포니 게이트웨이 1084로의 접속이 요구된다면, 선택하는 게이트웨이를 위한 이상적인 선택은 의뢰인의 요구에 따라 두 개의 카테고리로 분류된다.
만약 의뢰인 1080이 레귤러 PSTN 폰에 전화 호출을 하고 상기 PSTN 네트워크 사용이 인터넷 네트워크 사용에 비하여 저렴하거나 고 품질이 되는 것으로 결정된다면, 사용자가 인터넷 액세스 포인트에 최 근접한 포인트로부터 PSTN 네트워크에 액세스하는 것을 허용하는 게이트웨이를 선택하는 것이 바람직한 선택이다. 이것은 때때로 헤드-엔드홉-오프(HEHO)로 언급되는데, 여기에서 상기 클라이언트는 "헤드 엔드(head end)" 또는 "(near end)"에서 인터넷을 홉 오프(hop off)한다.
만약 클라이언트 1080이 레귤러 PSTN 폰으로의 전화 호출을 필요로 하고 상기 PSTN 네트워크가 인터넷 네트워크 사용에 비하여 고가로 결정된다면, 클라이언트가 착신 전화에 최 근접한 포인트로부터 PSTN에 액세스하는 것을 허용하는 게이트웨이를 선택하는 것이 바람직한 선택이다. 이 것은 타이-엔드 홉-오프(TEHO)로 언급되는데, 여기에서 상기 클라이언트는 인터넷의 테일 엔드("tail end") 또는 파 엔드("far end")에서 인터넷을 홉 오프(hop dff)한다.
a) 헤드-엔드 홉-오프 방식
(1) 클라이언트 핑 방식
이 방식은 후보 인터넷 텔레포니 게이트웨이 어드레스의 리스트를 확보하거나 루터 홉의 대기 시간 및 넘버의 최상의 선택을 결정하기 위하여 각각을 핑(ping)함으로써 최상의 헤드-엔드 홉-오프 인터넷 텔레포니 게이트웨이를 선택한다. 상기 프로세스는 다음과 같다.
■ 클라이언트 컴퓨터 1080 후보 인터넷 텔레포니 게이트웨이의 리스트를 얻기 위하여 디렉토리 서비스 1082에 문의한다.
■ 상기 디렉토리 서비스 1082는 클라이언트에 후보(candidates)를 제공하기 위하여 게이트웨이의 데이터베이스를 보고 게이트웨이의 리스트를 선택한다. 게이트웨이를 후보로 선정하는 판정 기준은 포함될 수 있다.
■ 선정된 마지막 게이트웨이.
■ IPv4 어드레스에서의 매칭 1, 2 또는 3 옥텟.
■ 알고 있다면, 마지막 클라이언트 액세스 포인트.
■ 도움이 된다면, 모든 주 게이트웨이 사이트로부터 적어도 하나의 게이트웨이 선택.
■ 상기 디렉토리 서비스 1082는 TPC/IP 메시지에서 "n" 후보 IP 어드레스를 클라이언트 1080에게 돌려보낸다.
■ 동시에 클라이언트 1082는 상기 IP 핑을 사용하여 에코 타입 메시지를 각 후보 인터넷 텔레포니 게이트웨이 1084,1081,1086으로 보낸다. 상기 "-알" 옵션은 추적 루트를 얻기 위하여 상기 핑 명령과 함께 사용되어 질 것이다.
■ 각 인터넷 텔레포니 게이트웨이의 핑 결과에 근거하여, 클라이언트 1080은 다음과 같이 핑 결과를 순서대로 정렬할 것이다:
■ 인터넷 텔레포니 게이트웨이가 핑 추적 경로에 의하여 드러난 어떠한 중재 루터를 통한 진행이 없이 클라이언트 1080에 액세스 할 수 있다면 그것들은 최초로 정렬된다.
■ 잔여 인터넷 텔레포니 게이트웨이는 왕복 여행 핑 결과(round-trip ping results)의 최저 대기 시간의 순으로 정렬된다.
상기 샘프 네트워크 위상(Sample Network Topology)을 가진 클라이언트 핑 방식을 사용하여, 상기 클라이언트 컴퓨터 1080은 디렉토리 서비스 1082에 핑 하는 인터넷 텔레포니 게이트웨이의 리스트를 문의한다:
166.37.61.117
166.25.27.101
166.37.27.205
상기 클라이언트 컴퓨터 1080은 동시에 다음의 명령을 발행한다:
ping 166.37.61.117-r1
ping 166.25.27.101-r1
ping 166.37.27.205-r1
핑 명령의 상기 결과는 다음과 같다:
32 바이트의 데이터를 가지는 Pinging 166.37.61.117:
166.37.61.117로부터의 응답: 바이트=32 시간=3분 TTL=30
경로: 166.37.61.101
166.37.61.117로부터의 응답: 바이트=32 시간=2분 TTL=30
경로: 166.37.61.101
166.37.61.117로부터의 응답: 바이트=32 시간=2분 TTL=31
경로: 166.37.61.101
166.37.61.117로부터의 응답: 바이트=32 시간=2분 TTL=30
경로: 166.37.61.101
32 바이트의 데이터를 가지는 Pinging 166.25.27.101
166.25.27.101로부터의 응답: 바이트=32 시간=14분 TTL=30
경로: 166.37.61.101
166.25.27.101로부터의 응답: 바이트=32 시간=2분 TTL=30
경로: 166.37.61.101
166.25.27.101로부터의 응답: 바이트=32 시간=3분 TTL=31
경로: 166.37.61.101
166.25.27.101로부터의 응답: 바이트=32 시간=4분 TTL=30
경로: 166.37.61.101
32바이트의 데이터를 가진 Pinging 166.37.27.205
166.37.27.205로부터의 응답: 바이트=32 시간=1분 TTL=126
경로: 166.37.27.205
166.37.27.205로부터의 응답: 바이트=32 시간=1분 TTL=126
경로: 166.37.27.205
166.37.27.205로부터의 응답: 바이트=32 시간=1분 TTL=126
경로: 166.37.27.205
166.37.27.205로부터의 응답: 바이트=32 시간=1분 TTL=126
경로: 166.37.27.205
166.37.27.205로 선택된 경로는 루터를 경유하지 않는다(경로와 핑 어드레스는 동일하다). 잔여 인터넷 텔레포니 어드레스는 평균 대기 시간 순으로 정렬된다. 인터넷 텔레포니 게이트웨이의 바람직한 정렬 결과는
166.37.27.205
166.37.61.117
166.25.27.101
첫 번째 선택 게이트웨이는 대부분 고 품질의 서비스를 주는데 적당한데 그 이유는 동일한 로컬 에어리어 네트워크에 위치하기 때문이다. 상기 게이트웨이는 상기 클라이언트가 사용을 시도하는 첫 번째가 될 것이다.
(2) 액세스 디바이스 로케이션 방식
인터넷 텔레포니 게이트웨이의 최적의 선택을 식별하기 위한 방식은 위에서 상술한 클라이언트 핑 방식의 조합과 상기 클라이언트 컴퓨터 1080이 인터넷에 액세스되는 기점에 대한 정보를 이용한다. 상기 방식은 다이얼-업 액세스 디바이스를 통하여 인터넷에 액세스하는 클라이언트에 효과가 있을 수 있다.
클라이언트 컴퓨터 1080은 인터넷 액세스 디바이스에 다이얼 호출한다. 상기 액세스 디바이스는 상기 호출에 응답하고 모뎀 톤을 작동한다. 그 때, 상기 클라이언트 컴퓨터와 액세스 디바이스는 PPT 세션을 설정한다. 상기 클라이언트 컴퓨터의 상기 사용자는 확인된다(확인 서버에 의하여 타당성 검사되는 사용자명/패스워드 프롬프트). 일단 사용자가 확인을 통과하면, 상기 액세스 디바이스는 확인된 사용자를 위하여 디렉토리 서비스의 사용자 프로파일을 갱신하는데, 다음과 같은 정보를 적립한다.
"사용자명""어카운트 코드""온라인 타임스탬프"
"액세스 디바이스 사이트 코드"
나중에, 상기 클라이언트 컴퓨터가 인터넷 텔레포니 게이트웨이를 통하여 액세스를 요구할 때, 그 것은 최상의 인터넷 텔레포니 게이트웨이의 선택을 결정하기 위하여 디렉토리 서비스 1082에 문의한다. 액세스 디바이스 사이트 코드가 디렉토리 서비스의 사용자 프로파일에서 발견된다면, 상기 디렉토리 서비스 1082는 동일한 사이트 코드에서 인터넷 텔레포니 게이트웨이 1084, 1081과 1086을 선택하고 상기 IP 어드레스를 클라이언트 컴퓨터 1080에 돌려보낸다. 인터넷 텔레포니 게이트웨이 1084, 1081과 1086이 상기 액세스 디바이스 사이트 코드와 동일한 사이트에서 사용될 수 없다면, 그 때는 디렉토리 서버에 저장된 네트워크 위상 맵에 따라 차선의 선택이 이루어진다.
상기 디렉토리 서버 1082에서 액세스 디바이스 사이트 코드가 전혀 발견되지 않는다면, 그 때는 상기 클라이언트 1080이 디렉토리 서버 1082를 갱신할 수 없는 디바이스를 통하여 상기 네트워크에 액세스한다. 상기 와 같은 경우라면, 전술한 상기 클라이언트 핑 방식은 최선의 대체 인터넷 텔레포니 게이트웨이를 정하는데 사용된다.
(3) 사용자 프로파일 방식
인터넷 텔레포니 게이트웨이 1084, 1081과 1086을 선택하는 또 다른 방식은 디렉토리 서버에 저장되어 있는 사용자 프로파일에 게이트웨이를 선택하는데 필요한 정보를 내장하는 것이다. 상기 방식을 사용하기 위해서는, 사용자는 상기 클라이언트 컴퓨터에 인터넷 텔레포니 소프트웨어 패키지를 실행시켜야 한다. 최초에 상기 패키지가 실행되면, 등록 정보가 사용자로부터 집합되는데, 사용자명, 이메일 어드레스, (고정 로케이션 컴퓨터를 위한) IP 어드레스, 사이트 코드, 어카운트 코드, 유쥬얼 인터넷 액세스 코드와 기타의 관계되는 정보를 포함한다. 일단 상기 정보가 사용자에 의하여 입력되면, 상기 소프트웨어 패키지는 상기 정보를 디렉토리 서버에 특히 사용자 프로파일에 적립한다.
상기 사용자가 상기 인터넷 텔레포니 소프트웨어 패키지를 시작하면, 사용자의 상기 IP 어드레스는 디렉토리 서비스에서 자동적으로 갱신된다. 이 것은 자동 존재 통지(automated presence notification)로 알려져 있다. 나중에 상기 사용자가 인터넷 텔레포니 게이트웨이 서비스를 필요로 할 때, 상기 사용자는 디렉토리 서비스에게 사용 가능한 인터넷 텔레포니 게이트웨이에 대하여 문의한다. 상기 디렉토리 서비스는 상기 사용자의 IP 어드레스와 상기 사용자의 유쥬얼 사이트 및 상기 네트워크로의 액세스 포인트를 알고 있다. 상기 디렉토리 서비스는 상기 클라이언트 컴퓨터를 위한 사용 가능한 인터넷 텔레포니 게이트웨이를 선택하기 위하여 모든 인터넷 텔레포니 게이트웨이 1084, 1081과 1086의 네트워크 지도에 더하여 상기 정보를 이용할 수 있다.
(4) 게이트웨이 핑 방식
마지막 방식은 후보 인터넷 텔레포니 게이트웨이 어드레스의 리스트를 얻고 대기 시간과 루터 홉의 숫자에 따라 최상의 선택을 하기 위하여 각각을 핑함으로써 헤드-엔드 홉-오프 인터넷 텔레포니 게이트웨이에 대한 최상의 선택을 한다. 상기 프로세스는 다음과 같다.
■ 클라이언트 컴퓨터는 인터넷 텔레포니 게이트웨이에 대한 최상의 선택을 얻기 위하여 상기 디렉토리 서비스에 문의한다.
■ 상기 디렉토리 서비스는 게이트웨이의 데이터베이스를 찾고 후보 게이트웨이의 리스트를 선택한다. 후보로서의 게이트웨이 선택 기준은 다음을 포함할 수 있다.
■ 선택된 마지막 게이트웨이.
■ IPv4 어드레스에서의 매칭 1, 2 또는 3 옥텟.
■ 알고 있다면, 마지막 클라이언트 액세스 포인트.
■ 실용적이 다면, 모든 주 게이트웨이 사이트로부터 최소 하나의 게이트웨이의 선택.
■ 상기 디렉토리는 각 후보 게이트웨이에게 클라이언트 컴퓨터의 IP 어드레스를 핑하도록 명하는 메시지를 각 후보 게이트웨이에 보낸다.
■ 각 후보 게이트웨이는 동시에 상기 IP 핑을 사용하여 에코-타입 메시지를 상기 클라이언트 컴퓨터에 보낸다. 추적 경로를 얻기 위하여 상기 핑 명령과 함께 알-옵션을 사용할 수 있다. 상기 핑 결과는 각 후보 게이트웨이로부터 상기 디렉토리 서비스로 되돌아간다.
■ 각 인터넷 텔레포니 게이트웨이에 대한 핑 결과에 근거하여, 상기 디렉토리 서비스는 다음과 같은 핑 결과를 순서 정렬한다.
■ 어떠한 인터넷 게이트웨이도 어떠한 중재 루터를 통한 진행 없이 상기 핑 추적 경로에 의하여 드러난 상기 클라이언트에 액세스 할 수 있다면, 그 것들은 최우선으로 정렬된다.
■ 잔여 인터넷 텔레포니 게이트웨이는 왕복 핑 결과의 평균 대기 시간이 적은 손으로 정렬된다.
상기 클라이언트 핑 방식과 게이트웨이 핑 방식은 헤드-엔드 홉-오프 게이트웨이에 대한 최상의 선택을 함에 있어서 상기 핑 프로그램을 대신해서 추적경로 프로그램을 사용할 수 있다.
(b) 테일-엔드 홉-오프 방식
테일-엔드 홉-오프는 상기 인터넷으로부터 출 구점으로 게이트웨이를 선택하는 것을 수반하는데, 여기에서는 가능한 상기 출구점이 터미네이팅 PSTN 로케이션에 가장 밀착되어 있다. 이 것은 고 PSTN 호출률을 피하는 것이 요구된다. 상기 인터넷은 착신 전화 번호의 로컬 호출 에어리어로 패킷화된 음성을 가지고 오는데 사용될 수 있는데, 여기에서는 PSTN상에 상기 호출을 운반하는데 낮은 로컬률이 지불될 수 있다.
(1) 게이트웨이 등록
테일-엔드 홉-오프 서비스의 한 가지 방식은 인터넷 텔레포니 게이트웨이 1084, 1081과 1086이 디렉토리 서비스에 등록하게 하는 것이다. 각 인터넷 텔레포니 게이트웨이는 상기 디렉토리 서비스에 상기 디렉토리 서비스가 서비스하는 호출 에어리어를 정렬하는 프로파일을 가질 것이다. 이것들은 국가 코드, 에어리어 코드, 교환국, 도시 코드, 라인 코드, 무선 셀, 로컬 액세스 트랜스포트 에어리어(LATA) 또는 넘버링 플랜을 서브세트 하는데 사용될 수 있는 어떠한 다른 방식에 따라서 정렬될 수 있다. 상기 게이트웨이는 시작과 동시에 상기 디렉토리 서비스에 상기 디렉토리 서비스가 서비스하는 상기 영역으로 정렬하는 TCP/IP 등록 메시지를 보낸다.
클라이언트 컴퓨터가 TEH0 서비스를 사용하기를 원하면, 그것은 상기 디렉토리 서비스에게 원하는 착신 전화 번호를 서비스하는 인터넷 텔레포니 서비스 1084에 관하여 문의한다. 상기 디렉토리 서비스 1082는 자격을 주는 인터넷 텔레포니 게이트웨이를 찾고, 하나가 발견되면, 사용 가능한 상기 게이트웨이의 IP 어드레스를 되돌려 보낸다. 동일한 착신 전화 번호를 서비스하는 다중 인터넷 텔레포니 게이트웨이 1084, 1081 과 1086을 가로지르며 호출량 균형을 맞출 수 있게 하기 위하여 부하 균형 알고리즘을 사용할 수 있다.
인터넷 텔레포니 게이트웨이 1084, 1081과 1086이 특별히 주어진 착신 텔레포니 번호의 호출 에어리어를 전혀 서비스하지 않는다면, 상기 디렉토리 서비스 1082는 상기 클라이언트 컴퓨터 1080에게 에러 TCP/IP 메시지를 되돌려 보낸다. 상기 클라이언트 1080은 그 때 특정 착신 전화 번호를 서비스하는 게이트웨이만이 아니라 어떠한 인터넷 게이트웨이에 관해서도 상기 디렉토리 서비스에게 문의할 수 있는 선택권을 가진다.
상기 게이트웨이 등록 기구의 개량형으로서, 게이트웨이는 모든 호출 에어리어를 위하여 제공되는 호출률을 등록할 수 있다. 예를 들면, 게이트웨이가 시애틀에서 전혀 사용할 수 없다면, 로스앤젤레스에서의 게이트웨이로부터 시애틀을 호출하는 것은 포틀 랜드에서의 게이트웨이로부터 시애틀을 호출하는 것보다 저렴할 수 있다. 상기 디렉토리 서비스에 등록된 상기 호출률은 상기 디렉토리 서비스가 어떠한 특정 호출을 사용하기 위한 게이트웨이를 가장 저렴하게 하도록 할 수 있다.
7. VNET 호출 프로세싱
도 11은 바람직한 실시 예에 따른 호출흐름 다이어그램을 보인 도면이다. 프로세싱은 1101에서 시작되는데, 여기서는 온-라인 메시지를 받은 디렉토리 서비스의 로케이션이 상기 고객을 위하여 데이터 분산 실행에 의하여 결정될 것이다. 어떠한 경우에는 이것은 VNET 서비스에 가입한 회사 또는 조직을 위한 사적 데이터 베이스일 수 있고 또 다른 경우에는 이것이 서비스 프로바이더(MCI)의 모든 고객을 위한 국제적 또는 전세계적 데이터베이스일 수 있다. 상기 디렉토리 서비스가 PC12 1051로부터 상기 메시지를 받을 때, 그것은 상기 사용자가 온-라인 되어 있고 특정 IP 어드레스에 위치하는 것을 나타내는 고유 ID와 관련된 프로파일 엔트리를 갱신할 것이다. 1102에서는 상기 ID와 관련된 상기 프로파일의 성공적인 갱신이 있은 후에 상기 디렉토리 서비스는 메시지가 수신되었고 처리되었음을 나타내는 응답(ACK)을 특정 IP 어드레스로 보낸다. 상기 컴퓨터가(PC12)가 상기 응답 메시지를 받을 때, 시각 또는 청각 인디케이터를 통하여 사용자에게 통지하는 것을 선택할 수 있다.
1103에서 PC11 1052의 사용자는 IP 네트워크에 컴퓨터를 접속하고 상기 컴퓨터를 켜고 텔레포니 시스템 소프트웨어를 시작한다. 상기 컴퓨터에 대한 등록 프로세스는 PC12 1051의 프로세스와 유사한 절차를 따른다. 상기 시나리오에서는 상기 메시지를 받은 디렉토리 서비스가 물리적으로 또는 논리적으로 PC12 1051로부터 메시지를 받은 디렉토리 서비스와 같다는 것을 상정한 것이다.
1104에서 상기 디렉토리 서비스 1031이 PC11 1052로부터 메시지를 받을 때, 상기 디렉토리 서비스는 PC12 1051에서의 메시지에 뒤따르는 절차와 유사한 절차를 시작한다. 그러나 상기 경우에는 PC11 1052로부터 받은 식별자와 관련된 프로파일을 갱신할 것이고 PC11 1052로부터 받은 IP 어드레스를 사용할 것이다. 갱신된 프로파일 정보로 인하여 확인 응답이 상기 디렉토리 서비스로부터 보내어질 때, PC11 1052와 관련된 IP 어드레스로 보내어진다. 상기 포인트에서, 양 컴퓨터(PC12 1051과 PC11 1052)는 "온-라인" 되고 호출을 받는데 사용될 수 있다.
1105에서는 PC12 1051이 컴퓨터 PC11 1052에 접속하기 위하여 PC 12 1051의 텔레포니 시스템 소프트웨어를 사용한다. 상기 접속을 설정하기 위하여, PC 12 1051의 사용자는 VNET 번호(또는 성명, 피고용인 ID 등 다른 고유 ID)를 다이얼 호출한다. 소프트웨어 패키지와 고객 네트워크의 실행에 따라 고유 네트워크 아이덴파이어는 상기 다이얼 스트링에 위치하여야 할 지 모른다. 예를 들면, VNET의 텔레포니 실행에서, 가입자는 상기 호출의 루팅을 위하여 VNET 네트워크를 사용중이라는 것을 PBX에 신호하기 위하여 VNET 번호를 다이얼하기 전에 번호 8을 입력할 것이 요구된다. 일단 상기 텔레포니 소프트웨어패키지가 상기 호출을 VNET 타입 호출로 식별하면, 상기 텔레포니 소프트웨어 패키지는 상기 디렉토리 서비스에게 번역 요청을 보낼 것이다. 최소한, 상기 번역 요청은 다음의 정보를 포함할 것이다:
-상기 요청을 보내는 컴퓨터의 IP 어드레스 그리고
·다이얼 호출된 컴퓨터의 VNET 번호
1106에서는, 상기 디렉토리 서비스가 상기 메시지를 받을 때, VNET 번호(또는 다른 ID)를 사용하여 VNET 번호(또는 다른 ID)와 관련된 상기 사용자가 온-라인 되어 있는지를 결정하고 컴퓨터가 접속될 수 있는 로케이션의 IP 어드레스를 식별한다. 압축 알고리즘 또는 특별한 하드웨어 또는 소프트웨어 기능과 같은 (PC11 1052에) 접속되어 있는 상기 컴퓨터에 관하여 사용 가능한 어떠한 추가적 정보가 상기 디렉토리 서비스 1031에 의하여 또한 복구될 수 있다. 그리고 나서 상기 디렉토리 서비스 1031은 상기 컴퓨터가 온-라인 되어 있는 지와 같은 PC11 1052에 관한 상태 정보와 상기 컴퓨터가 사용 가능하다면 그것의 IP 어드레스와 PC11 1052의 기능에 관한 사용 가능한 어떠한 다른 정보와 함께 메시지를 PC12 1052에게 되돌려 보낸다. PC12 1051이 상기 응답을 받을 때, PC11 1052가 접속될 수 있는지를 결정한다. 상기 결정은 PC11 1052의 온-라인 상태와 PC11 1052의 기능에 관한 상기 추가적인 정보에 근거를 둘 것이다. PC12 1051이 PC11 1052가 접속될 수 없다는 것을 나타내는 상태 정보를 받는다면 상기 호출 흐름은 여기에서 정지되지만 그렇지 않다면 계속된다.
이어지는 단계 1107에서 1111까지는 정상 IP 텔레포니 호출 준비 및 해체(tear-down) 단계이다. 1107에서는, PC12 1051이 PC11 1052에 "링"메시지를 전달한다. 상기 메시지는 단계 1031에서 상기 디렉토리 서비스 1031로부터 받은 상기 IP 어드레스로 보내어진다. 상기 메시지는 PC12 1051 사용자를 식별하는 정보를 포함할 수 있거나 요청된 접속에 관련된 파라미터를 상술하는 정보를 포함할 수 있다.
1108에서는, PC11 1052가 단계 1107로부터의 상기 메시지를 받고, 상기 메시지의 수령은 PC11 1052 사용자가 인입 호출에 대하여 통보 받았음을 나타내는 메시지를 PC12 1051로 다시 보냄으로써 통지된다. 상기 통보는 PC11 1052의 소프트웨어 패키지와 구성에 따라 보거나 들을 수 있다.
1109에서는, PC11 1052 사용자가 상기 호출을 받아들이면, 상기 호출에 대한 응답을 확인하는 메시지를 PC12 1051에 보낸다. PC11 1052 사용자가 상기 호출에 응답을 하지 않거나 거절하기를 택한다면, 에러 상태를 나타내는 메시지가 PC12 1051로 보내어진다. 상기 호출에 대하여 응답이 없으면, 상기 호출 흐름은 여기에서 정지되나, 그렇지 않으면 계속된다.
1110에서는, PC12 1051과 PC 11 1052의 사용자가 그들의 텔레포니 소프트웨어를 사용하여 대화할 수 있다. 대화는 1111에서 양 PC 사용자가 상대방 호출 참가자에게 단절 메시지를 보냄으로써 접속을 끊을 때까지 진전된다. 상기 메시지의 포맷과 내용은 PC12 1051과 PC11 1052가 사용한 텔레포니 소프트웨어 패키지에 달려 있다. 상기 시나리오에서는 PC11 1052가 PC12 1051에게 단절 메시지를 보내고 양 컴퓨터의 상기 텔레포니 소프트웨어 시스템이 음성 전송을 중지한다.
도 12는 바람직한 실시 예에 따른 네트워크외 PC에 대한 VNET PC 정보 호출 흐름을 보여주는 도면이다. 상기 흐름에서, 상기 인터넷 텔레포니 게이트웨이는 네트워크외(out-of-network) 요소이다. 이는 상기 인터넷 텔레포니 게이트웨이가 스위치와 통신하기 위한 SS7 시그널링을 사용할 수 없고 다이얼 호출된 상기 VNET 번호를 단순히 펄스로 내보내야 한다는 것을 의미한다. 대체 실시 예는 디렉토리 서비스가 VNET 번호를 직접 스위치/트렁크로 번역하는 것과 적절한 숫자를 펄스로 내보내는 것을 용이하게 한다. 상기 프로세스는 스위칭 네트워크에서의 번역을 용이하게 하지만 상기 인터넷 게이트웨이와 상기 스위치사이에 좀 더 복잡한 시그널링 인터페이스를 요구할 수 있다. 상기 타입의 네트워크내(in-network) 인터넷 게이트웨이 시나리오는 또 다른 호출 흐름에서 다루어 질 것이다.
상기 시나리오는 상기 인터넷과 고객 구내 교환기(PBX) 사이에 어떠한 통합화(integration)도 없었다는 것을 상정한 것이다. 통합화가 있었다면, 상기 PC가 인터넷(또는 인트라넷)을 통하여 고객 PBS상에서 ITG에 접속하는 것이 가능할 수 도 있다. 도 12는 바람직한 실시 예에 따른 호출 흐름 다이어그램을 보여주는 도면이다. 프로세싱은 1201에서 시작되는데, 여기서는 상기 온-라인 메시지를 받은 상기 디렉토리 서비스의 로케이션이 상기 고객을 위한 상기 데이터 분산 실행에 의하여 결정될 것이다. 어떠한 경우에서는 이것은 VNET 서비스에 가입한 회사 또는 조직을 위한 사적 데이터베이스일 수 도 있고 다른 경우에서는 서비스 프로바이더(MCI)를 위한 국제적 또는 전세계적 데이터베이스일 수 도 있다.
상기 디렉토리 서비스가 PC12 1051로부터 상기 메시지를 받을 때, 상기 디렉토리 서비스는 상기 사용자가 온-라인 되어 있고 특정 IP 어드레스에 위치하는 것을 나타내는 고유 ID와 관련된 프로파일 엔트리를 갱신할 것이다. 그리고 나서, 1202에서는, ID와 관련된 상기 프로파일의 성공적인 갱신이 있은 후, 상기 디렉토리 서비스가 상기 메시지를 받았고 처리되었음을 나타내는 응답(ACK)을 특정 IP 어드레스에게 보낸다. 상기 컴퓨터(PC12)가 상기 응답 메시지를 받을 때 가시 또는 가청 인디케이터를 통하여 상기 사용자에게 통보하는 것을 택할 수 있다.
1203에서는, 그리고 나서 네트워크외 인터넷 게이트웨이 폰으로의 다이얼 호출 경로에 대한 번역을 결정하기 위하여 VNET 번역 요청을 상기 디렉토리 서비스로 보낸다. 상기 IP 어드레스와 DNIS를 포함하는 응답을 1204에서 돌려보낸다. 상기 응답은 상기 호출을 경로 지정하기 위하여 상기 폰 어드레스 정보를 완전히 분해한다. 그리고 나서, 1205에서는, 상기 DNIS 정보를 이용하는 IP 텔레포니 다이얼 호출이 일어난다. DNIS는 상기 호출의 경로 지정에서 사용하기 위하여 호출에 관한 명확한 정보인 다이얼 호출된 번호 정보 서비스에 관하여 언급하고 있다. 1206에서는 ACK가 IP 텔레포니로부터 되돌아가고, 1207에서는 IP 텔레포니 응답이 일어나고 호출 경로는 1208에서 설정된다.
1209a는 응답 상태로 가고 다이얼호출 톤 1209b를 보내는 VNET PC를 보여준다. 그리고 나서, 1211에서는 착신 전화로 상기 호출을 경로 지정하는 방법을 결정하기 위하여 상기 DNIS 정보의 상기 경로 지정 번역이 경로 지정 데이터베이스에 의하여 사용된다. 1212에서 번역 응답을 받고, 1213에서는 스위치 대 스위치 펄스를 내보낸다. 그리고 나서 1215에서는 링이 상기 착신 폰에 전송되고 상기 PC로의 링백이 일어난다. 1216에서 상기 호출은 상기 인터넷 게이트웨이 접속을 통하여 네트워크 밖으로 전송되고 응답된다. 1217에서는 1218에서 참가자 중 한 명이 행 업 될 때까지 대화가 계속된다.
도 13은 바람직한 실시 예에 따른 네트워크외 폰에 대한 VNET PC 폰 정보 호출 흐름을 보여주는 도면이다. 상기 호출 흐름에서는 상기 PC로부터 상기 인터넷/인트라넷으로의 상기 호출을 PBX로 직접 접속된 인터넷 게이트웨이로 경로를 지정함으로써 상기 PSTN 사용을 방지한다.
도 14는 바람직한 실시 예에 따른 네트워크내 폰에 대한 VNET PC 폰 정보 호출 흐름으로 보여주는 도면이다. 상기 호출 흐름에서 상기 인터넷 텔레포니 게이트웨이는 네트워크내 요소이다. 이것은 상기 인터넷 게이트웨이가 상기 호출을 스위치로 핸드 오프(hand off)하기 위하여 SS7 시그널링을 이용할 수 있고 스위치인 것처럼 작용할 수 있을 것을 요구한다. 이것은 상기 디렉토리 서비스가 상기 스위치/트렁크를 되돌리는 것과 첫 번째 VNET 룩업 상에 디지트를 펄스로 내보내는 것을 허용한다. 이 단계는 상기 스위치에 의하여 추가적인 룩업을 방지한다. 상기 경우에서 상기 디렉토리 서비스는 VNET 경로 지정 정보로의 액세스를 가져야 한다.
a) PC to PC
도 15는 바람직한 실시 예에 따른 PC to PC 인터넷 텔레포니 호출을 보여주는 도면이다. 단계 1501에서는 네트 폰 사용자가 IP 접속에 의하여 상기 인터넷을 통하여 단계 1502 MCI 디렉토리 서비스에 접속되는데, 여기에서는 상기 호출의 경로 지정 방법을 결정하기 위하여 룩업이 실행된다. 단계 1503에서는 상기 호출을 보내는 장소를 결정하기 위하여 인텔리전트 시스템 플랫폼(ISP)에서 종료된다. IP 루터는 인텔리전트 서비시스 네트워크(ISN)에 의하여 상기 네트워크를 통한 상기 호출을 받은 방법을 결정하기 위하여 상기 MCI ISP 기능 엔진(feature engine)으로 가는 게이트웨이이다. 단계 1504에서는 상기 호출이 상기 인터넷을 통하여 상기 넷 폰 사용자에 접속된다. 대체 시나리오의 단계 1504에서는, 호출 참가자들이 MCI 오퍼레이터와 말하기를 원하고 상기 IP 루터는 네트-스위치(인터페이스)를 통하여 (음성 세상으로) 가기 때문에, 상기 전화에서의 사람은 불필요하다. 단계 1505에서는 네트 스위치가 호출 처리 엔진에게 DSP 엔진 기능을 행하는지를 문의한다. 단계 1506에서는 상기 호출이 WAN 허브를 통하여 MCI 스위치로 MCI 오퍼레이터로 또는 단계 1507에서는 음성메일로 경로 지정된다.
b) PC to 폰
도 16은 PC로부터 인터넷을 통하여 전화로 경로 지정되는 전화를 나타낸 도면이다. 단계 1602에서는, 상기 호출의 경로 지정에 대한 ISN 정보를 얻기 위하여 MCI 디렉토리에 문의한다. 그리고 나서 상기 호출은 단계 1603에서 ISP 게이트웨이로 다시 향해지고 단계 1604와 1605에서 상기 IP 루터를 이용하며 호출 처리 엔진으로 경로 지정된다. 그리고 나서 단계 1606에서 상기 호출은 상기 WAN으로 경로 지정되고 마지막으로 상기 호출에 대하여 본체 요금부과가 기록되는 RBOC로 경로 지정된다.
c) 폰 to PC
도 17은 바람직한 실시 예에 따른 폰 to PC를 나타내는 도면이다. 단계 1701에서는 전화가 특별한 네트 스위치로 경로 지정되는데, 여기에서는 단계 1702에서 호출 처리 엔진이 일련의 디지털 시그널 처리기를 이용하여 DTMF 톤을 결정한다. 그리고 나서 단계 1703에서 상기 시스템은 디렉토리 정보를 찾고 상기 호출을 접속한다. 상기 호출자가 그곳에 없거나 통화 중이라면, 그 때 단계 1704에서 상기 호출이 단계 1705에서의 호출 처리 엔진 이용을 하여 IP 루터를 통하여 스위치 너머로 경로 지정된다.
d) 폰 to 폰
도 18은 바람직한 실시 예에 따른 인터넷상에서의 폰에 대한 폰 호출을 나타내는 도면이다. 호출은 단계 1801에서 스위치로 오고, 단계 1802에서 호출 처리 엔진에서 실행되는 호출 논리 프로그램에 의하여 처리된다. 단계 1803에서는 상술한 호출 경로 지정을 결정하기 위하여 룩업이 디렉토리 정보 데이터베이스에서 실행된다. 경로 지정은 본체 요금부과 업무 1808에 요금 부과 기록을 저장하는 것을 포함한다. 모든 ISN 기능은 비록 상기 호출이 인터넷을 통하여 경로 지정된다 하더라도 상기 호출에게 이용될 수 있다. 상기 호출 경과가 인터넷 1804를 통하고 네트워크 스위치 쪽으로 지정되게 하는 것을 용이하게 하기 위하여 IP 루터는 각 인터넷 끝에서 사용된다. 상기 네트워크 스위치로부터 상기 호출은 호출 처리 엔진으로, 그리고 WAN 허브 1806을 통하고 RBOC 1807을 통하여 목표 전화로 경로 지정된다. 디지털 트랜스코딩과 DTMF 검출과 음성 인식과 호출 처리와 VRU 기능과 모뎀 기능을 실행하기 위하여 다양한 DSP 엔진 1803이 이용된다.
XI. 원격 통신 네트워크 관리(TELECOMMUNICATION NETWORK MANAGEMENT)
바람직한 실시 예는 네트워크 이벤트를 분석하고, 상관시키고 또한 제공하기 위하여 원격 통신 네트워크용 네트워크 관리 시스템을 이용한다. 현대의 원격 통신네트워크는 호툴 설정, 처리 및 취소에 요구되는 시그널링 데이터를 반송하기 위하여 콜-베어링(call-bearing) 네트워크들과 성질이 다른 데이터 시그널링 네트워크를 이용하는데, 상기 시그널링 네트워크는 총괄하여 공통 채널 신호 시스템(Common Channel Signaling System) #7, 즉 약하여 신호 시스템 #7로 언급되는 상업-표준 구조 및 프로토콜을 사용한다. SS7은 기존의 시그널링 방식에 비하여 상당한 진전을 본 것인데, 여기에서는 호출 시그널링 데이터가 호출로서 동일한 회선을 통하여 전송된다. SS7 호출 시그널링 데이터를 전송하기 위하여 회선의 독특한 전용 네트워크를 제공한다. SS7을 이용함으로써 호출 설정 시간(post-dial delay로서 호출자에 감지됨)을 감소시켰고 콜-베어링 네트워크에 능력을 증가시켰다. SS7 시그널링의 상세한 기술은 Signaling System #7, Travis Rusell, Mcgraw Hill (1995)에서 제공된다.
SS7 네트워크의 표준은 국내(미국) 네트워크를 위하여는 ANSI에 의하여 국제 접속을 위하여는 ITU에 의하여 설정되어 있으며, 각각 ANSI SS7과 ITU C7로 언급된다. 전형적인 SS7 네트워크는 도 1B에 도시되어 있다. 콜-베어링 원격 통신 네트워크는 고객 호출량을 스위치하기 위하여 매트릭스 스위치 102a/102b를 사용한다. 상기 스위치 102a/102b는 Northern Telecom에 의하여 제조된 DMS-250 또는 Digital Switch Corporation에 의하여 제조된 DEX-600과 같이 규격화되어 있다. 상기 스위치 102a/102b는 음성-등급(voice-grade)과 데이터-등급(data-grade) 콜-베어링 트렁크(trunks)와 상호 접속되어 있다. 상기 접속은 도 1B에는 도시되어 있지 않지만 많은 종류의 구성을 취 할 수 있다.
원격 통신 네트워크에서의 스위치는 다중 기능을 실행한다. 음성 호출을 위한 회선의 스위칭에 더하여 스위치는 호출 제어의 일부로서 시그널링 메시지를 다른 스위치에 중계해야 한다. 상기 시그널링 메시지는 컴퓨터의 네트워크를 통하여 전달되는데, 그 각각은 시그널링 포인트(SP) 102a/102b로 명명된다. SS7 네트워크에는 세 가지 종류의 SP가 있다:
-서비스 스위칭 포인트(SSP)
-신호 중계점(STP)
-서비스 제어점(SCP)
상기 SSP는 SS7 시그널링 네트워크로의 스위치 인터페이스이다.
신호 중계점(STP) 104a...104f(집합적으로 104로 언급된다)는 SS7 신호의 스위치와 경로 지정에 사용되는 패킷-스위칭 통신 디바이스(packet-switching communications device)이다. 상기 신호 중계점은 여유도(redundancy)와 복원(restoration)을 위하여 클러스터(cluster)로 알려진 쌍으로 배치된다. 예를 들면, 도 1B 에서는 STP 104a가 지역 클러스터(Regional Cluster) 1에서 STP 104b와 짝을 이루고 있고, STP 104c가 Regional Cluster 2에서 STP 104d와 짝을 이루고 있으며, STP 104e는 지역 클러스터 3에서 STP 104f와 짝을 이루고 있다. 전형적인 SS7 네트워크는 복수의 STP 클러스터 104를 포함하고 있다; 도 1에서는 도시 목적으로 세 개가 나타나 있다. 각 STP 클러스터 104는 SSP 102의 특정 지리적 지역에 대하여 서비스한다. 복수의 SSP 102는 클러스터 내에서 두 개의 STP 104 각각과의 주 SS7 링크를 가진다. 이것은 1차 시외 대역제(homing arrangement)로서 서비스한다. 도 1B에서는 도시의 목적으로 오직 두 개의 SSP 102가 국부 클러스터로 홈(home)하도록 나타나 있다: 실제로는 여러 개의 SSP 102가 특정 STP 클러스터 104로 홈할 것이다. SSP 102는 또한 일반적으로 다른 클러스터 내에 한 개 또는 두 개의 STP와의 2차 SS7 link를 가질 것이다. 이것은 2차 시외 대역제로서 서비스한다.
다양한 요소들을 접속하는 상기 SS7 link는 다음과 같이 식별된다:
A link는 SSP를 1차 STP 각각에 접속한다.
B 링크는 하나의 클러스터에서의 STP를 다른 클러스터에서의 STP와 접속한다.
C 링크는 하나의 STP를 동일한 클러스터에 있는 다른 STP에 접속한다.
D 링크는 다른 carrier 네트워크들 사이에 STP를 접속한다(미 도시).
E 링크는 SSP를 동일한 클러스터에 있지 않은 STP에 접속한다(2차 homing).
F 링크는 두 개의 SSP를 상호 접속한다.
Interchange Carrier(IXC) 네트워크와 Local Exchange Carrier(LEC) 네트워크와 같이 두 개의 다른 캐리어의 네트워크를 접속하기 위하여 각 캐리어의 네트워크로부터의 STP 클러스터 104는 D 링크들 또는 A 링크들에 의하여 접속 될 수도 있다. SS7은 LEC와 IXC 사이에서 pass되는 호출에 대한 시그널링을 또한 전송할 수 있도록 상기 인터페이스에 표준화된 프로토콜을 제공한다.
스위치가 고객 호출을 받고 경로 지정할 때, 그 호출에 대한 시그럴링은 접속된 SSP 102에 의하여 수용(또는 발생)된다. 스위치들을 접속하는 인터머신(intermachine) 트렁크들이 고객의 호출을 가지고 갈 때 그 호출에 대한 시그널링은 STP4로 보내어 진다. 상기 STP4는 상기 신호를 호출 종료 스위치의 SSP 102 어느 하나에게로 경로 지정을 하거나 또는 다른 STP 104로 경로 지정을 하는데, 그리고 나서 상기 다른 STP 104는 상기 신호를 호출 종료 스위치의 SSP 102로 경로 지정한다. SS7 네트워크의 또 다른 요소는 도 2에서 나타난 바와 같은 Protocol Monitoring Units(PMU) 106이다. PMU 106은 스위치 사이트에 배치되어 있고 SS7 네트워크에 독립적인 모니터링 도구를 제공한다. INET Inc. of Richardson, TX에 의하여 제조된 디바이스와 같은 상기 디바이스들은 도 2에 나타난 바와 같이 SS7 네트워크의 A와 E와 F 링크를 모니터 한다. 그것들은 SS7 링크에 대한 오류와 성능 정보를 발생시킨다.
어떠한 원격통신 네트워크와 마찬가지로 SS7 네트워크는 파이버 절단과 다른 난폭한 전송과 디바이스 오류에 치명적이다. SS7 네트워크는 고객 통화량을 전송하는데 요구되는 모든 시그널링을 가지고 가기 때문에 어떠한 난제도 신속히 제거되고 정정되어야 하는 것이 필수적이다. 그러므로 시스템은 필수적으로 SS7 네트워크를 모니터하고 오류와 성능을 분석하고 정정 조치를 관리할 수 있어야 한다.
SS7 네트워크 관리 시스템의 선행 기술은 비록 상기의 기본적인 기능은 수행하지만 여러 가지 단점을 가지고 있다. 네트워크 위상의 수동 구성 배치에 많은 것이 요구되는데, 이는 인간의 오류와 위상 갱신의 지연에 치명적이다. 상기 시스템들의 구성 배치는 일반적으로 상기 시스템이 be down for a period of time되는 것을 요구한다. 산업에서 이용될 수 있는 많은 시스템들은 특정의 vendor의 PMU 106을 의도하고 있고 실제로 위상 데이터를 그들의 PMU 106으로부터 얻고 있고 따라서 PMU 106과 다른 vendor의 장비에 접속되지 않은 네트워크 요소는 무시한다.
선행 기술 시스템은 오직 독점 PMU 106으로부터 받은 데이터와만 작동하기 때문에 그들은 PMU 이벤트와 다른 타입의 SS7 네트워크 요소로부터 발생된 이벤트 사이에 상관관계를 제공하지 않는다. 그들은 또한 이벤트 상관관계에 대하여 경직되고 독점적인 분석만을 제공하고 있다.
강화된 SS7 네트워크 관리 기능에 관한 방식과 시스템은 다양한 SS7 네트워크 요소들에 의하여 발생된 이벤트를 받고 처리할 수 있는 분산 클라이언트/서버 플랫포옴에 의하여 제공된다. 각 네트워크 이벤트는 어떠한 타입의 요소에 의하여 발생된 이벤트를 처리하는 것을 허용하기 위하여 분석되고 표준화된다. 이벤트들은 또한 네트워크 위상 데이터베이스와 전송 네트워크 관리 시스템과 네트워크 유지 스케줄과 시스템 사용자들에 의하여 수취될 수 있다. 도 3과 관련하여, SS7 네트워크 관리 시스템(SNMS)으로 언급되는 본 발명의 바람직한 실시 예의 시스템 구조가 도시되어 있다. SNMS는 네 개의 논리 서버 302/304/306/308과 네트워크 관리 광역 네트워크를 통하여 접속되는 다수의 클라이언트 워크스테이션 312a/312b/312c로 구성된다. 네 개의 논리 SNMS 서버 302/304/306/308 모두는 단일 또는 다수의 물리적 유닛에 존재할 수도 있다. 바람직한 실시 예에서는 기능을 고양하기 위하여 각 논리 서버가 별개의 physical 유닛에 존재한다. 상기 physical 유닛들은 AIX 오퍼레이팅 시스템과 함께 실행되는 IBM RS6000 유닛과 같이 어떠한 종래 형식의 것일 수도 있다.
상기 클라이언트 워크스테이션 312는 마이크로 윈도우스 또는 IBM OS/2오퍼레이팅 시스템과 함께 실행되는 종래의 PC이거나 dumb terminal이거나 VAX VMS 워크스테이션일 수도 있다. 실제에 있어서는 클라이언트 워크스테이션은 인터넷 프로토콜(IP)을 가지고 X-윈도우스와 함께 실행되고 WAN 310으로 접속되는 어떠한 터미널 또는 PC일 수도 있다. 어떠한 SNMS-specific 소프트웨어도 클라이언트 워크스테이션 312상에서 실행되지 않는다.
SNMS는 다양한 SS7 네트워크요소와 다른 네트워크 관리 시스템(NMS) 338로부터 이벤트를 받는다. 그것은 또한 네트워크 위상과 구성배치와 유지 데이터를 외부 시스템으로부터 받는데 이는 후술한다. 이벤트를 발생시키는 다양한 네트워크 요소는 네트워크 제어기 314와 국제 및 국내 SP 316/102와 STP 104와 PMU 106을 포함한다. 네트워크 제어기 314는 외부 명령에 근거하여 회선을 스위치 하는 디바이스들이다. 그것들은 SSP 102와 동일한 방식으로 SS7 시그널링을 이용하나, 어떠한 STP 104에도 접속되지 않는다. 국제 SP 316은 국내 및 국제 원격통신 네트워크사이에서 게이트웨이로서 서비스한다. 상기 STP 104는 국내적 또는 국제적일 수도 있다.
상기 PMU 106은 SS7 회선을 가로지르는 SS7 패킷을 스캔하고 오류 상태를 분석하고 그 당시에 SNMS 상으로 지나가는 네트워크 이벤트를 발생시킨다. 상기 PMU 106은 또한 모니터 된 SS7 회선의 기능에 관한 주기적인 통계를 발생시킨다.
모든 SP 102/316과 STP 104와 PMU 106과 SS7 네트워크 제어기 314는 네트워크 이벤트를 통신 네트워크를 통하여 SNMS로 전송한다. 이것은 SNMS가 각 디바이스와의 세션을 유지하여야 하는 요구조건을 제거한다. 하나의 전형적인 실시 예에서는 도 3에서 나타난 바와 같이 비동기 데이터 통신 네트워크 320이 네트워크 제어기 314와 국제 SP 316으로부터 이벤트를 전송하기 위하여 사용된다. IBM의 3708과 같은 IBM 본체 Front End Processor(FEP) 324는 비동기 프로토콜이 IBM mainframe-based switched Host Interface Facilities Transport(SWIFT)에 의하여 수취될 수 있도록 비동기 프로토콜을 SNA로 전환하는데 사용된다. SWIFT 326은 각 네트워크 요소와의 논리 통신 세션을 유지하는 통신 인터페이스 및 데이터 분산 어플리케이션이다.
상기의 동일한 실시 예에 있어서, X.25 오퍼레이팅 시스템스 지원(OSS) 네트워크 328은 이벤트들을 STP 104와 SP 102와 PMU 106으로부터 전송하기 위하여 사용된다. Local Support Element(LSE) 시스템 330은 상기 이벤트들을 받는다. VAX/VMS 시스템 일 수도 있는 상기 LES 330은 본질적으로 이벤트 데이터들을 상기 X.25 OSS 네트워크 328로부터 SNMS 서버 302/304로 변환하기 위하여 사용되는 패킷 어셈블러(Assembler)/디셈블러(Disassembler)(PAD)와 프로토콜 변환기이다. 그것은 또한 각 네트워크 요소와의 통신 세션을 유지하고 따라서 SNMS가 그와 같이 하여야 하는 요구를 제거하는데 있어 SWIFT 326과 같은 기능을 서비스한다. SWIFT 326과 LSE 330에 대한 필요는 전형적인 원격 통신 네트워크의 일 실시 예를 나타내고 있는데, 상기 원격 통신 네트워크에는 다른 타입의 요소들이 다른 전송 기구를 요구하는 위치에 존재한다. SNMS는 상기의 모든 타입의 요소를 보조한다.
모든 네트워크 이벤트는 분석과 상관 관계를 위하여 SNMS 경보 서버 302에 입력된다. 어떤 이벤트도 또한 활동 기록 목적으로 저장되기 위하여 SNMS Reporting 서버 304에 입력된다. VAX/VMS 시스템일 수도 있는 제어 시스템 332는 상기 X.25 OSS 네트워크 328을 통하여 각 네트워크 요소로부터 위상과 구성 배치 데이터를 모으기 위하여 사용된다. STP 104와 SP 102와 같은 어떠한 요소는 상기 데이터를 상기 X.25 OSS 네트워크 328을 통하여 직접 보낼 수도 있다. 오직 비동기 모드에서 통신하는 국제 SSP 316과 같은 요소는 X.25 OSS 네트워크 328에 접속되기 위하여 패킷 어셈블러(Assembler)/디셈블러(Disassembler)(PAD) 318을 사용한다. 그리고 나서 상기 제어 시스템 322는 상기 위상 및 구성배치 데이터를 SNMS 위상 서버 306으로 공급한다.
네트워크 위상 정보는 경보 상관 관계를 실행하고 화상 디스플레이를 제공하기 위하여 SNMS에 의하여 사용된다. 대부분의 위상 정보는 네트워크 위상 데이터베이스 334로부터 수신되는데, 바람직한 실시 예에서는 상기 정보가 오더 엔트리 시스템과 네트워크 엔지니어링 시스템에 의하여 생성되고 유지된다. 위상 데이터는 상기 네트워크 위상 데이터베이스 334 및 상기 제어 시스템 332로부터 상기 SNMS 위상 서버 306으로 입력된다. PC 336의 사용을 통하여 수동 오버라이드를 입력하는 능력은 또한 상기 SNMS 위상 서버 306에 의하여 제공된다.
상기 SNMS 경보 서버 302는 또한 이벤트 특히 DS-3 전송 경보를 다른 네트워크 관리 시스템(NMS) 338로부터 수신한다. 위상 데이터를 사용하여 SNMS는 상기 이벤트를 SS7 네트워크 요소로부터 수신된 이벤트와 상호 관련시킬 것이다. 상기 SNMS 경보 서버 302는 또한 네트워크 유지관리 스케쥴 시스템 340으로부터 네트워크 스케쥴 정보를 수신한다. SNMS는 유지에 기인하는 계획된 네트워크 정지를 설명하기 위하여 상기 정보를 사용하고 따라서 유지-발생 경보에 응답할 필요가 제거된다. 또한 SNMS는 계획된 유지 활동에 영향을 미칠 수 있는 네트워크 정지에 대하여 유지원에게 사전 경고하기 위하여 상기 정보를 사용한다.
상기 SNMS 경보 서버 302는 장애 관리 시스템 342와의 인터페이스를 가지고 있다. 상기 인터페이스는 클라이언트 위크스테이션 312의 SNMS 사용자가 SNMS-발생 경보에 대하여 장애 티켓을 제출하는 것을 허용한다. SNMS-내부 장애 관리 시스템 사용을 반대하는 상기 인터페이스는 다수의 다른 타입의 장애 관리 시스템을 이용하도록 구성 배치될 수 있다. 바람직한 실시 예에 따르면 SNMS 화상 서버 308이 단일 사이트에 있는 모든 클라이언트 워크스테이션을 지원하고 따라서 상기 SNMS 화상 서버 308은 다수의 서버이다. SNMS 화상 서버 308의 지리적 분산은 중아 로케이션으로부터 각 워크스테이션으로 화상 프리젠테이션을 지원하는 대량의 데이터를 전송할 필요성을 제거한다. 경보 서버 302와 리포팅 서버 304와 위상 서버 306으로부터의 데이터만이 워크스테이션 사이트로 전송되고, 따라서 네트워크 전송 대역폭을 저장하고 SNMS 기능을 향상시킨다. 대체 실시 예에 따르면 상기 화상 서버 308은 중심으로 위치할 수 있다.
도 4에 따르면 고-레벨 프로세스 플로우차트가 SNMS 논리 시스템 성분을 나타내고 있다. 프로세스의 중심에는 프로세스 이벤트 402가 잇다. 상기 성분은 SNMS 프로세스에 대한 통화량 캅(cop)으로서 서비스한다. 프로세스 이벤트 402는 주로 SNMS 경보 서버 302 상에서 실행되는데, 상기 프로세스 이벤트 402는 다른 SNMS 성분으로부터 이벤트를 수신하고 처리하고 저장하고 보고 및 디스플레이 성분에 처리된 이벤트 데이터를 공급할 책임을 진다. 상기 프로세스 이벤트 프로세스 402는 도 5에서 좀 더 상세히 나타나 있다.
주로 상기 경보 서버 상에서 실행되는 상기 수신 네트워크 이벤트 성분 404는 SWIFT 326과 LSE 330과 같은 시스템을 통하여 다양한 SS7 네트워크 요소(STP 104, SP 102, PMU 106 등)로부터 네트워크 이벤트를 수신한다. 상기 성분은 상기 이벤트를 분석하고 해석을 위하여 프로세스 이벤트 402로 송신한다. 상기 수신 네트워크 이벤트 프로세스 404는 도 6에서 좀 더 자세히 나타나 있다.
주로 위상 서버 306 상에서 실행되는 프로세스 위상 성분 406은 네트워크 위상 데이터베이스로부터 제어 시스템 332를 통하여 SS7 네트워크 요소로부터 그리고 수동 오버라이드 336으로부터 네트워크 위상 및 구성배치 데이터를 받는다. 상기 데이터는 네트워크 이벤트를 상호 관련시키고 상기 이벤트에 impact assessment를 실행시키기 위하여 사용된다. 상기 데이터는 또한 이벤트의 화상 프리젠테이션을 제공하기 위하여 사용된다. 프로세스 위상 406은 상기 위상 및 구성배치 데이터를 분석하고 저장하며 해석을 위하여 프로세스 이벤트 402에 송신한다. 상기 프로세스 위상 프로세스 406은 도 7에 좀 더 자세히 나타나 있다.
주로 경보 서버 302 상에서 실행되는 규정 알고리즘 구성요소 408은 SNMS에 의하여 사용되는 특정의 분석 및 해석법을 규정한다. 그리고 나서 상기 규정은 분석 및 해석에 사용되기 위하여 프로세스 이벤트 402로 로드된다. 상기 알고리즘은 소프트웨어 모듈에 저장되고 프로그램된 코드에 의하여 정의된다. 프로그래머는 단순히 상기 기 정의된 알고리즘을 상기 소프트웨어 모듈에 프로그램 하는데, 그리고 나서 상기 알고리즘은 프로세스 이벤트 402에 의하여 사용된다. 상기 알고리즘은 사실상 절차적인 것이고 네트워크 위상에 근거를 두고 있다. 상기 알고리즘은 전용어로 쓰여지고 SNMS 사용자에 의하여 동적으로 변환될 수 있다는 단순한 규정과 SNMS 소프트웨어 코드 범위 내에서 프로그램 된다는 다소 복잡한 규정으로 이루어져 있다.
주로 경보 서버 302 상에서 실행되는 상기 수신 NMS 데이터 구성 요소 410은 다른 네트워크 관리 시스템(NMS) 338로부터 이벤트를 수신한다. 상기 이벤트는 DS-3 전송 경보를 포함한다. 또한 상기 수신 NMS 데이터 구성 요소 410은 네트워크 유지 스케쥴 시스템 340으로부터 네트워크 유지 이벤트를 수신한다. 그리고 나서 상기 수신 NMS 데이터 구성 요소 410은 상기 이벤트를 분석하고 분석을 위하여 프로세스 이벤트 402로 송신한다. 주로 화상 서버 308 및 경보 서버 302 상에서 실행되는 디스플레이 경보 구성요소 412는 화상 사용자 인터페이스(GUI)를 포함하고 프로세스 이벤트 402에 의하여 제공된 데이터를 사용하며 위상 및 경보 프레젠테이션을 지원하는 관련된 소프트웨어를 포함한다. 또한 그 것은 경보 취소와 같은 사용자 상호 작용과 수신 통보와 장애 티켓 제출을 지원한다. 그 것은 상기 상호작용의 저장 및 요구되는 데이터 갱신을 위하여 프로세스 이벤트 402에 입력한다. 상기 디스플레이 경보 프로세스 412는 도 8에서 보다 자세히 나타나 있다.
주로 리포팅 서버 304 상에서 실행되는 데이터 보고 구성요소 414는 프로세스 이벤트 402에 의하여 공급되는 데이터를 사용하여 위상 및 경보 보고 기능을 지원한다. 데이터 보고 프로세스 414는 도 9에 보다 자세히 나타나 있다.
도 5에는 상세한 프로세스 이벤트 구성요소 402의 프로세스가 나타나 있다. 상기 프로세스는 SNMS의 주 프로세스이다. 상기 프로세스 이벤트 구성요소 402는 다른 SNMS 구성요소로부터 범용 이벤트를 수신하고 관련 데이터를 추출하기 위하여 각 이벤트를 분석하고 상기 타입의 이벤트를 식별한다. 상기 이벤트가 SS7-관련 이벤트라면 프로세스 이벤트 402는 경보를 발생하거나 현 경보를 상호 관련시키는 것과 같이 선택된 알고리즘을 적용한다.
첫 번째 3 단계 502-506은 각 SNMS 세션의 시작에 실행되는 초기화 프로세스이다. 상기 단계 502-506은 상기 시스템이 실행될 수 있는 상태를 설정한다. 그리고 나서 510-542는 연속적인 루프로서 실행된다. 단계 502에서는 현재 위상 데이터가 위상 서버 306 상에서 위상 데이터 기억 장치로부터 읽혀진다. 상기 위상 데이터 기억 장치는 도 4에서 나타난 바와 같이 프로세스 위상 프로세스 406에서 만들어지고 프로세스 이벤트 402로 입력된다. 읽혀진 위상 데이터는 프로세스 위상 406에서 분석되어 지고 따라서 단계 502에서 프로세스 이벤트 402에 의하여 처리가 용이한 표준화된 이벤트로서 읽혀진다.
단계 504에서는, 규정 알고리즘 구성요소 408에서 생성된 알고리즘이 읽혀진다. 상기 알고리즘은 각 경보에 SNMS가 어떠한 조치를 취하는지를 결정한다. SNMS는 상기 타입의 경보에 대한 불러내어지는 상기 알고리즘의 맵을 가진다.
단계 506에서는 데이터 보고 프로세스 414에서 생성되는 오류관리(FM)보고 데이터베이스로부터의 경보 기록이 읽혀진다. 모든 이전의 경보는 폐기된다. (단계 502에서 읽혀진) 상기 위상에 존재하지 않는 회선 또는 노드에 대하여 작동되는 어떠한 경보도 폐기된다. 또한 (단계 504에서 읽혀지는) 어떠한 현 알고리즘으로 맵하지 않는 어떠한 경보도 폐기된다. 상기 경보는 오직 초기화에서만 읽혀진다. 시스템 기능의 향상을 위하여 추가적인 경보 기록이 상기 프로세스 이벤트 402 구성요소 내부의 데이터베이스로부터 검색된다. 단계 506은 초기화 프로세스를 포함한다; 일단 현재의 위상, 알고리즘 및 경보가 읽혀지면 SNMS는 이벤트 판독, 처리, 저장이 계속되는 프로세스를 시작할 수 있다.
상기 프로세스는 단계 510과 함께 시작되는데, 상기 프로세스에서는 대기중의 다음 이벤트를 수신하고 식별한다. 상기 대기 열은 상기 프로세스 이벤트 구성요소 402에게 네트워크 이벤트와 위상 이벤트와 NMS 이벤트를 제공하는 First In/First Out(FIFO) 대기 열이다. 다시 말하자면, 단계 502에서 읽혀지는 상기 경보 데이터는 시스템 상태를 시작 시에 읽혀지는 초기화 데이터이다. 단계 510에서는 진행중 이벤트(Ongoing event)가 프로세스 구성요소 404, 406 및 410으로부터 게속적으로 읽혀진다. 상기 이벤트는 이미 분석되었고 표준화된 SNMS 이벤트로서 수신된다. 그리고 나서 SNMS는 수신되고 있는 상기 타입의 이벤트를 식별한다. 상기 이벤트가 어떠한 임계값보다 이전의 것 예컨대 1시간 정도 이전의 것으로 판명된다면 상기 이벤트는 폐기된다.
단계 512, 520, 524 및 534에서는 SNMS가 단계 510에서 생성된 이벤트 타입 식별에 근거한 상기 이벤트를 어떠한 방식으로 처리해야 하는지를 결정한다.
단계 512에서는 상기 이벤트가 위상 데이터로 결정된다면 SNMS는 단계 514에서 새로운 위상을 나타내기 위하여 GUI 디스플레이를 한다. 그리고 나서 단계 516에서 SNMS는 새로운 위상에 맵되지 않은 어떠한 경보도 폐기하기 위하여 작동중의 경보와의 일치를 실행한다. 단계 518에서는 상기 새로운 위상 데이터가 위상 데이터 기억 장치에 기록되는데, 상기 데이터는 SNMS 위상 서버 306에 저장된다.
단계 520에서는 상기 이벤트는 이 후의 SNMS 규정에 의한 참조를 위하여 SNMS 보고 서버 304 상에서 상기 FM 보고 데이터베이스에 저장된다.
단계 524에서 상기 이벤트가 규정된 SS7 네트워크 이벤트로 결정된다면 그때 단계 526에서 상기 이벤트를 위하여 하나 또는 그 이사의 알고리즘을 불러들일 것이다. 그러한 알고리즘은 네트워크 관리 시스템 338과 네트워크 유지 스케쥴 340과 네트워크 위상 334로부터 검색된 데이터를 사용할 수 있다.
예를 들면, 각 회선 레벨 알고리즘이 경보를 발생할 때 상기 알고리즘은 상기 네트워크 유지 스케쥴 340과 NMS 338 기록에 대한 검사를 실행한다. 특정 회선이 유지 윈도우 (네트워크 유지 스케쥴 340) 내에 존재하거나 전송 경보(NMS 338)를 가지는 DS-3 상에 이송된다면 각 경보 기록은 표지 처리된다. SS7 회선이 DS-0 레벨에서 실행될 때 TDRL 네트워크 위상 데이터베이스 334는 DS-0 변환 표에 DS-3을 제공한다. DS-3 내의 어떠한 DS-0 회선도 잠재적으로 전송 오류에 포함되는 것으로 표지 처리된다. NMS 338로부터의 취소 기록은 관련되는 NMS 338 관련이 제거될 수 있도록 작동상의 SNMS 회선 레벨 경보가 평가되도록 할 것이다. SNMS 취소 이벤트는 실제 SNMS 경보를 취소할 것이다. GUI 필터는 사용자가 유지 윈도우와 조화되고 전송 오류에 포함되는 경보를 마스크 아웃 하는 것을 허용하는데 이는 상기 경보가 SNMS 오퍼레이터작동을 요하지 않기 때문이다.
단계 528에서는 작동중의 경보가 단계 526으로부터 초래되는 새로운 경보 발생 및 취소와 조화된다. 단계 528에서는 상기 GUI 디스플레이가 갱신된다. 단계 532에서는 상기의 새로운 경보 데이터가 FM 보고 데이터베이스에 저장된다.
단계 534에서는 상기 이벤트가 timer로 결정될 수 있다. SNMS 알고리즘은 때때로 지속 및 비율 알고리즘과 같은 규정된 기간을 위한 특정 컨디션의 추가적인 처리를 지연시킬 필요가 있다. 지연 timer는 상기 상태를 위하여 설정되어 있고 새로운 SNMS 이벤트의 처리는 계속된다. 상기 시간이 경과 할 때 SNMS 상기 시간을 이벤트로 취급하고 적절한 알고리즘을 실행한다.
예를 들면 SS7 링크는 수 초 내에 재 기능할 수 있는 가능성을 순간적으로 막을 수 있거나 조치를 필요로 하는 심각한 정지에 기인하여 매우 큰 기간동안 고장날 수 있다. SNMS가 상기 이벤트를 수신할 때 상기 SNMS는 약 1분의 타이머를 상기 이벤트에 배치할 수 있다. 상기 이벤트가 1분내에 삭제된다면 SNMS는 상기 이벤트상에 어떠한 조치도 취하지 않는다. 그러나 1분 타이머가 경과 한 후에 상기 이벤트가 바뀌지 않는다면(SS7 링크가 여전히 고장 상태이다면) SNMS는 조치를 취할 것이다.
단계 536에서는 상기와 같은 조치를 취하기 위하여 적절한 알고리즘을 불러낸다. 단계 538에서는 active경보가 단계 536에서 발생 또는 삭제된 active경보와 조화된다. 단계 540에서는 상기 GUI 디스플레이는 갱신된다. 단계 542에서는 새로운 경보 데이터가 FM 보고 데이터베이스에 저장된다. 전술한바와 같이 SNMS는 이벤트를 수신하고 처리하는 것과 관련하여 연속 식으로 작동한다. 단계 518,522,532와 542에서의 데이터 저장 후 프로세스는 단계 510으로 되돌아간다.
도 6에서는 수취 네트워크 이벤트 구성 요소 404가의 상세한 프로세스가 나타나 있다. 상기 구성 요소는 Async Data 네트워크 320과 SWIFT 326과 X.25 OSS 네트워크 328과 LSE 330과 같은 데이터 이송 기구를 통하여 상기 SS7 네트워크 요소로부터 이벤트를 모은다. 상기 이벤트는 First In/First Out(FIFO) 대기 열에 상기 SNMS 경보 서버 302에 의하여 수신된다. 단계 602 및 604에서는 상기 SS7 네트워크 요소로부터의 이벤트가 SWIFT 326 및 LSE 330과 같은 SNMS 외부의 mainframe 어플리케이션s에 의하여 수집되고 이벤트 데이터의 프로토콜이 네트워크 요소-특정 프로토콜로부터 SNA 또는 TCP/IP로 변환된다. 일 실시 예에 따르면 SNMS는 상기 프로토콜을 SNMS RTUF보 서버 302가 인식할 수 있는 프로토콜로 변환하는 mainframe 상에서 실행되는 소프트웨어를 또한 가질 수 있다. 그리고 나서 상기 이벤트 데이터는 SNA 또는 TCP/IP를 통하여 SNMS 경보 서버 302로 전송된다. SNMS 처리될 수 있는 모든 SS7 이벤트 타입의 시그널링 이벤트 리스트 608을 보존한다. 단계 606에서 SNMS는 시그널링 이벤트 리스트 608을 검사하고 현 이벤트가 목록에서 발견되면 SNMS는 처리를 위한 상기 이벤트를 trap한다. 상기 이벤트가 상기 목록에서 발겨되지 않는다면 SNMS는 그것을 폐기한다.
단계 610에서는 상기 이벤트가 규정된 분석 규정에 따라 분석된다. 상기 분석 규정 614는 어떠한 항목이 어떠한 타입의 이벤트로부터 추출되어야 하는 지와 상기 SNMS 코드로 프로그램 되어야 하는지를 상술한다. 단계 610상의 이벤트 분석은 상기 경보 알고리즘 또는 디스플레이 내에 필요한 상기 이벤트 데이터 항목만을 추출한다. 또한 단계 610으로의 입력은 상기 네트워크 보수 스케쥴 340으로부터의 예정된 이벤트 612이다. 예정된 이벤트 612는 예정된 네트워크 보수일 수 있는 단계 602에서 수집된 각 네트워크 이벤트를 식별하기 위하여 사용된다. 이것은 SNMS 오퍼레이터가 계획된 보수에 기인하는 상기 네트워크 정지를 설명하는 것을 허용한다.
단계 616에서는 다른 SNMS 프로세스에 의하여 사용 될 목적으로 SNMS 상주 메모리에 표준화된 이벤트 objects를 생성하기 위하여 분석된 상기 이벤트 데이터가 사용된다. 상기의 이벤트 오브젝트는 단계 510에서 프로세스 이벤트 402인 주 프로세스로 읽혀진다.
도 7에는 상기 프로세스 위상 구성 요소 406의 상세한 프로세스가 나타나 있다. 상기 프로세스 구성 요소는 다른 SNMS 프로세스에 의하여 사용 될 목적으로 세 가지 타입의 신호원으로부터 네트워크 위상과 구성 배치 데이터를 검색하고 표준화된 위상 데이터 기록을 생성하고 상기 데이터를 저장한다. 특히 단계 502에서 상기 프로세스 구성 요소 406은 경보 서버 302상에서 실행되는 프로세스 이벤트 402로 액티브 위상 데이터를 공급한다.
단계 702에서는 상기 SNMS 위상 서버 306이 세 개의 다른 신호원으로부터 위상 데이터를 수집한다. 상기 SNMS 위상 서버 306은 제어 시스템 332를 통하여 SS7 네트워크 요소에 의하여 발생된 현재의 접속 및 구성 배치 데이터를 수집한다. 상기 SNMS 위상 서버 306은 오더 엔트리 및 엔지니어링 시스템으로 입력되는 위상 데이터를 수집하고 네트워크 위상 데이터베이스 334에 저장한다. 또한 상기 위상 서버 306은 워크스테이션을 통하여 수동 오버라이드 336을 받아들인다. 상기 위상 데이터베이스 334 및 제어 시스템 332로부터의 상기 데이터 모음은 주기를 바탕으로 발생하고 SNMS 경보 서버 302와 독립적으로 실행된다. PNU 106으로부터 검색된 데이터를 사용하는 종래 기술과는 달리 SNMS는 도 2상에 나타난 바와 같이 PMU 106에 접속되지 않은 네트워크 요소를 포함하여 모든 타입의 네트워크 요소로부터 위상 데이터를 수신한다. 또한 SNMS는 Local Exchange Carrier(LEC) 또는 국제 캐리어와 같은 외국 네트워크의 위상을 나타내는 데이터를 사용한다. 상기 데이터는 어느 end 커스터머가 SS7 링크 정지에 의하여 영향을 받을 수 있는가와 같은 fact를 SNMS 사용자가 결정하는 것을 허용할 임팩트 부과를 실행하는데 사용된다. 상기 타입의 위상 데이터는 SNMS에 의하여 수집되고 사용되며, 그리고 예를 들면 STP 104와 Switch/SSP 102와의 상기 SS7 링크를 위하여 데이터는 네트워크 오더 엔트리 및 엔지니어링 시스템에 의하여 수신된다.상기 데이터 및 그 내용에 대한 간략한 설명은 다음과 같다.
STP 링크 ID 상기 STP로의 각 SS7 링크를 식별한다.
Switch 링크 ID 상기 Switch/SP로의 각 SS7 링크를 식별한다.
STP 링크세트 상기 STP로의 링크의 트렁크 grouping 을 식별한다.
Switch 링크세트 상기 Switch/SP로의 SS7링크의 트렁크 그룹핑을 식별한다.
MCI/Telco 회선 ID 외부 시스템으로의 SS7 링크를 식별한다. 두 개의 다른 네트워크에서의 인터페이스를 위하여 각 ID(MCI ID 및 Telco ID)는 각 네트워크(본 실시 예에서의 MCI 및 Telco)를 위한 SS7 링크의 식별을 제공한다.
링크 타입 상기 타입의 SS7 링크를 식별한다.
SLC 신호 링크 코드
SS7에 의하여 지원되는 스위치된 음성 네트워크를 위하여 데이터는 네트워크 오더 엔트리 및 엔지니어링 시스템에 의하여 수신되고 SS7 이벤트 임팩트 부과를 실행하기 위하여 사용된다.
음성 트렁크 그룹 각 SSP 102에 의하여 지원되는 음성 트렁크 그룹
국내 STP 104g를 국제 STP 104h에 SS7 연결을 위하여 데이터는 네트워크 오더 엔트리 및 엔지니어링 시스템에 의하여 수신된다.
회선 ID 외부 시스템으로의 상기 SS7 링크를 식별한다
SLC 신호 링크 코드
임팩트 부과를 실행을 목적으로, 로컬 교환 캐리어(LEC) NPA/NXX 부과 및 END OFFICE to 액세스 탠덤 homing arrangements는 Bellcore의 로컬 교환 경로 지정 가이드(LERG)에 의하여 일반화된 호출 에어리어 데이터베이스에 의하여 수신된다.
LATA 로컬 액세스 이송 에어리어(conventional)
NPA/NXX 넘버링 플랜 에어리어/prefix(conventional)
END Office LEC 커스터머 서빙 노드
액세스 탠덤 LEC 엔드 오피스 허브
외국 네트워크 STP 104 클러스터링 및 SSP 102 호밍 arrangement는 제어 시스템을 통하여 SS7 네트워크에 의하여 수신된다.
포인트 코드 SS7 노드를 식별한다(conventional)
각 네트워크 요소의 어떠한 측면을 식별하는 데이터는 스위치 구성 배치 파일에 의하여 수신되는데, 상기 스위치 구성 배치 파일은 외부 시스템에 위치한다.
각 네트워크 DS-0을 DS-3상으로 mapping하는 데이터는 네트워크 위상 데이터베이스에 의하여 수신된다. 상기 데이터는 NMSD에 의하여 수신된 DS-3 경보를 DS-0레벨 회선로 할당하는데 사용된다.
자동 프로세스를 통하여 습득한 데이터를 겹쳐 쓸 것이 요구되는 데이터는 수동 오버라이드에 의하여 제공된다.
다시 도 7상의 단계 704로 돌아가서, 다양한 위상 데이터가 SNMS 알고리즘이 필요로 하는 데이터 항목을 추출하기 위하여 분석된다. 그리고 나서 상기 데이터는 프로세스 이벤트 402에 의하여 처리될 수 있는 이벤트 기록으로 표준화된다.
단계 706에서는 상기 표준화 데이터 기록이 다른 데이터에 대한 타당성검사가 된다. 예를 들면 회선 위상 기록은 엔드 노드가 식별되고 규정되는 것을 보장하기 위하여 노드 위상 기록에 대한 타당성 검사가 된다.
단계 708에서는 상기 위상 데이터가 Sybase 에 의하여 제공되는 것과 같은 관련 데이터 베이스에서도 도 3의 위상서버 306에 저장된다.
단계 710에서는 상기 새로운 위상 기록이 상기 우상 서버 306으로부터 경보 서버 302상에서 실행되는 주 SNMS 프로세스로 전달되고 능동 구성 배치(현재 메모리에 로드된 구성 배치)에 대하여 비교된다. 액티브 경보 및 GUI 디스플레이는 존재하지 않는 위상 엔트리에 관계되는 경보를 제거하는 것과 조화된다.
단계 712에서는 상기 위상이 성능을 이유로 flat 파일의 형태로 상기 경보 서버 302(프로세스 이벤트 402의 사용을 위하여)에 저장된다. 이때 상기 flat 파일은 단계 708로부터 상기 위상 서버 306 데이터베이스를 반영한다. 상기 flat 파일은 오로지 주 프로세스에 의하여 액세스 할 수 있다. 단계 714에서는 상기 새로운 위상 기록이 능동 SNMS 메모리로 로드 되고 우상 데이터를 필요로 하는 새로운 프로세스는 이제 새로운 구성 배치를 사용한다.
도 8은 디스플레이 경보 구성 요소 412의 프로세스를 상세하게 나타내고 있다. 상기 프로세스 구성 요소는 SNMS 처리의 결과를 상기 사용자(오퍼레이터로 언급됨)에게로 제공하고 오퍼레이터 입력을 SNMS 에서 실행되는 조치로 받아들인다. 따라서 디스플레이 경보 412 및 프로세스 이벤트 402 사이의 프로세스는 두 가지 길이 있다, 전 SNMS 시스템을 위하여 실행되는 단일 프로세스 이벤트 프로세스 402가 존재할 때 SNMS 상으로 로그되는 각 오포레이터를 위하여 실행되는 상기 디스플레이 경보 프로세스 412의 다른 실 예가 있음을 주의하여야 한다. 즉 각 오퍼레이터는 디스플레이 경보 412의 분리 실행을 유발시킨다.
오퍼레이터가 SNMS상에 로그할 때 첫 단계 802-808은 초기화 단계로서 실행된다. 상기 단계로부터 단계 810-838은 연속 루프로서 작동한다. 초기화는 각 오퍼레이터에게 작동할 수 있는 시스템 상태를 제공한다. 단계 802에서는 현 위상이 그래픽 사용자 인터페이스(GUI)를 통하여 읽혀지고 디스플레이 된다. 각 오터레이터는 오퍼레이터 요청에 근거하여 초기화되고 종료되는 자신의 GUI 프로세스를 가진다. 각 GUI 프로세스는 독립적으로 자신의 디스플레이를 관리한다. 어떠한 상태 변화도 각각의 프로세스에 의하여 조종된다.
단계 804에서는 특정 오퍼레이터 뷰(view)를 규정하는 필터가 판독된다. 각 오퍼레이터는 그 GUI 프로세스가 디스플레이 할 뷰를 규정할 수 있다. 필터 파라미터는 다음을 포함한다:
1. 통화 경보 또는 사용 난이도(facility) 경보 또는 양자 모두
2. 수신 확인 경보 또는 미 수신 확인 경보 또는 양자 모두
3. 유지 윈도우 내의 회선상의 경보 또는 유지 윈도우 내에 있지 않은 회선상의 경보 또는 양자 모두.
4. 관련 전용 경보(정지 ID를 통한 DS-3 경보)를 가지는 회선상의 경보 또는 관련 전송 경보를 가지지 않은 회선상의 경보 또는 양자 모두.
5. 구체적인 시베러티(severity)를 가지는 경보.
6. 상술된 커스터머 ID가 가지는 모드/회선 상의 경보.
7. 국제 회선상의 경보 또는 국내 회선상의 경보 또는 양자 모두.
상기 오퍼레이터의 GUI 디스플레이는 단계 804에서 초기화 시에 그리고 단계 828 및 830에서 필터 변경이 요청될 때 갱신된다. 상기 디스플레이 경보 412 프로세스의 각각의 특정 오퍼레이터의 실례는 상기 특정 오퍼레이터의 필터에 관련되는 경보 기록만이 전송되도록 하기 위하여 프로세스 이벤트 402와의 접속을 연다. 단계 806에서는 상기 특정 오퍼레이터의 프로세스는 어떠한 경보가 송신되었는지를 식별하기 위하여 프로세스 이벤트 402에 자신을 기록한다. 단계808에서는 상기 GUI 디스플레이가 상기 오퍼레이터에게 제공된다.
디스플레이 경보 412의 계속적인 실행은 단계 810에서 개시된다. 상기 오퍼레이터 필터에 의하여 규정된바와 같이, 검색되고 제공될 각 이벤트는 수신되고 식별된다. 단계 812,816,820, 826 및 826에서는 SNMS가 단계 810에서 만들어진 이벤트 타입 식별에 근거하는 이벤트에 무엇을 하여야 하는지를 결정한다. 단계 812 및 816에서는 상기 이벤트가 경보 갱신 또는 위상 갱신인 것으로 결정된다면, 상기 오퍼레이터 GUI 디스플레이는 단계 814 및 818에서 각각 이것을 반영하기 위하여 갱신된다. 그리고 나서 단계 810에서 다음 이벤트가 수신된다.
단계 820에서는 상기 이벤트가 오퍼레이터 작동임이 결정된다면, 두 개의 조치가 요구된다. 첫 째로는, 단계 822에서 상기 오퍼레이터의 GUI 디스플레이가 상기 상태 변화를 반영하기 위하여 갱신된다. 그리고 나서 단계 824에서 상태 변화 갱신이 주 프로세스로 송신된다. 프로세스 이벤트 402는 상기 상태 변화가 SNMS 기록과 다른 GUI 프로세스(다른 사용자를 위한)에 반영될 수 있도록 하기 위하여 수신되고 상기 상태 변화에 반응할 수 있다.
단계 826에서는 상기 이벤트가 오퍼레이터 디스플레이 실행임이 결정된다면, 그 때 상기 실행이 필터 변경 요구인지 디스플레이 요구인지를 결정한다. 단계 828에서 필터 변경 요구임이 결정된다면 그 때 단계 830에서 상기 GUI 프로세스가 적절한 경보 기록이 전송되도록 프로세스 이벤트 402에 기록한다. 단계 832에 서 오퍼레이터 디스플레이 요구임이 결정된다면 그 때 단계 834에서 상기 요구 디스플레이가 상기 오퍼레이터에 제공된다. 디스플레이 요구는 다음을 포함할 수 있다:
1. 노드 상세 및 접속
2. 회선 접속
3. 링크 세트 접속
4. 미지의 위상 경보(위상 데이터베이스에 규정되지 않은 오브젝트에 대한 경보)
5. STP 쌍 접속
6. LATA 내에 포함된 노드
7. Home/Mate 접속(비 인접 노드를 위함)
8. NPA/NXX 리스트
9 트렁크 그룹 리스트
10. 최종 오피스 액세스 탠덤
11. 규칙 규정 도움 스크린(상기 오퍼레이터가 상기 경보를 발생하는데 사용되는 실제 알고리즘을 이해하는데 도움을 줌)
12. 권고 실행(특정 경보가 수신될 때 취해야 하는 오퍼레이터 규정 실행)
단계 836에서 상기 이벤트가 종료 요구임이 결정된다면 그 때 상기 특정한 오퍼레이터의 GUI 프로세스는 단계 838에서 종료된다. 그렇지 않으면 다음 이벤트가 단계 810에서 수신된다. 디스플레이 경보 프로세스 내에서 SNMS는 오류 격리, 임팩트 평가 및 장애 처리를 지원하는 몇 개의 고유 디스플레이 윈도우를 제공한다. 노드 및 회선 심볼을 포함하는 모든 상기 GUI 디스플레이는 SNMS 내의 액티브 윈도우이다(즉, 스크린은 노드 및 회선의 경보 상태가 변경될 때 동적으로 갱신된다). 모든 상기 디스플레이는 SNMS 내에서의 사용되는 한 세트의 MCI 위상 소스(source)에 기인할 수 있다. SNMS는 오퍼레이터 디스플레이에서 사용되는 SNMS의 확장 위상처리를 가지고 있다.
A. SNMS 회선 맵
상기 윈도우는 선택된 링크 세트에 대한 위상 및 경보 상태 정보를 디스플레이 한다. 네트워크 이벤트가 수신될 때, SNMS는 최종 포인트 사이의 관계를 인식하고 발생 경보를 감소시킴으로써 오류를 격리시킨다. 상기 디스플레이는 상기 오퍼레이터가 (노드의 원근(perspective)으로부터) 시그널링 회선의 양측으로부터 보이는 바와 같은 링크 세트를 검사하는 것을 허용한다.
B. SNMS 접속 맵
상기 윈도우는 MCI의 시그널링 네트워크의 클러스터 뷰를 제공한다. 클러스터에서 MCI STP에 접속된 non-MCI 노드 및 MCI 모두는 상기 관련 링크 세트를 따라 디스플레이 된다. 클러스터 뷰는 단일 STP 오류/격리가 서비스 임팩팅이 아니기 때문에 중요하나 클러스터 오류는 모든 MCI SP가 상기 클러스터에서의 양 MCI STP와의 접속성을 가지기 때문에 중요하지는 않다.
C. SNMS 비 인접 맵
상기 윈도우는 선택된 LEC 시그널링 네트워크의 STP 쌍 뷰를 제공한다. LEC STP 쌍에 접속된 (상기 MCI 네트워크와 시그널링 관계를 가진) 모든 LEC SP, STP 및 SCP는 디스플레이 된다. MCI의 책임 영역에는 LEC SSP 시그널링 링크로의 상기 LEC STP가 포함되지 않고 따라서 어떠한 링크 세트도 디스플레이 되지 않는다. 상기 디스플레이는 상기 SNMS 오퍼레이터가 상기 MCI 노드에 의하여 보이는 바와 같은 LEC 시그널링 네트워크를 검사하는 것을 허용한다.
D. SNMS LATA 접속 맵
상기 윈도우는 특정 LATA 내에 위치하는 모든 LEC 소유의 노드의 맵을 제공한다. 또한 상기 LATA에 서비스하는 상기 MCI STP 쌍은 역시 (적용할 수 있는) 관련 링크 세트에 따라 디스플레이 된다. 상기 디스플레이는 문제가 상기 LATA 내에서 드러나는 경우/드러날 때 상기 오퍼레이터가 특정 LATA를 면밀히 검사하는 것을 허용한다. LATA 문제는, 비록 MCI의 제어 도메인 외부이지만 시그널링 메시지가 상기 네트워크 사이에서 공유되기 때문에 상기 MCI 네트워크 내부에 문제를 도입할 수 있다. 또한 상기 특정 LATA에서 착신되는 MCI 음성 통화는 LATA 정지에 의하여 영향을 받을 수 있다.
E. NPA-NXX 정보 리스트
상기 윈도우는 특정 LEC 스위치에 의하여 서비스되는 NPX-NXX 정보의 리스트를 제공한다. 상기 디스플레이는 임팩트 평가 기간 동안 매우 유용하다(즉, 상기 특정 LEC 스위치가 격리되어 있다면 그 NPA-NXX 정보는 무용하다).
F. 최종 사무 정보 리스트
상기 윈도우는 특정 LEC 액세스 탠덤 정위치된 LEC 최종 사무 노드의 리스트를 제공한다. 상기 디스플레이는 임팩트 평가 기간 동안 매우 유용하다(즉, 상기 특정 LEC 탠덤 스위치가 격리되어 있다면 그 최종 사무는 무용하다).
G. 트렁크 그룹 정보 리스트
상기 윈도우는 특정 MCI 스위치에 접속된 MCI 음성 트렁크 및 그것이 종료되는 상기 LEC 최종 사무 스위치의 리스트를 제공한다. 상기 디스플레이는 임팩트 평가 기간 동안 매우 유용하다(즉, MCI 스위치가 격리될 때 그 최종 사무는 임팩트 된다). 상기 디스플레이는 선택된 LEC 최종 사무 스위치에 또한 사용될 수 있다.
H. 필터 규정 윈도우
상기 SNMS 오퍼레이터는 그 디스플레이의 범위를 다음과 같이 한정할 수 있다:
- 제공되어야 하는 경보의 타입
- 제공되어야 하는 경보의 severity
- 수신 통보 경보 또는 미 수신 통보 경보 또는 양자 모두
- 계획된 정지 윈도우 내부의 회선상의 경보 또는 계획된 정지 윈도우 외부의 회선상의 경보 또는 양자 모두
- 특정 전송 네트워크 정지의 결과가 아닌 경보
- 특정 커스터머 노드 상의 경보 또는 특정 커스터머에 접속된 회선상의 경보
1. 장애 티켓 윈도우
상기 SNMS 오퍼레이터는 시그널링 경보 상에 장애 티켓을 열 수 있다. 상기 장애 티켓은 MCI의 장애 티켓 시스템에서 개방된다. 도한 오퍼레이터는 현 장애 티켓의 상태를 디스플레이할 수 있다.
도 9에는 데이터 보고 구성요소 414의 프로세스가 상세히 나타나 있다. 상기 프로세스 구성요소는 보고 서버 304 상에서 실행되는데 SNMS 처리 데이터를 저장하고 보고서를 제공한다.
표준화된 네트워크 요소(NE) 이벤트 기록 914는 로케이션 특정 시간 스탬프와 함께 수신된다. 단계 902에서는 상기 타임 스탬프가 표준화된 보고가 생성될 수 있도록 하기 위하여 그리니치 평균 시간(GMT)으로 변경된다.
단계 904에서는 수신된 모든 데이터가 각 데이터베이스 표에 저장된다. 데이터는 또한 장기간 저장을 위하여 테입 또는 디스크로 보관될 수 있다. 상기 데이터는 SNMS-발생 경보 916, 표준화 위상 기록 918 및 PMU 920으로부터의 성능 통계를 포함한다. 상기 데이터는 또한 NMS 328으로부터의 DS-3 경보 및 네트워크 유지 스케쥴 데이터 340과 같은 미 처리 데이터를 포함할 수 있다.
단계 906에서는 보고서가 생성된다. 상기 보고서는 주문형 또는 폼 보고서일 수 있다. 상기 보고서는 또한 요구가 있는 즉시 또는 스케쥴마다 작성될 수 있다. 상기 보고서는 다소의 방식으로 제공될 수 있는데, 상기 방식에는 전자 메일 908, X-터미널 디스플레이 910 및 프린트된 보고서 912로 한정되지는 않는다.
XII. 포트를 통한 영상 텔레포니
포트를 통한 음성으로부터의 논리적 다음 단계는 영상이다. 오늘 날 컴퓨터는 어떠한 타입의 컴퓨터 네트워크에 접속될 때 상호 영상 "호출"을 할 수 있다. 그러나 대부분의 사람들은 오로지 포트상의 그들의 모뎀으로부터 네트워크에 접속된 컴퓨터상의 또 다른 모뎀과 호출을 함으로써 컴퓨터 네트워크에 접속하고, 그 결과로 그들은 그 때 네트워크 상에서 또 다른 컴퓨터를 호출할 수 있는데, 상기 또 다른 컴퓨터는 모뎀에 의하여 차례로 또 다른 네트워크 컴퓨터에 접속된다. 네트워크 오버헤드 없이 포트 상에서 직접적으로 또 다른 사람을 호출하고 모뎀이 상호 통신을 할 수 있게 하는 것이 보다 간편하다(그리고 능률적이다). ITU 권장 H.324는 포트 상에서 작동하는 V.34 모뎀을 이용하는 저 비트율(28.8kbps 모뎀) 멀티미디어 통신용 터미널을 기술하고 있다. H.324터미널은 실-시간 음성, 데이터 및 영상 또는 영상 텔레포니를 포함하는 어떠한 조합을 실행할 수 있다. H.324 터미널은 퍼스널 컴퓨터로 통합될 수 있고 영상 전화 및 텔레비전과 같은 독립형의 디바이스에 제공될 수 있다. 각 미디어 타입(음성, 데이터, 영상)의 지원은 션택적이지만, 지원되면 오퍼레이션의 특정 공통 모드의 사용 능력이 요구되며, 그 결과 상기 미디어 타입을 지원하는 모든 터미널은 상호 작용할 수 있다. H.324는 둘 이상의 사용되는 각 타입의 채널을 허용한다. H.324시리즈의 다른 권장 안은 H.324 멀티플렉스(음성, 데이터, 영상의 조합), H.245 제어, H.263 영상 코덱(디지털 인코더 및 디코더) 및 G.723.1.1 음성 코덱을 포함한다.
H.324는 ITU 권장 H.245의 논리 채널 시그널링 절차를 사용하는데, 상기 절차에는 각 논리 채널의 컨텐드가 채널이 열릴 때 기술된다. 절차는 각 사용자가 그들의 장치의 멀티미디어 능력만을 이용하는 것을 허용하는데 에 제공된다. 예를 들면 영상 능력은 가지지 못하고 오직 음성 능력만을 가지는 누군가에게 영상 (및 음성)호출을 시도하는 사람은 여전히 음성 방식으로 통신할 수 있다(G.723.1.1).
규정에 의한 H.324는 포인트-투-포인트 프로토콜이다. 둘 이상의 다른 사람과 회의하기 위해서는 MCU(Multipoint Control Unit)이 영상-호출 브릿지로서 작용될 것이 요구된다. H.324 컴퓨터는 무선 네트워크 상의 컴퓨터뿐 아니라 ISDN 상의 H.320 컴퓨터와 상호 작용할 수 있다.
A. 영상 텔레포니 시스템의 구성 요소
1. ACD를 가지는 DSP 모뎀 풀
디지털 신호 프로세서(DSP) 모뎀 풀은 각 모뎀이 특별한 기능(새로운 V. 모뎀 프로토콜, DTMF 검출)을 위하여 프로그램될 수 있는 능력을 가지는 모뎀 뱅크이다. 호출은 MCI 스위치로부터 ACD로 경로 지정된다. 상기 ACD는 DSP 모뎀이 사용할 수 있는 매트릭스를 보유한다. 또한 어떠한 에이전트 그룹이 상기 호출을 처리하는데 자유로운가를 결정하는 그룹 선택을 하는 ISNAP와 통신할 수 있다. 대체 실시 예에 따르면 DSP 리소오스는 ACD 없이 배치 즉 스위치에 직접 접속될 수 있다. 상기 실시 예에서는 상기 DSP 리소오스가 NCS에 기초한 경로지정 단계를 사용하여 관리된다.
2. 에이전트
에이전트는 휴먼 영상 오퍼레이터(영상 capable MTOC), 또는 자동 프로그램(영상 ARU). 상기 ACD는 어떠한 에이전트 포트가 사용가능한 가를 알고 에이전트를 에이전트 포트에 접속한다.
3. 보류 영상 서버(영상 on Hold Server)
ACD가 사용 가능한 에이전트 포트를 가지고 있지 않는 경우 그때 상기 호출자는 ACD가 프리(free) 에이전트 포트를 발견할 때까지 영상 On Hold Server에 접속되는데, 상기 영상 On Hold Server는 애드버타이즈먼트 및 다른 비-상호 작용의 영상을 보내는 능력을 가지고 있다.
4. 영상 메일 서버
영상-메일 메시지는 여기에 저장된다. 커스터머는 그들의 메일을 관리하고 상기 서버에 저장된 인사말을 기록할 수 있다.
5. 영상 컨텐트 엔진(Video Content Engine)
주문형 영상 컨텐트는 상기 영상 Content 엔진 상에 위치한다. 여기에 저장된 영상은 미리 기록된 영상-회의, 훈련 영상(training video) 등 일 수 있다.
6. 예약 엔진(Reservation Engine)
사람들이 다중-집단 영상-회의를 계획하기 원할 때 그들은 상기 시스템에 회의 참가자 및 시간을 상세히 열거하여야 한다. 구성배치는 인간 영상 오퍼레이터의 도움을 받거나 또는 어떠한 다른 폼(form) 엔트리 방식에 의하여 이루어질 수 있다.
7. 영상 브릿지
H.324가 포인트-투-포인트 프로토콜이므로 멀티-포인트 회의 유닛(MCU)은 각 참가자를 관리하고 적절하게 영상 흐름을 다시 보낼 필요가 있다. MCU 회의는 H.324 및 H.320 compliant 시스템을 가지는 커스터머에 사용될 수 있을 것이다.
B. 시나리오
컴퓨터 또는 세트-톱(set-top) TV는 H.324 compliant 소프트웨어와 28.8 kpbs(V.34) 또는 그 이상에 매우 적당한 POTS를 통한 사용을 위한 모뎀을 가진다. 하나의 목적은 또 다른 집단을 호출하는 것이다. 그들이 응답을 하지 않거나 통화중인 경우, 발신자는 착신 측을 위하여 영상-메일을 남길 수 있는 선택권을 가진다. 또 다른 목적은 셋 이상의 참가자단의 회의에서 계획하고 참가하는 것이다.
C. 접속 셋업
도 19B는 바람직한 실시 예에 따른 호출 접속 셋업을 보여 준다. 누군가에게의 영상 호출을 하는데는 세 가지 방식이 있다. 첫 번째 방식은 단순히 그를 호출하는 것이다. (도 19B의 1부터 7) 착신지가 통화 중이거나 응답을 하지 않는다면 그 때 호출자는 1 800 VID MAIL으로 또 다른 호출을 하고 다음과 같은 적절한 절차를 실행한다.
사용자가 1에서 "1 800 VID MAIL"을 다이얼 호출할 때 DSP 모뎀 풀 상의 ACD는 스위치를 모뎀 2에 접속하고 포트를 에이전트 3에 접속할 것이다. 그리고 나서 H. 324 대역폭의 데이터 흐름부(ITU T.120 표준을 사용함)를 이용하는 특별한 커스텀 터미널 프로그램의 상기 시스템으로의 상기 사용자 로그-인은 V-mail 데이터 인터페이스(VMID)를 호출한다. 그래픽 사용자 인터페이스, 아이콘, 또는 다른 메뉴로부터 상기 호출자는 다음과 같은 것을 선택할 수 있다:
- 영상-가능한 MCI customer 의 디렉토리를 띄엄띄엄 읽거나 검색하는 것
- 또 다른 H.324 compliant 소프트웨어 프로그램을 호출하는 것
-연착을 위한 Store ＆ Forward를 위하여 영상-메일을 만드는 것
- 영상-메일 안부 메시지를 개인화하고 기록하는 것
- 그들의 영상-메일을 보고 관리하는 것 또는
- 기록 보관소로부터 선택을 보는 것(Video On Demand)
대체 실시 예에 따르면 사용자는 번호를 호출하기 위하여 "1 800 324 CALL"을 다이얼 호출 할 수 있다. 그리고 나서, 착신 번호가 1 310 375 1771이다면, 모뎀 다이얼 string은 "ATDT 1 800 324 CALL,,,1 319 375 1772"(상기 콤마','는 상기 모뎀이 다이얼 호출 중에 잠깐 멈춤을 할 것을 알리는 것임)가 될 것이다. 1 800 324 CALL로의 접속이 이루어질 때 접속은 발신지로부터 ACD 2a, 3a에 의하여 선택된 MCI 스위치 1로 ARU 5a로 이루어진다.
상기 ARU 5a는 착신번호를 얻기 위하여 전화 키패드 또는 DTMF tone을 발생시키는 다른 디바이스를 통하여 입력된 DTMF tone을 검출한다. 상기 발신기는 상기 ARU 5a 착신번호 5a, 6a 및 7로 분리 호출을 할 때 보류 상태로 남아 있는다. 상기 착신지가 응답을 하면 상기 발신기는 착신지에 접속되고 양측의 모뎀은 접속될 수 있고 상기 ARU 5a는 복구된다. 착신기가 통화중이거나 응답을 하지 않으면, 상기 호출은 상기 DSP 모뎀 풀 2를 통하여 1 800 VID MAIL 또는 에이전트로 이송된다. 상기 에이전트는 상기 호출자와의 H.324 접속을 하고 그들의 착신 번호에 대하여 문의할 것이다(또는 도움을 제공함). 상기 대체예의 구조는 대체 실시 예에 관하여 논의되었던 바와 같은 directlineMCI 시스템에서 fax가 검출되고 전송되는 방법과 유사하다.
D. 착신지의 호출
상기 착신 번호를 알고 있을 때 상기 영상 On Hold Server는 상기 H.324 접속 4에 상기 영상 입력을 제공한다. 새로운 호출은 에이전트 5.6으로부터 착신번호 7로 이루어진다. 상세한 실시 예를 실시함에 있어 해석을 요하는 하나의 관심사는 모뎀이 스위치 작동 후에 오프-라인 됨이 없이 재-동기화 할 수 있는 가에 대한 결정을 요구한다. 상기 착신 번호가 응답하고 그것이 모뎀이라면, 접속은 반드시 발신지 모뎀 스피드와 동일한 스피드 하에서 이루어져야 한다. 모뎀 핸드쉐이킹(handshaking)이 실행된 후에는 상기 ACD는 상기 스위치가 상기 에이전트 3.5를 복구시킬 것과 상기 모뎀 2와 6을 복구시킬 것을 지시하고 상기 발신지를 착신지 1과 7에 접속한다. 상기 착신 PC는 상기 접속이 H.324 호출(fax, 기타가 아닌)임을 인식하고 상기 영상-호출은 진행된다.
대체 실시 예에 따르면, 상기 착신지가 응답을 하고 그것이 모뎀인 경우 접속은 이루어진다. 그 때 두 개의 H.324 호출은 두 개의 DSP 모뎀을 사용하고 있다. 상기 에이전트는 호출 3 및 5 양자로부터 복구될 수 있다. 각 호출로부터의 입력 데이터는 상기의 다른 호출 2 및 6으로 복사된다. 상기 방식에서 에이전트는 영상 Store ＆ Forward 9에 대한 영상 호출을 검사할 수 있다. 하나의 접속이 캐리어를 빠뜨릴 때, 상기 영상-호출은 완전하고 잔여 호출을 위한 모뎀 캐리어는 빠뜨려진다.
E. Recording Video-Mail, Store ＆ Forward Video and Greeting
착신 번호가 응답을 하지 않거나 통화중인 경우 영상 메일 서버는 착신 번호 8 소유자를 위하여 적절한 영상-메일 인사를 보낸다. 그리고 나서 상기 호출자는 영상-메시지를 남겨두는데, 그것은 상기 영상 메일 서버에 저장된다. Store ＆ Forward 영상을 위한 영상 기록은 상술했던 영상 메시지를 남기는 것과 정확히 일치하고 착신번호, 발송 시간 및 현재 사용할 수 있는 기타의 음성 S＆F 기능과 같은 파라미터는 상기 VMDI를 통하여 입력되거나 휴먼 비디오 오퍼레이터 (또는 자동 비디오 ARU)와 통신된다.
당신이 통화중이거나 응답을 하지 않으므로 인하여 누군가가 당신에게 도달할 수 없을 경우 재생을 위한 개인화된 인사말을 기록하는 것은 영상-메일을 남기는 것과 유사하다. 상기의 기록을 할 것인가의 선택은 상기 VMDI를 통하여 이루어지거나 휴먼 비디오 오퍼레이터와 통신된다.
F. 영상-메일 및 주문 영상의 검색
사용자는 새로운 메시지에 대하여 사용자 영상-메일을 주기적으로 폴링 하도록 선택할 수 있거나, 사용자가 새로운 대기 메시지를 가질 때 영상 메일 서버가 사용자를 주기적으로 호출하게 한다. 구성 배치는 상기 VMDI 또는 휴먼 비디오 오퍼레이터를 통하여 이루어진다. 영상-메일을 관리하고 검사하는 것은 또한 VMDI를 통하여 실행되거나 휴먼 비디오 오퍼레이터와 통신된다.
주문 영상(VOD)에 대한 영상 뷰의 선택은 VMDI를 통하여 이루어 진다. 상기 영상은 기-기록된 영상-회의, 트레이닝 영상 등 일 수 있고 영상 Content 엔진 9상에 저장될 수 있다.
G. 영상-회의 Scheduling.
사용자는 VMDI 또는 인터넷 10 WWW 폼을 통하여 항행할 수 있거나 다분기점 회의를 계획하기 위하여 휴먼 영상 오퍼레이터와 통신할 수 있다. 상기 정보는 예약 엔진에 저장된다. 다른 회의 참가자는 영상-메일, e-mail 메시지 등에 의하여 스케줄 통지를 받는다. 모든 등록된 회의 참가자에게 특별한 시간(예컨대 회의 1시간전)에 영상-메일(또는 e-메일, 음성-메일, 페이징 서비스 또는 기타의 사용 가능한 통지 방식)을 통하여 리마인드 할 수 있는 선택을 할 수 있을 것이다. 상기 MCU(영상 bridge)는 각 참가자 12를 호출할 수 있고 H.324 사용자는 계획된 시간 12에서 상기 MCU로 다이얼 호출할 수 있다.
XIII 인터넷을 통한 영상 텔레포니(VIDEO TELEPHONY OVER THE INTERNET)
도 19E는 바람직한 실시 예에 따른 인터넷을 통한 영상 전화를 전송하기 위한 구조를 보여준다. 실-시간 전송 프로토콜(RTP) RTP에 기초한 영상 회의는 메시지로 요약된 음성, 비디오 및 데이터 전송에 대해 언급하고 있다. RTP에 기초한 영상-회의 세션을 위하여 최종 사용자 스테이션은 맨 먼저 RTP 메시지를 전송하는데 사용되는 인터넷과의 다이얼-업(dial-up) 포인트-투-포인트(PPP) 접속을 설정한다. 음성 정보는 G.723.1.1 음성 코덱(코더-디코더)에 따라서 압축되고, 비디오는 ITU H.263 비디오 코덱 표준에 따라서 압축되고 데이터는 ITU-T.120 표준에 따라 전송된다.
RTP는 실-시간 상태량을 가진 어플리케이션의 지원을 제공하는 프로토클이다. UDP/IP 그 초기 목표 네트워킹 환경일 때, RTP는 IPX 또는 다른 프로토콜 상에서 사용되기 위하여 전송에 독립적이다. RTP는 리소스(resource) 예약 또는 서비스 제어의 질의 발행을 어드레스 하지 않는다. 대신에 RSVP와 같은 리소오스 예약 프로토콜에 의존한다. 대부분의 네트워크 사용자에게 익숙한 전송 서비스는 포인트-투-포인트 또는 유니캐스트 서비스이다. 이것은 HDLC 및 TCP와 같은 네트워킹 프로토콜에 의하여 제공되는 서비스의 표준 형식이다.
브로드캐스트 서비스는 (wire-based 네트워크 상에서, 하여튼)다소 덜 일반적으로 사용된다. 대형 네트워크를 통하여는 브로드캐스트는 용인하기 어렵고 (왜냐하면 개인 sub-net가 관여되어 있는가 여부를 고려치 않고 브로드케스트는 도처에 네트워크 대역폭을 사용하기 때문이다), 따라서 브로드케스트는 일반적으로 LAN-wide 사용으로 제한된다(브로드케스트 서비스는 IP와 같은 저-레벨 네트워크 프로토콜에 의하여 제공된다). LAN에서 조차도 브로드케스트는 때때로 바람직하지 않은데 이는 모든 장치와 상기 브로드케스트 데이터가 관여되어 있는지 여부를 결정하기 위하여 상기 모든 장치가 프로세싱을 실행할 것을 상기 브로드케스트가 요구하기 때문이다.
좀더 실용적인 잠재적 광 청취(wide audience)를 위한 데이터 전송 서비스는 멀티캐스트이다. WAN 상의 멀티캐스트 모델에서는 특별한 멀티캐스트 서비스에 능동적으로 관여하는 호스트만이 그들에게 경로 지정된 상기 데이터를 가질 것이다. 이것은 멀티 캐스트 데이터의 발신기 및 수신기 사이의 링크를 위한 대역폭 소모를 막는다. LAN 상에서 많은 인터페이스 카드는 관련성을 기록하지 않은 멀티 캐스트 데이터를 상기 인터페이스 카드가 자동적으로 무시할 수 있는 편리성을 제공한다; 이는 무관련한 호스트상의 불필요한 처리 오버헤드를 방지하는 결과를 야기한다.
A. 구성 요소
영상 Content 엔진 및 MCI 회의 공간 네트워크로부터의 영상 브로드케스트 MBONE 기능을 가지는 RSVP Routers. MCI는 국부적으로 다중 분기하고 인터넷 외부로 다수의 유니캐스트를 전송하는 MBONE 네트워크를 가질 수 있다.
RSVP는 인터넷 어플리케이션이 그 데이터 흐름을 위하여 특별한 서비스 질을 얻는 것을 허용할 수 있는 네트워크 제어 프로토콜이다. 상기 RSVP는 일반적으로(필수적이지는 않는) 시간적으로 앞서서 또는 동적으로 데이터 경로를 따라서 리소오스를 예약하는 것을 요구할 수 있다. RSVP는 미래의 "통합 서비스"인터넷의 구성 요소인데, 이것은 서비스의 양질의 성과와 실-시간 품질을 제공한다. 실시 예는 후술하는 바와 같이 명세서에 상세히 나타나 있다.
호스트(엔드 시스템)에서의 어플리케이션이 데이터 흐름을 위하여 특정 QOS를 요청할 때 RSVP는 상기 데이터 흐름의 경로를 따라 각 루터에 상기 요청을 전달하고, 요청된 서비스를 제공하고자 루터 및 호스트 상태를 유지하기 위하여 사용된다. 비록 RSVP가 리소오스 예약의 셋업을 위하여 개량되었지만 상기 RSVP는 데이터 흐름 경로를 따라 다른 종류의 네트워크 제어 정보를 이송하는데 용이하게 적응할 수 있다.
1. 디렉토리 및 등록 엔진
사람들이 (모뎀 다이얼-업, 직접 접속 등을 통하여) 인터넷에 접속될 때, 그들은 디렉토리에 자신들을 등록할 수 있다. 상기 디렉토리는 특정한 사람이 회의에 참석할 수 있는 지를 결정하는데 사용된다.
2. 에이전트
에이전트는 휴먼 비디오 오퍼레이터(영상 Capable MTOC) 또는 자동 프로그램(영상 ARU)일 수 있다. 바람직한 실시 예에 따른 인터넷 ACD는 에이전트 포트가 관리될 수 있도록 설계되어 있다. 상기 ACD는 어떠한 에이전트 포트가 이용될 수 있는지를 알 수 있고 에이전트를 이용 가능한 에이전트 포트에 접속한다. 상기 ACD가 이용 가능한 에이전트 포트를 가지지 않는다면, 그때 호출자는 영상 On Hold Server에 접속되는데, 이것은 상기 ACD가 프리 에이전트 포트를 찾을 때까지 애드버타이즈먼트와 다른 비-상호작용 영상을 작동 할 수 있는 능력을 가진다.
3. 영상 메일 서버(영상 Mail Server)
영상-메일 메시지는 여기에 저장된다. 커스터머는 상기 서버에 저장되도록 그들의 메일을 관리하고 인사말을 기록할 수 있다.
4. 영상 Content 엔진
주문 영상 content는 영상 Content 엔진에 위치한다.
여기에 저장된 비디오는 기-기록된 비디오-회의, 트레이닝 비디오 등일 수 있다.
5. 회의 예약 엔진
사람들이 집단 화상 회의를 계획하기를 원할 때, 그들은 상기 시스템 상에서 회의 참석자 및 시간을 명기할 수 있다. 구성배치는 휴먼 화상 오퍼레이터의 도움 또는 어떠한 다른 형식의 엔트리 방식에 의하여 행해질 수 있다.
6. MCI 회의 공간
이것은 커스터머가 나타날 수 있는 가상 현실 영역이다.
모든 참석자는 "avatar"로 개인화 된다. 각 애버타는 가시 아이덴터티, 화상, 음성 등과 같은 많은 능력과 기능을 가지고 있다. 애버타는 도큐먼트 공유, 파일 전송 등을 나타내는 다양한 오브젝트를 조정함으로써 상호 작용하며 상호간을 보는 것은 물론 상호간의 대화도 가능하다.
7. 가상 현실 공간 엔진
회의 공간은 가상 현실 엔진에 의하여 만들어지고 관리된다.
상기 가상 현실 엔진은 상기 회의 공간의 오브젝트 조작 및 기타의 논리적 설명을 관리한다.
B 시나리오
사용자가 현재 인터넷으로의 접속을 하고 있다고 가정한다. 상기 사용자는 상기 인터넷을 통하여 RTP(TCP에 대항하는)를 이용하는 H.263 compliant system 소프트웨어를 이용할 수 있다. 상기 사용자가 또한 VR MCI 회의-공간에 참석하고 화상-메일을 생성/보기를 원한다면, 상기 사용자는 VR 세션을 결합할 수 있다.
C 접속 셋업
인터넷 상에서 타인에게 화상 호출을 하는 가장 손쉬운 방법은 초기 전화 호출로서 메뉴와 옵션을 통하여 항행함이 없이 간단히 상기 호출을 하는 것이다. 그러나 착신지가 통화중이거나 응답을 하지 않는다면, MCI는 depositing 메시지에 서비스를 제공한다. 커스터머는 telnet 서버(예를 들면 telnet vmail.mci.com)로 로그인할 수 있거나 주문-생산 클라이언트 또는 WWW(예를 들면 http://vmail.mci.com)을 사용할 수 있다. 상기 서비스 메뉴는 상술한 바와 같이 포트를 통하여 다이얼 호출할 때 사용할 수 있는 VMDI와 유사한 V-메일 데이터 인터페이스(VMDI)로 언급된다.
메뉴로부터 상기 호출자는 다음을 선택할 수 있다.
-영상-가능한 MCI 커스터머의 디렉토리를 띄엄띄엄 읽고 검색하는 것
-또 다른 H.263 compliant 소프트웨어 프로그램을 호출하는 것
-연착에 대비하여 축적 및 전달을 위한 화상-메일의 생성
-그들의 화상-메일 인사 메시지를 개인화하고 기록하는 것
-그들의 화상-메일을 보고 관리하는 것, 그리고
-기록 라이브러리로부터 선택을 보는 것(Video On Demand)
사용자가 착신지명, IP 어드레스 또는 다른 ID을 나타냄으로써 호출 참가자를 상세히 설명할 때, 디렉토리가 검사된다. 착신지가 실제 호출 없이 호출을 받아들일 수 있는지 결정하는 것이 가능하다; 왜냐하면 착신지가 호출을 받아들일 수 있음이 결정될 수 있고 따라서 발신지 영상 클라이언트는 착신지에 접속될 수 있음을 통보 받을 수 있기 때문이다. 상기 호출자가 상기 VMDI에 액세스하기 위하여 WWW 브라우저(예를 들면 Netscape Navigator, Microsoft Internet Explorer, internetMCI Navigator 등)를 사용한다면 그때 호출은 자동적으로 Java, JavaScript 또는 Helper App를 사용하며 개시된다. 호출이 완료될 수 없다면 화상-메일을 남겨둘 수도 있다.
D. 영상-메일, 축적 및 전달과 인사의 기록(Recording Video-Mail, Store ＆ Forward Video and Greetings)
에이전트가 착신 측이 이용될 수 없다고 (오프-라인, 통화중, 무응답 등)결정하면 상기 화상 메일 서버는 착신 번호 8의 소유자를 위하여 적절한 화상-메일 인사를 행한다. 그리고 나서 상기 호출자는 화상-메시지를 남겨두는데, 그것은 화상 메일 서버에 저장된다. 축적 ＆ 전달(S ＆ F) 화상을 위한 화상 기록은 정확히 전술의 남겨둔 화상-메시지와 일치한다. 현재 사용될 수 있는 착신 번호 전달 시간, 기타 음성 S＆F 기능과 같은 파라미터는 상기 VMDI를 통하여 입력되거나 휴면 화상 오퍼레이터(또는 자동 화상 ARU)와 통신된다. 커스터머는 통화중이거나 응답이 없어 그들에게 도달할 수 없는 호출자에 대한 그들 자신의 개인화 인사장을 기록할 수 있다. 이는 상기 VMDI를 통하여 또는 휴먼 화상 오퍼레이터와 통신되는 남겨진 화상 메일과 유사한 방식으로 실행된다.
E. 영상-메일 및 주문 영상의 검색(Retrieving Video-Mail and Video On Demand)
사용자는 새로운 메시지를 위하여 그들의 화상 메일을 주기적으로 폴링하거나 그들이 기다리는 새로운 메시지를 가지고 있을 때 상기 화상-메일 서버가 그들을 주기적으로 호출하도록 하는 선택을 할 수 있다. 구성 배치는 상기 VMDI 또는 휴먼 화상 오퍼레이터를 통하여 행해진다. 또한 화상-메일의 관리 및 검사는 상기 VMDI를 통하여 실행되거나 휴먼 화상 오퍼레이터와 통신된다. 주문 영상(VOD)를 위한 가시 화상의 선택은 상기 VMDI를 통하여 제공된다. 상기 화상은 기-기록된 화상-회의, 트레이닝 화상 등일 수 있고, 영상 Content 엔진에 저장된다.
F. 영상-회의
사용자는 회의 공간에서의 회의를 계획하기 위하여 상기 VMDI 또는 인터넷 10 WWW 형식을 통하여 항행할 수 있고 또는 휴먼 화상 오퍼레이터와 통신할 수 있다. 상기 정보는 회의 예약 엔진 8에 저장된다. 다른 회의 참석자는 화상-메일, e-메일 메시지 또는 기타에 의하여 스케줄 통지를 받는다. 선택 사양 독촉장은 화상-메일 (또는 e-메일, 음성-메일, 페이징 서비스 또는 기타의 사용 가능한 통지방식)을 통하여 특별한 시간에(예를 들면 회의 1시간 전에) 모든 등록 회의 참가에게 제공된다.
G. 가상 현실
다중 집단 회의를 위하여 가상 회합 장소가 가상 현실 공간 엔진에 의하여 만들어진다. 상기 인터페이스의 실행은 VRML에 근거하는 실시 예를 포함한다. 각자는 애버타의 제어 하에 있다. 각 애버타는 가시 화상(정적 화상 또는 생생한 화상 "얼굴")과 음성(음성 또는 음악)과 같은 많은 다른 기능을 가질 수 있다. 데이터 교환 및 협조는 각 VR 회의실에서 실행될 수 있는 모든 액션이다. 상기 사적 MBONE 네트워크는 회의 일원의 데이터 흐름의 멀티-캐스팅을 허용한다. 모든 이들이 VR-공간에서 상호 작용할 때 다른 뷰를 가지기 때문에 , 상기 VR-공간 엔진은 각자 애버타의 뷰에서 그들의 애버타 흐름만을 멀티-캐스팅 함으로써 모든 이들의 입력 H.263 흐름을 다른 모든 이들에게 브로드캐스트 하는 것을 최적화 할 수 있다.
XIV. 화상-회의 구조
MCI 화상-회의는 화상 전화를 포함하는 실-시간 음성, 화상 및 데이터 또는 어떠한 조합을 포함하는 멀티미디어 토인을 위한 구조를 기술한다. 상기 구조는 또한 다름 화상-회의 표준과의 상호-작동을 규정한다. 상기 구조는 또한 멀티 포인트 구성 배치 및 제어와 디렉토리 서비스와 화상 메일 서비스를 규정한다.
A. 기능
화상-회의 구조는 멀티미디어 서비스 시스템이고 다음을 포함하는 다수의 기능과 특징을 제공하도록 설계된다.
·포인트-투-포인트 전화
·제어를 위한 MCU 및 멀티미디어 정보 프로세싱을 가지는 멀티미디어 화상-회의
·ITU H.320 및 ITU H.324 표준에 근거한 다른 화상-회의 시스템과의 상호 작용을 위한 게이트웨이의 지원
·실-시간 음성, 화상 및 데이터와 어떠한 조합의 지원
·멀티미디어 정보 흐름은 표준 이송 프로토콜 RPT를 사용하는 최종-사용자 사이에서 이송된다.
·최종-사용자 터미널 사이에서 ITU H.263 화상 및 ITU G.723 음성과 같은 동적 능력 교환 및 모드 선택의 지원
도 19C는 바람직한 실시 예에 따른 화상-회의 구조를 보여준다. 상기 화상-회의 구조의 구성 요소 및 상세는 다음과 같다.
B. 구성 요소
상기 화상-회의 시스템은 다음을 포함하는 구성 요소 세트로 이루어진다.
·최종-사용자 터미널
·LAN 상호 접속 시스템
·ITU H.322 서버
·지원 서비스 유닛
1. 최종-사용자 터미널
상기 최종-사용자 터미널은 통신의 마지막 포인트이다. 사용자는 상기 최종-사용자 터미널을 사용하여 화상 회의에서 통신하고 참가한다. ITU H.322 터미널 1＆ 8과 ITU H.320 터미널 9와 ITU H.324 터미널 10을 포함하는 최종-사용자 터미널은 호출 제어, 멀티 포인트 제어 및 게이트웨이 기능을 제공하는 상기 ITU H.323 서버를 통하여 상호 접속된다. 최종-사용자 터미널은 멀티미디어 입출력이 가능하고 전화 인스트루먼트, 마이크로폰, 비디오 카메라, 비디오 디스플레이 모니터 및 키보드를 구비한다.
2. LAN 상호 접속 시스템
상기 LAN 상호 접속 시스템 3은 MCI 교환 네트워크 2와 H,323 서버 4, 비디오 컨텐트 엔진 5, 비디오 메일 서버 6 및 또한 H.323 디렉토리 서버 7을 포함하는 다른 H.323 시스템과의 사이의 인터페이스 시스템이다. MCI 교환 네트워크와의 통신 링크를 설정하고 상기 LAN 상호 접속 시스템을 통하여 상기 H.323 서버와의 통신을 한다. 상기 LAN 상호 접속 시스템은 상기 H.323 화상-회의 시스템에 ACD 같은 기능성을 제공한다.
3. ITU H.323 서버
H.323 서버 4는 ITU H.320 및 ITU H.324와 샅은 다양한 영상-회의 표준을 지원하는 터미널 사이에서의 상호 작용을 위하여 호출 제어, 멀티 포인트 제어, 멀티 포인트 처리 및 게이트웨이 서비스를 포함하는 다양한 서비스를 제공한다.
상기 H.323 서버는 각각의 다른 시스템과 통신하고 최종-사용자 터미널, 영상 메일 서버 및 H.323 디렉토리 서버와 같은 다른 외부 시스템과 통신하는 각개 구성 요소의 세트로 이루어진다. H.323 서버의 다양한 구성 요소는 다음을 포함한다:
·H.323 게이트키퍼
·오퍼레이터 서비스 모듈
·H.323 멀티 포인트 제어 유닛(MCU)
·H.323 게이트웨이
4 게이트키퍼
상기 H.323 게이트키퍼는 H.323 터미널 및 게이트웨이로 호출 제어 서비스를 제공한다. 상기 게이트키퍼는 다음을 포함하는 다양한 서비스를 제공한다;
·터미널, 게이트웨이 및 MCU를 가지는 호출 제어 시그널링;
·영상-회의 시스템으로의 액세스를 위한 Admissions Control;
·호출 허가;
·대역폭 제어 및 관리;
·다양한 종류의 상호 작용 영상-회의 시스템 사이의 어드레스 번역을 위한 이송 어드레스 번역;
·진행중 호출의 호출 관리;
·디렉토리 서비스를 제공하기 위한 디렉토리 서버 [7]과의 인터페이스; 그리고
·영상 메일 서비스를 위한 영상 메일 서버 [6]과의 인터페이스.
상기 게이트키퍼는 다양한 서비스를 위하여 ITU H.225 흐름 패킷화 및 동기화 절차를 사용하며, 수동 오퍼레이터 서비스를 제공하기 위하여 오퍼레이터 서비스 모듈과 단단히 통합된다.
5. 오퍼레이터 서비스 모듈.
상기 오퍼레이터 서비스 모듈은 수동/자동 오퍼레이터 서비스를 제공하며 상기 게이트키퍼에 단단히 통합된다. LAN상의 다른 곳에 위치하는 수동 또는 자동 오퍼레이터 터미널은 요구되는 오퍼레이터 서비스 모두를 제공하는 상기 오퍼레이터 서비스 모듈을 통하여 게이트키퍼와 상호 작용한다.
6. 멀티 포인트 제어 유닛(MCU)
상기 MCU는 멀티 포인트 제어기 및 멀티 포인트 프로세서로 이루어지며 화상 회의를 위하여 멀티 포인트 제어 및 처리 서비스를 함께 제공한다. 상기 멀티 포인트 제어기는 세 개 또는 그 이상의 터미널 사이의 회의를 지원하기 위하여 제어 기능을 제공한다. 상기 멀티 포인트 제어기는 멀티 포인트 회의에서 각 터미널과의 능력 교환을 실행한다. 상기 멀티 포인트 프로세서는 멀티 포인트 콘트롤러의 제어 하에서 혼합, 스위칭 및 다른 요구되는 처리를 포함하는 데이터 흐름, 음성 및/또는 영상의 처리를 제공한다. 상기 MCU는 멀티 포인트 컨트롤러 및 멀티 포인트 프로세서의 특징 및 기능을 실행하기 위하여 ITU H.245 메시지 및 방법들을 사용한다.
7. 게이트웨이
H.323 게이트웨이는 다양한 전송 포맷사이에서의 적절한 번역을 제공한다. 상기 번역 서비스는 다음을 포함한다.
·H.320 시스템의 일부를 이루는 H.221 및 H.225 사이에서의 호출 시그널링 메시지 번역
·H.245 및 H.242 사이에서의 통신 절차 번역; 그리고
·H.623, H.261, G.723, G.728 및 T.120과 같은 영상, 음성 및 데이터 포맷 사이에서의 번역
상기 H.323 게이트웨이는 전송 포맷과 호출 셋업과 제어 신호 및 절차를 위한 변환 기능을 제공한다.
8. 지원 서비스 유닛
상기 지원 서비스 유닛은 상기 최종-사용자 터미널에 다양한 서비스를 제공하기 위하여 H.323 서버와 상호 작용하는 H.323 디렉토리 서버7과 영상-메일 서버6과 영상 컨텐트 엔진 5를 포함한다. 상기 H.323 디렉토리 서버는 디렉토리 서비스를 제공하고 상기 H.323 서버의 게이트키퍼 유닛과 상호 작용한다. 상기 영상 메일 서버는 H.323 시스템에 생성된 영상 메일 모두의 저장소이고 영상 메일의 생성과 재생을 위하여 H.323 서버의 게이트키퍼 유닛과 상호 작용한다. 상기 영상 content 엔진은 최종-사용자 터미널에 서비스될 수 있는 다른 모든 타입의 영상 컨텐트의 저장소이다. 상기 영상 컨텐트 엔진은 H.323 서버의 게이트키퍼 유닛과 상호 작용한다.
C. 개요
영상-회의 구조에 근거를 둔 상기 H.323은 실-시간 음성, 영상 및 데이터를 포함하는 멀티미디어 통신 또는 영상 전화를 포함하는 어떠한 조합에 대한 구조를 기술한다. H.323 터미널 사용자는 영상 설비를 구비하지 않은 다른 터미널 사용자와의 멀티미디어 영상-회의 세션, 포인트-투-포인트 영상 전화 세션 또는 음성만의 세션에 참가할 수 있다.상기 구조는 또한 ITU H.320 및 ITU H.324와 같은 표준에 근거를 둔 다른 영상-회의 터미널과의 상호작용을 위하여 게이트웨이를 포함할 수 있다.
상기 구조는 검색 설비를 포함하는 완전한 디렉토리 서비스를 제공하기 위하여 디렉토리 서버를 포함한다. 영상 메일 서버는 영상 메일의 기록과 재생을 제공하는 구조의 필수 구성요소이다. 영상 컨텐트 엔진은 또한 멀티미디어 컨텐트 전달 서비스를 제공하기 위한 전체 구조의 일부를 이룬다.
영상-회의 또는 영상 전화 세션에 참가하는 H.323 터미널은 MCI 스위치 네트워크를 통하여 H.323 서버와 통신한다. 상기 H.323 서버는 H.320 또는 H.324 터미널과의 상호 작용을 위하여 호출 제어, 정보 흐름 전달, 멀티-포인트 제어 또한 게이트웨이 서비스를 포함하는 다양한 서비스를 제공한다. 상기 서버는 또한 디렉토리 서비스 및 영상 메일 서비스를 제공한다.
영상 호출을 개시하는 H.323 터미널은 상기 MCI 스위치 네트워크를 통하여 상기 H.323 서버와의 통신 링크를 설정한다. 상기 H.323 서버에 의한 네트워크로의 입장 시에 상기 서버는 영상회의에 참가하는 착신 터미널 또는 착신 그룹을 선택하는 터미널을 개시하는 호출에 다른 사용 가능한 터미널의 디렉토리를 제공한다. 그리고 나서 상기 서버는 상기 선택된 착신 터미널 또는 터미널들과의 통신 링크를 셋업하고, 마지막으로 상기 호출 터미널과 호출된 터미널/터미널들을 연결한다. 상기 착신 터미널이 통화중이거나 또는 사용될 수 없는 경우에는 상기 서버는 영상 메일을 저장하기 위하여 상기 호출 터미널에 영상 메일을 저장하는 선택권을 제공 할 수 있다. 상기 서버는 수령인에게 상기 영상 메일을 통지하고 주문 영상 메일 검색을 위하여 수령인 서비스를 제공한다. H.323 터미널로의 주문 컨텐트 전달과 같은 추가적인 서비스는 상기 H.323 서버에 의하여 제공되고 제어된다.
D. 호출 흐름 실례
영상-회의에 근거를 둔 H.323 구조에 대한 호출 흐름은 다른 H.323, H.320 및 H.324 터미널로의 호출을 포함하는 포인트-투-포인트 호출 및 멀티 포인트 영상-회의 호출을 포함하는 다양한 호출 형태로 상세히 설명된다.
도 19c는 바람직한 실시 예에 따른 다양한 호출 흐름을 보여준다.
1. 포인트-투-포인트 호출
a) 경우 1: 또 다른 H.323 터미널에 대한 H.323 터미널
H.323 터미널 1을 개시하는 호출은 상기 MCI 교환 네트워크를 통하여 또 다른 H.323 터미널[8]로의 호출을 개시한다. 상기 게이트키퍼는 호출 설정 및 호출 제어를 포함하는 세션의 제어에 포함된다. 터미널 최종-사용자 인터페이스는 어떠한 상업적 사용 가능한 웹-브라우저이다.
·호출 터미널 1은 상기 MCI 교환 네트워크로의 다이얼-업 호출을 개시한다;
·상기 호출은 LAN 상호 접속 3 시스템을 통하여 H.323 서버의 H.323 게이트키퍼 모듈에서 종료된다;
·PPP 링크는 잘 알려진 신뢰할 수 없는 이송 어드레스/포트 상에 상기 게이트키퍼 4와 상기 호출 터미널 사이에서 설정된다;
·호출 터미널은 상기 게이트키퍼[4]에 허가 요청 메시지를 보낸다;
·상기 게이트키퍼4는 허가 수신 통보 메시지를 보내고 디렉토리 서버7과 통신하고 호출 터미널에 디스플레이 하기 위하여 호출 터미널로 디렉토리 정보를 되 보내고, 상기 디렉토리 정보를 포인트-투-포인트 또는 회의 모드를 포함하는 호출 모두의 선택을 따라 웹-페이지로서 디스플레이 된다;
·허가 교환 후, 잘 알려진 포트 상에 H.225 호출 제어 메시지를 위한 신뢰할 수 있는 접속의 셋업이 이루어진다;
·상기 터미널 사용자는 상기 포인트-투-포인트 모드를 선택하고 또한 상기 호출의 착신지를 선택한다. 이것은 셋업 요청 메시지이다;
·오퍼레이터 서비스 모듈/오퍼레이터와 함께 상기 게이트키퍼 4는 셋업 요청과 함께 호출된 터미널 8의 호출을 계속한다.
·셋업 요청이 실패할 경우, 상기 게이트키퍼 4는 상기 호출 터미널 1에 실패를 알리고 호출 터미널 1에 영상 메일을 남길 수 있는 선택권을 제공한다;
·호출 터미널 1의 사용자가 착신 터미널 8의 사용자를 위하여 영상 메일을 남기기를 선택할 경우, 상기 게이트키퍼 4는 상기 영상 메일 서버 6과의 접속을 설정하고 H.245 접속을 위하여 상기 메일 서버 6으로부터 신뢰할 수 있는 포트 어드레스를 수신한다.
·상기 게이트 4는 추가적으로 영상 메일 서버 6과의 H.225 호출 제어를 위하여 접속을 설정한다.
·상기 게이트키퍼 4는 H.245 제어 채널을 위하여 신뢰할 수 있는 포트 어드레스를 호출 터미널 1에 차례로 보낸다. 상기 게이트키퍼 4는 H.245 제어 채널 통신에 포함될 수 있다.
·상기 호출 터미널 1은 H.245 제어 채널을 위하여 신뢰할 수 있는 접속을 설정하고 능력 교환, 모드 선택 등과 같은 H.245 절차가 실행된다.
·상기 capabilities 교환 후에, H.245 절차는 다양한 미디어 흐름을 위하여 논리 채널을 설정하는 데에 사용될 수 있다.
·상기 capabilities 교환은 또한 다양한 미디어 흐름의 이송을 위하여 동적 포트 어드레스의 착신을 포함한다.
·상기 미디어 흐름은 상기 다양한 논리 채널에서 동적 포트를 통하여 이송된다.
·일단 상기 터미널이 영상 메일을 끝마치면, 상기 영상 흐름의 전송을 종료한 후 상기 터미널은 영상을 위한 논리 채널을 폐쇄한다.
·데이터 전송은 종료되고, 데이터를 위한 논리채널은 폐쇄된다.
·음성 전송은 종료되고, 음성을 위한 논리채널은 폐쇄된다.
·H.245 호출, 삭제 메시지는 피어 엔터티(peer entity)로 송신된다.
·호출 터미널 1은 H.225 포트 상에서 단절 메시지를 게이트키퍼 7로 전송하고 상기 게이트키퍼는 차례로 상기 단절 메시지를 영상 메일 서버 6에 송신한다.
· 단절 메시지는 수신 통지되고 상기 호출은 단절된다.
·셋업 요청이 성공하면, 피호출 터미널 8은 H.245 접속을 위한 신뢰할 수 있는 포트 어드레스를 포함하는 접속 메시지로 응답한다.
·상기 게이트키퍼4는 상기 H.245 제어 채널 통신을 위하여 상기 포트 어드레스를 따라서 접속 메시지로 상기 호출 터미널 1에 응답한다.
·호출 터미널 1은 상기 게이트웨이 4와 H.225 호출 제어 시그널링을 위한 접속을 셋업하고 H.245 제어 채널 통신을 위하여 또 다른 접속을 설정하고 상기 게이트웨이 4에 접속 수신통지 메시지로 응답한다.
·상기 게이트키퍼4는 차례로 피호출 터미널8에 접속 수신통지 메시지를 송신한다.
·피호출 터미널8은 H.225 호출 제어 접속을 지금 셋업하고 또한 제어 채널 통신을 위하여 상기 게이트키퍼 4와 H.245를 위한 또 다른 접속을 설정한다.
·신뢰할 수 있는 통신을 위하여 H.245 제어 채널을 설정하는 상기 터미널을 capabilities 및 H.245의 다른 개시 절차를 교환하고 음성 채널은 상기 capabilities 교환 전에 선택적으로 개방될 수 있다.
·capabilities 교환에 후속하는 동적 포트를 통한 논리 채널은 각 미디어 흐름을 위하여 설정된다.
·일단 미디어 논리채널이 동적 포트를 통하여 개방되면 미디어 정보는 교환될 수 있다.
·상기 세션 도중에 H.245 제어 절차는 모드 제어, 능력 등과 같은 채널 구조를 변경하기 위하여 불러내어질 수 있다.
·또한 H.225 제어 채널은 호출 상태, 대역 폭 할당 등을 포함하는 상기 게이트키퍼[4]에 의하여 요청된 것과 같은 특정 절차를 위해 존재한다.
·종료를 위하여 어느 한쪽 터미널은 종료 영상 메시지를 시작하고 영상 전송을 중단하고 그리고 나서 영상을 위한 논리채널을 폐쇄할 수 있다;
·데이터 전송은 중단되고 데이터를 위한 논리 채널은 폐쇄된다;
·음성 전송은 중단되고 음성을 위한 논리 채널은 폐쇄된다;
· H.245 엔드 세션 메시지는 송신되고 제어 채널 상의 전송은 종료되고 상기 제어 채널은 폐쇄된다;
·상기 엔드 세션 메시지를 수신하는 터미널은 폐쇄 절차를 반복할 수 있고 그리고 나서 H.225 호출 시그널링 채널은 호출 삭제를 위하여 사용된다; 그리고
·상기 종료를 개시하는 터미널은 H.225 제어 채널 상에서 단절 메시지를 상기 게이트키퍼 4에 송신할 수 있는데, 상기 게이트키퍼 4는 차례로 단절 메시지를 peer 터미널로 송신한다.
상기 peer 터미널은 상기 개시 터미널로 전달되는 단절을 수신 통지하고 상기 호출은 결국은 복구된다.
b) 경우 2: H.320 터미널에 대한 H.323 터미널
H.323 터미널 1로부터 개시된 호출은 MCI 교환네트워크를 통하여 H.320 터미널 9로의 호출을 불러일으킨다. 상기 게이트웨이와 함께 상기 게이트키퍼는 호출 설정 및 호출 제어를 포함하는 세션을 제어하는데 불려내어진다. 터미널 최종-사용자 인터페이스는 어떠한 상업적 사용 가능한 웹-브라우저 또는 유사한 인터페이스이다.
상기 호출 흐름은 게이트웨이 4 구성 요소가 상기 게이트키퍼 4와 피호출 터미널 9 사이에서 도입된다는 점을 제외하고 전술한 케이스에서 설명된 또 다른 H.323 터미널을 호출하는 H.323 터미널과 유사하다. 상기 게이트웨이는 음성, 비디오, 데이터 및 제어를 포함하는 H.323 메시지를 H.320 메시지로 트랜스코드(transcode)하고 그 반대 행위를 한다. 상기 H.320 터미널 9가 H.323 터미널 [1]로의 호출을 개시하면, 상기 개시 다이얼-업 루트는 상기 게이트웨이에 의하여 실행되고 그리고 나서 상기 게이트키퍼는 상기 호출 제어를 인계하고 상기 호출은 앞선 케이스에서 기술된 바와 같이 진행한다.
c) 경우 3: H.324 터미널에 대한 H.323 터미널
H.323 터미널 1을 개시하는 호출은 MCI 교환네트워크를 통하여 H.324 터미널 10으로의 호출을 개시한다. 상기 게이트웨이와 함께 상기 게이트키퍼는 호출 설정 및 호출 제어를 포함하는 세션을 제어하는데 포함된다. 터미널 최종-사용자 인터페이스는 웹-브라우저 또는 유사한 인터페이스이다.
상기 호출 흐름은 게이트웨이 4 구성 요소가 상기 게이트키퍼 4와 피호출 터미널 9 사이에서 도입된다는 점을 제외하고 앞선 케이스에서 기술된 바와 같이 또 다른 H.323 터미널을 호출하는 H.323 터미널과 유사하다.
상기 게이트웨이 4는 음성, 영상, 데이터 및 제어를 포함하는 H.323 메시지를 H.324 메시지로 트랜스코드하고 그 역행을 한다.
상기 H.324 터미널 10이 H.323 터미널 1로의 호출을 개시하면, 개시 다이얼-업 루틴이 상기 게이트웨이에 의하여 실행되고 그리고 나서 상기 게이트키퍼는 상기 호출 제어를 인계하고 앞선 케이스에서 기술된 바와 같이 상기 호출은 진행된다.
2. 멀티 포인트 영상-회의 호출
멀티 포인트 영상-회의의 경우에 있어 모든 터미널은 상기 게이트키퍼 4와 개시 호출 시그널링 및 셋업 메시지를 교환하며 그리고 나서 게이트키퍼 4를 통하여 H.245 제어 채널 메시징을 포함하는 실제 회의를 위한 멀티 포인트 제어기에 접속된다.
다음은 회의를 셋업 하는데 고려하여야 할 사항이다.
·개시 허가 제어 메시지 교환후, 사용자에게는 회의 형식 및 참가자들의 동적 리스트에 관한 정보를 가진 웹 페이지가 제공된다.
·나중에 참가한 참가자에게는 회의 정보를 가진 웹 페이지가 제공되며 또한 확인 정보를 입력하는 것이 요구된다.
·모든 사용자는 상기 게이트키퍼 [4]를 통하여 상기 멀티포인트 제어기 [4]로 접속된다.
·상기 멀티포인트 제어기 [4]는 다양한 참가자들 사이에서 정보를 분배한다.
E. 결론
상기 영상-회의 구조는 실-시간 음성, 영상 및 데이터 또는 포인트-투-포인트 전화를 포함하는 어떠한 조합을 포함하는 멀티미디어 통신에 대한 전체적 해결책이다. 상기 구조는 ITU 권고 안을 이용하는 다른 시스템과의 상호작용을 규정한다.
디렉토리 서비스 및 영상 메일 서비스를 포함하는 또 다른 서비스는 또한 총체적 구조의 일 부를 이룬다.
XV. 영상 축적 및 전달 구조
상기 영상 축적 및 전달 구조는 주문-영상 컨텐트 전달 시스템을 기술한다. 상기 컨텐트는 영상 및 음성 또는 음성만을 포함할 수 있다. 상기 컨텐트를 위한 입력 신호원은 현재의 영상-회의 설비로부터 또는 어떠한 영상/음성 신호원로부터 존재한다. 입력 영상은 ITU H.320, ITU H.324, ITU H.263 또는 MPEG와 같은 다양한 표준 형식으로 디지털 라이브러리에 저장되며 요구되는 형식으로 클라이언트에게 전달된다. 전달은 인터넷 상에서 또는 ISDN을 포함하는 다이얼-업 라인 상에서 상기 클라이언트에게로 다양한 스피드로 행해지고 각 다른 형식을 위한 단일 저장으로 행해진다.
A. 특징
상기 영상 저장 및 전달 구조는 다음을 포함하는 풍부한 일련의 특징 및 기능을 가지도록 설계된다.
·주문 음성 및 영상의 전달;
·IP(인터넷 프로토콜) 및 RTP(실 시간 이송 프로토콜) 양자상의 ITU H.320, ITU H.324, MPEG 및 ITU H.263을 포함하는 다양한 압축 및 전송 표준의 지원;
·다이얼-업 ISDN 라인 및 저 스피드(28.8kbps) 아날로그 전화 라인에 의한 인터넷 상의 컨텐트 전달의 지원;
·컨텐트의 단일 신호원과 다중 저장과 전달 형식과 다중 전달 스피드의 지원; 그리고
·다중 형식으로의 컨텐트 관리 및 보관의 지원;
B. 구조
도 19는 바람직한 실시 예에 따른 영상 축적 및 전달 구조를 나타낸다.
C. 구성 요소
영상 축적 및 전달 구조는 다음의 구성 요소에 의하여 완전히 기술된다.
·컨텐트 생성 및 트랜스코딩.
·컨텐트 관리 및 전달.
·컨텐트 검색 및 디스플레이.
1 컨텐트 생성 및 트랜스코딩
입력 신호원은 아날로그 영상, 멀티-포인트 제어 유닛(MCU)으로부터의 영상 및 다른 영상 신호원 1a 및 1b를 포함한다. 입력 컨텐트는 ITU H.261, ITU H.263,ITU H.320, ITU H.263, ITU H.324, MPEG 및 또한 RTP를 통한 H.263 및 인터넷 프로토콜 2 및 3을 통한 H.263의 전달을 지원하는 형식과 같은 표준 형식으로 변환된다. 입력은 최초에 H.263으로 코드 부여되고 선택적으로 다양한 다른 형식으로 트랜스코드되고 2에 저장될 수 있다. 상기의 트랜스코드된 컨텐트는 다른 서버 상에 저장되는데, 다양한 클라이언트에 서비스하는 각 컨텐트 형식을 위한 서버는 각각 다른 형식 5a, 5b,5c, 5d 및 5f를 지원한다.
2 컨텐트 관리 및 전달
컨텐트는 다양한 서버에 저장되는데 각 서버는 특정 포맷을 지원하고, 상기 컨텐트는 다음으로 구성되는 디지털 라이브러리에 의하여 관리된다.
- 인덱스 관리 및 컨텐트 보관을 위한 인덱스 서버 4
-컨텐트 저장을 위한 오브젝트 서버 5a, 5b, 5c, 5d, 5e 및 5f
-상기 인덱스 및 오브젝트 서버로의 전위(front end)로서 그리고 컨텐트를 요구하는 다른 클라이언트와 상호 작용하는 Proxy Client 6.
컨텐트 전달은 다음에 의하여 이루어진다:
-인터넷
-다이얼-업 ISDN 회선
- 28.8kbps에 있는 다이얼-업 아날로그 전화 라인, 그리고
컨텐트 포맷은 IP 또는 RTP를 통하여 이송된 MPEG 흐름, H.320 흐름, H.324 흐름 또는 H.263 흐름 중 어느 하나이다.
3. 컨텐트 검색 및 디스플레이
컨텐트 검색은 다양한 포맷을 지원하는 다음과 같은 클라이언트에 의하여 이루어진다.
- MPEG 클라이언트 -7a;
- RTP를 지원하는 ITU H.263 클라이언트-7b;
-IP를 지원하는 ITU H.263 클라이언트-7c;
-ITU H.320 클라이언트-7d; 그리고
-ITU H.324 클라이언트-7e
컨텐트는 요구가 있는 즉시 다양한 클라이언트에 의하여 검색되고 로컬 디스플레이 상에 디스플레이 된다.
클라이언트는 패스트-포워드(fast-forward), 리-외인드(re-wind)등과 같은 기능과 같은 VCR을 지원한다.
D 개요
다양한 신호원로부터의 아날로그 영상 및 MCU로부터의 H.320 영상은 입력으로서 수신되고 ITU H.324, ITU H.261, ITU H.263 또는 MPEG와 같은 요구되는 다양한 포맷으로 트랜스코드되고 각 포맷을 위하여 제공된 다양한 오브젝트 서버 상에 저장된다. 상기 오브젝트 서버는 차례로 상기 인덱스 서버에 의하여 관리되고 함께 디지털 라이브러리에 호출된다. 컨텐트에 대한 클라이언트로부터의 어떠한 요청도 상기 인덱스 서버에 의하여 수신되고 차례로 Proxy 클라이언트를 통하여 상기 오브젝트 서버에 의하여 서비스된다.
상기 인덱스 서버 또는 상기 라이브러리 서버는 상기 proxy 클라이언트 및 스토어로부터의 요청에 응답하고 상기 오브젝트 서버 상에서 H.261, H.263 또는 MPEG 멀티미디어 정보와 같은 오브젝트를 갱신하고 검색한다. 그리고 나서 상기 서버들은 다시 대리 클라이언트로 검색 정보를 전달하기 위하여 상기 오브젝트 서버를 감독한다. 상기 인덱스 서버는 오브젝트 서버 상에 저장된 다양한 모든 오브젝트의 완전한 인덱스 정보를 가지며 또한 정보가 위치하고 있는 오브젝트 서버의 정보를 가지고 있다. 상기 인덱스 서버 상에서 사용할 수 있는 상기 인덱스 정보는 다양한 오브젝트 서버로부터 멀티미디어 컨텐트의 검색을 위하여 상기 대리 클라이언트에 의하여 접근할 수 있다. 보안 및 액세스 제어는 또한 인덱스 서버 기능의 일부를 이루고 있다.
상기 오브젝트 서버는 회의 설비로부터의 영상-회의 정보를 포함하는 멀티미디어 컨텐트에 대한 기억 장치로서 실행되고 물리적 저장을 제공하는 디지털 라이브러리의 필수 구성 요소를 이룬다. 상기 멀티미디어 컨텐트는 요구가 있는 즉시 상기 대리 클라이언트에 의하여 검색될 수 있는 표준 포맷에 저장된다. 각 오브젝트 서버는 H.261, H.263, MPEG등과 같이 멀티미디어 컨텐트의 특정 포맷을 위하여 제공된다. 멀티미디어 포맷을 위하여 제공된 특정 오브젝트 서버에 관한 정보를 포함하는 멀티미디어 컨텐트의 조직 및 인덱스 정보는 인덱스 서버에 의하여 관리된다. 상기 오브젝트 서버는 상기 인덱스 서버로부터 특정 명령을 수신하는 것과 동시에 상기 대리 클라이언트로 저장된 멀티미디어 컨텐트를 전달한다.
상기 대리 클라이언트는 상기 디지털 라이브러리의 front end이고 주문 멀티미디어 컨텐트를 위하여 인터넷을 통하여 모든 클라이언트에 의하여 액세스된다. 상기 대리 클라이언트는 World Wide Web(WWW) 서버이고 액세스될 때 상기 클라이언트로 페이지를 전달한다. 상기 클라이언트는 상기 대리 클라이언트가 상호작용하고 그것에 의하여 상기 WWW 페이지를 통하여 디지털 라이브러리와 상호 작용한다. 클라이언트는 상기 WWW 페이지와의 상호작용에 의하여 멀티미디어 컨텐트를 요청한다. 상기 대리 클라이언트는 상기 WWW 페이지를 통하여 상기 클라이언트로부터 요청을 수신하고 상기 요청을 처리한다. 상기 대리 클라이언트는 그리고 나서 상기 클라이언트에 의하여 요청된 바와 같이 오브젝트 문의에 대하여 상기 인덱스 서버와 통신한다. 상기 인덱스 서버는 그리고 나서 요청된 멀티미디어 포맷으로 제공되는 상기 오브젝트 서버중 하나와 통신하고 상기 인덱스 서버에서 사용될 수 있는 인덱스 정보에 근거를 두면서 상기 대리 클라이언트로 요청된 멀티미디어 컨텐트를 전달하도록 상기 오브젝트 서버에 명령한다. 상기 대리 클라이언트는 상기 오브젝트 서버로부터 멀티미디어 컨텐트를 수신하고 그것을 상기 요청을 만드는 클라이언트에 전달한다.
상기 클라이언트는 요청되는 영상 포맷 및 클라이언트 capabilities에 의존하는 28.8 Kbps에서의 ISDN 라인 또는 아날로그 라인 상에서의 다이얼-업 접속 또는 인터넷 어느 하나를 통하여 상기 서버에 접속한다. H.320 클라이언트를 ISDN 라인에 의하여 접수되며 H.324 클라이언트는 28.8 Kbps로 아날로그 전화 상에 서비스를 요청한다. MPEG 클라이언트 또는 RTP을 사용하는 H.263 클라이언트 또는 IP를 사용하는 H.263 클라이언트는 인터넷을 통하여 서비스를 요청한다. WWW 브라우저와 같은 멀티미디어 컨텐트 문의 및 디스플레이를 위한 전위는 클라이언트의 일부로서 통합되고 최종 사용자에게 사용하기 용이한 인터페이스를 제공한다.
상기 클라이언트로부터의 영상에 대한 요청은 상기 요청을 경로 인덱스 서버로 경로 지정하는 대리 클라이언트에 의하여 수신되는데 상기 인덱스 서버는 차례로 상기 요청을 처리하고 전달을 위하여 상기 컨텐트에 인덱스 하는 것에 더하여 특정 오브젝트 서버와 통신한다. 상기 오브젝트 서버는 인터넷을 통하여 상기 클라이언트에게로 요청된 컨텐트를 전달한다. 다이얼-업 링크의 경우에 상기 컨텐트는 기-설정된 링크 상에 다시 전달된다.
요컨대, 상기 영상 축적 및 전달 구조는 영상 및 음성 또는 주문 음성 생성, 트랜스코딩, 저장, 보관 관리 및 전달에 대한 포괄적인 시스템을 기술한다. 영상 및 음성 또는 음성의 전달은 인터넷 상 또는 ISDN 또는 아날로그 전화 다이얼-업 라인에 의하여 이루어진다. 영상 및 음성 또는 음성을 포함하는 컨텐트는 각각 다양한 전달 스피드를 서비스하는 각각의 저장 로케이션으로부터의 다양한 데이터 율로 전달된다.
XVI. 영상 오퍼레이터
A. 하드웨어 구조
도 96은 영상 오퍼레이터가 영상 회의 또는 영상 호출에 참가하는 것을 허용하고 영상 호출자에 다수의 서비스를 제공하는 시스템 하드웨어를 보여준다. 제공된 서비스는 다음을 포함한다: 입력 영상 호출에 대한 응답 또는 커스터머 사이트로의 다이얼 호출; 영상 회의 스케줄을 유지하고 Bandwidth an Demand Interoperability Group ("BONDING")호출 또는 Telecommunication Union-Telecommunication Standardization Sector ("ITU-T") Standard H.320 Multi-rate Bearer Service (MRBS) Integrated Services Digital Network ("ISDN") 호출을 사용하는 호출자를 영상 회의 또는 영상호출에게로 연결하기 위한 시스템으로의 액세스; 어떠한 영상 회의 또는 영상 호출의 모니터, 뷰. 및 기록; 기 기록된 영상 회의 또는 영상 호출의 재생; 그리고 영상 회의 또는 영상 호출 중에 영상 회의로부터의 문의에 응답 또는 원조를 제공하는 것.
상기 시스템 하드웨어는 영상 오퍼레이터 터미널 40001, 호출 서버 40002, 멀티미디어 허브("MM Hub") 40003, 광역네트워크 허브("WAN Hubs") 40004, 멀티 포인트 회의 유닛("MCU") 40005, BONDING 서버 40006, 클라이언트 터미널 40007 및 교환 네트워크 ("MCI") 40008로 이루어진다.
일 실시 예에서는 상기 영상 오퍼레이터 터미널 40001은 처리속도 90MHZ 또는 그 이상, 32 MB 램 및 적어도 1.0 GB 저장공간을 가진 하드디스크 드라이브를 가진 펜티엄급 퍼스널 컴퓨터이다. 상기 실시 예에 따른 오퍼레이팅 시스템은 Microsoft사의 Window 95이다. 특별한 특징은 Incite Multimedia Communications Program ("MCP") 소프트웨어, 음성 및 영상 압축을 위한 H.320 영상 코더/디코더 ("코덱")카드 (예를 들면 Zydacron의 Z240 코덱) 및 동기(isochronous) Ethernet ("isoEthernet")네트워크 인터페이스 카드를 포함한다. Incite's MCP는 영상 신호의 전송을 위한 등시성 채널에 96 ISDN B-채널에 상당하는 것을 생성하기 위하여 isoEthernet 네트워크 카드를 관리한다.
상기 실시 예에서의 호출 서버 40002는 처리속도 90MHZ 또는 그 이상, 32 MB RAM 및 적어도 1.0 GB 저장 공간을 가진 하드디스크 드라이브를 가진 펜티엄급 퍼스널 컴퓨터이다. 오퍼레이팅 시스템은 마이크로 소프트사의 Windows NT 서버이다. 특별한 특징은 Incite Call Server 서비스 및 Ethernet 네트워크 인터페이스 카드를 포함한다.
본 시스템의 또 다른 실시 예는 어떠한 MM 허브 40003 모뎀 및 어떠한 WAN 허브 40004 모뎀에 적당하다. 일 실시 예에서는 상기 MM 허브 40003은 Incite Multimedia 허브 이고 WAN 허브는 Incite WAN 허브이다. 상기 MM 허브 40003은 isoEthernet 인터페이스에 96 풀-듀플렉스(full-duplex) B-채널로 구성되는 대역폭을 지원하는 다수의 포트를 통하여 영상 오퍼레이터 터미널 40001 및 BONDING 서버 40006과 같은 퍼스널 컴퓨터 또는 WAN 허브 4004 또는 다른 직렬 MM 허브에 접속하는 local area 네트워크("LAN") 허브이다. 또한 상기 MM 허브 40003은 호출 서버 40002로부터의 Ethernet 인터페이스와 같은 Ethernet 인터페이스를 통하여 10 Mbps의 Ethernet data까지 용인할 수 있다. 상기 WAN 허브 40004는 MM 허브 40003 및 MCI 40008과 같은 전용 또는 공용 교환 네트워크 사이에서 인터페이스로서 작용하는데, 영상 회의가 상기 MM 허브 40003 및 WAN 허브 40004를 포함하는 LAN 또는 WAN을 넘어 확장되는 것을 가능하게 한다.
상기 시스템의 다른 실시 예들은 다양한 제조자들의 MCU 40005 디바이스에 적합하다. MCU 40005의 기능은 단일의 영상 회의에서 상호 통신하기 위하여 영상 회의 호출자들이 다양한 다른 디바이스를 사용하고, 가능하면 다른 회선에 근거한 디지털 네트워크를 통하여 통신하는 것을 허용하는 것이다. 예를 들면 일실시 예는 영상 Server Multimedia 회의 Server ("MCS")를 채용하는데, 이것은 영상 회의 호출자 누구라도 완전한 영상 회의 토론을 청취하게 할 수 있게 하기 위하여 음성을 혼합하고 각 영상 회의 호출자가 동시에 다른 모든 호출자를 볼 수 있도록 영상을 처리한다.
일 실시 예에서는 상기 BONDING 서버 40006은 처리 속도 90MHZ 또는 그 이상, 32MB RAM 및 적어도 1.0GB 저장 공간을 가진 하드디스크 드라이브를 가진 펜티엄급 퍼스널 컴퓨터이다. 상기 실시 예에 있어서 오퍼레이팅 시스템은 Microsoft사의 Window 95이다. 특이할만한 기능은 Incite BONDING 서버 소프트웨어, 디지털 신호 프로세서 ("DSP") 카드 (텍사스 인스트루먼트사의 "TMS320C80" DSP와 같은) 및 isoEthernet 네트워크 인터페이스 카드를 포함한다. 클라이언트 터미널 40007이 BONDING 또는 Aggregated 영상 호출을 만드는 곳에서, 상기 BONDING 서버 40006은 상기 호출을 영상 오퍼레이터 플랫포옴 내에서 사용되는 멀티-rate ISDN 호출로 변환한다.
바람직한 실시 예에 있어서는, 클라이언트 터미널은 처리 속도 90MHZ 또는 그 이상, 32 MB RAM 그리고 적어도 1.0GB 저장 공간을 가진 하드디스크 드라이브를 가진 펜티엄급 퍼스널 컴퓨터이다. 오퍼레이팅 시스템은 상기 실시 예에서는 Microsoft사의 Window 95이다. 클라이언트 터미널 40007은 ITU-T 표준 H.320에 적합하게 하는 음성 및 영상 설비를 구비하고 있다.
상기 실시 예에서, 교환 네트워크는 MCI 40008에 의하여 제공되는 통합 서비스 디지털 인터넷("ISDN")이다.
상기 영상 오퍼레이터 터미널 40001은 96 full-duplex B-channels의 대역폭을 가진 isoethernet 인터페이스를 통하여 MM 허브 40003에 접속되는데, 상기 인터페이스는 각 영상 오퍼레이터가 8명의 영상 회의 클라이언트까지 관리하게 할 수 있으며 한편 각 클라이언트는 클라이언트 터미널 40007을 채용한다. 상기 MM 허브 40003은 유사한 isoEthernet local area 네트워크("LAN") 접속을 통하여 WAN 허브 40004에 접속된다. 하나의 WAN 허브 40004는 multi-rate ISDN 인터페이스에 의하여 MCI 40008을 통하여 MCU 40005에 접속된다. 또 다른 WAN 허브 40004는 multi-rate ISDN 인터페이스에 의하여 MCI 40008에 접속되고 MCI는 BONDING 또는 multi-rate ISDN 인터페이스에 의하여 각 클라이언트 터미널 40007에 접속된다. 세 가지 방식 접속에서, 상기 MCU 40005, 상기 호출 서버 40002 및 상기 MM 허브 40003은 Ethernet 광역네트워크("WAN") 40009를 통하여 상호 접속된다. 상기 MM 허브 40003은 full "iso" 모드에서 248 B-channel의 대역폭을 가진 isoEthernet 인터페이스를 통하여 BONDING 서버 40006에 또한 접속된다.
B 영상 오퍼레이터 콘솔
도 97은 영상 오퍼레이터가 영상 회의 호출을 관리하게 할 수 있게 하는 시스템의 일실시 예를 보여주는데, 그것은 영상 오퍼레이터 콘솔 시스템 40101과 40117을 통한 외부 시스템 및 인터페이스 40108을 포함한다.
상기 영상 오퍼레이터 콘솔 시스템 40101은 화상 사용자 인터페이스 ("GUI") 40102, 소프트웨어 시스템 40103 및 미디어 콘솔 시스템 40107로 구성된다. 상기 GUI 40102는 비디오 오퍼레이터가 상기 영상 콘솔 시스템 40101을 사용하는 영상 오퍼레이터 터미널 [도 96의 40001]로부터 영상 오퍼레이터 발명의 모든 기능을 실행하게 할 수 있게 하기 위하여 소프트웨어 시스템 40103 및 미디어 제어 시스템 40107 양자와 상호 작용한다.
상기 소프트웨어 시스템 40103은 다음과 같은 시스템을 실행한다: 상기 영상 오퍼레이터의 스케줄을 관리하는 스케줄 시스템 40104; 어떠한 호출로부터의 음성 및 영상 입력을 기록하고 어떠한 호출을 통한 음성 및 영상 입력을 재생하는 기록 및 재생 시스템 40105; 다이얼 및 보류와 같은 교환 기능을 실행함으로써 개별 호출을 관리하기 위하여 Incite MCP 어플리케이션과의 어플리케이션 프로그램 인터페이스로 작용하는 호출 시스템 인터페이스 40106.
상기 스케쥴링 시스템 40104는 개방형 데이터베이스 연결성 ("ODBC") 인터페이스 40108을 통하여 Video Operator Shared Data base 40111에 접속되는데, 상기 데이터 베이스 40111은 차례로 VOSD 및 VRS 40114 사이의 인터페이스를 통하여 영상회의 예약 시스템 ("VRS")40115에 접속된다. 상기 VRS 40115는 상기 영상 Operator Shared Database 40111내의 데이터베이스 에이전트 시스템에 의하여 일반 원칙에 따라 또는 요구가 있는 즉시 상기 인터페이스 40114를 통하여 상기 영상 Operator Shared Database 40111에 영상 회의 스케줄 회의 규정 및 사이트 규정을 제출한다. 상기 영상 오퍼레이터 공용 데이터 베이스 40111은 바람직한 실시 예에서 상기 영상 오퍼레이터 콘솔 40101을 포함하는 컴퓨터와는 다른 컴퓨터에 위치하는데, 상기 데이터 베이스 40111은 모든 회의 및 사이트 정보를 저장하며 따라서 어떠한 영상회의 호출을 위하여 필요한 회의 및 사이트 구성배치를 검색할 수 있다. 내부의 스케쥴링 시스템 40104와 연관된 외부시스템의 대체 실시 예에서는 영상 오퍼레이터 공유 데이터베이스 40111 및 VRS 40115는 단일 시스템으로 통합될 수 있다.
상기 기록 및 재생 시스템 40105는 영상 오퍼레이터 터미널 [도 96의 40007]에 국부적으로 위치한 영상 오퍼레이터 저장 및 재생 시스템 40112와 동적 데이터 교환("DDE"), 오브젝트 링킹 및 Embedding ("OLE") 또는 동적 링크 라이브러리("DLL") 인터페이스 40109를 통하여 통신한다. 상기 영상 오퍼레이터 및 재생 시스템은 ITU-T 표준 H.320을 따르는 단-방향 기록 디바이스 40116 및 ITU-T 표준 H.320을 따르는 단-방향 재생 디바이스 40117로 구성된다. 회의 호출은 디지트 화된 음성 및 영상 신호를 상기 영상 오퍼레이터 콘솔 40101로부터 H.320 recorder 40116으로 전송함으로써 기록된다. 회의 호출은 기 기록된 회의 호출을 디스크 기억 장치로부터 검색하고 음성 및 영상 신호를 H.320 재생 디바이스 40117로부터 영상 오퍼레이터 콘솔로 전송함으로써 재생된다.
상기 호출 시스템 인터페이스 시스템 40106은 다이얼 보류 등과 같은 교환 기능을 관리하기 위하여 DDE 인터페이스 40110을 통하여 Incite MCP 어플리케이션 40113과 통신한다.
미디어 제어 시스템 40107은 상기 GUI 40102가 음성 및 영상의 GUI 40102 화상을 관리하기 위하여 직접적으로 외부 구성 요소와 통신하는 것을 허용한다. 도 401에서 볼 수 있는 실시 예에서는 상기 미디어 제어 시스템 40107은 DDE 인터페이스 40110을 통하여 Incite MCP 어플리케이션 40113과 통신한다. 상기 Incite MCP 어플리케이션 40113은 영상 윈도우 placement 및 음성 제어와 같은 필요한 모든 호출 셋업 특징 및 멀티미디어 특징을 DDE 인터페이스 40110을 통하여 내부 및 멀티미디어 특징을 DDE 인터페이스 40110을 통하여 내부 미디어 제어 시스템 40107 그리고 GUI 40102로 제공한다.
도 98은 영상 오퍼레이터가 영상 회의 호출을 관리하는 것을 가능하게 하기 위한 시스템의 두 번째 실시 예를 보여주는데 그것은 영상 오퍼레이터 콘솔 시스템 40101과 40117을 통한 외부 시스템 및 인터페이스 40108과 40216을 통한 외부 시스템 및 인터페이스 40203을 포함한다. 상기 실시 예에서는 그러나 소프트웨어 시스템 40103이 영상 서버의 "MCS" 40215 MCU 뿐 아니라 다른 제조자의 MCU 어플리케이션에도 적합하다. 따라서 도 98에는 내부 소프트웨어 시스템 MCU 제어 40201, 외부 소프트웨어 시스템 MCU 제어 시스템 40208, MCU 자신 40214 및 40215와 그들 사이의 인터페이스 40206, 40210 및 40211이 나타나 있다. 또한 상기 Incite MCP 40113 어플리케이션 뿐 아니라 "호출 제어 인터페이스를 가진 다른 프로그램" 40216이 상기 실시 예에서 필요한 호출 셋업 및 멀티미디어 특징을 제공할 수 있기 때문에 외부 호출 제어 시스템 40209는 중계 DDE, OLE 도는 DLL 인터페이스 40207, 40212 및 40213과 마찬가지로 요구된다. 상기 실시 예는 또한 영상 축적 및 전달 시스템 40204와 그것의 DDE, OLE 또는 DLL 인터페이스 40203을 포함한다. 결국은 상기 두 번째 실시 예는 상기 내부 소프트웨어 시스템 호출 모니터 40202를 추가한다.
첫 번째 실시 예와 같이 상기 영상 오퍼레이터 콘솔 시스템 40101은 GUI 40102 및 소프트웨어 시스템 40103으로 구성된다. 그러나 상기 스케쥴링 시스템 40104, 상기 기록 및 재생 시스템 40105 및 상기 호출 시스템 인터페이스에 더하여, 두 번째 실시 예의 소프트웨어는 MCU 제어 40201 및 호출 모니터 40202를 포함한다.
상기 스케쥴링 시스템 40104와 관련 외부 시스템 40108, 40111, 40114 및 40115는 도 97에서 도시되고 전술된 첫 번째 실시 예의 그것과 동일하다.
상기 내부 MCU 제어 40201은 다양한 다른 MCU 시스템에 특유한 resource 및 특징을 관리하기 위하여 DDE, OLE 또는 DLL 인터페이스 40206을 통하여 외부 MCU 제어 시스템 40208과 통신한다 상기 MCU 제어 시스템 40208 Conference Talk interface 40211을 통하여 영상 서버 MCS 4025와 통신하거나 다른 vendor-specific 인터페이스 40210을 통하여 어떠한 다른 MCU vendor's MCU 40214와 통신하거나 한다.
상기 기록 및 재생 시스템 40105는 DDE, OLE 또는 DLL 인터페이스 40109, 40203을 통하여 저장 및 검색 시스템 40205 및 영상 축적 및 전달 시스템 40204와 통신한다. 상기 저장 및 검색 시스템 40205 및 영상 축적 및 전달 시스템 40204는 또 다른 DDE, OLE 또는 DLL 인터페이스 40207을 통하여 호출 제어 시스템 40209와 통신한다. 상기 호출 제어 시스템 40209는 또 다른 DDE, OLE 또는 DLL 인터페이스 40212를 통하여 단-방향 H.320 recorder 40116 및 단-방향 H.320 재생 디바이스 40117과 통신한다 회의 호출은 디지트 화된 음성 및 영상 신호를 영상 오퍼레이터 콘솔 40101로부터 저장 및 검색 시스템 40205 및 호출 제어 시스템 40209를 통하여 H.320 recorder 40116으로 전송함으로써 기록된다. 회의 호출은 기 기록된 회의 호출을 디스크 기억 장치로부터 검색하고 상기 음성 및 영상 신호를 상기 H.320 재생 디바이스 40117로부터 상기 호출 제어 시스템 40209 및 저장 및 검색 시스템 40205를 통하여 영상 오퍼레이터 콘솔 40101로 전송함으로써 재생된다. 상기 영상 축적 및 전달 시스템 40204는 기록 및 재생 시스템 40105 및 호출 제어 시스템 40209 사이에서 통신하며 상기 저장 및 검색 시스템 40205와 유사한 방식으로 작동된다.
호출 모니터 40202는 영상 오퍼레이터 콘솔 소프트웨어 시스템 40103 내에서 상기 호출 시스템 인터페이스 40106을 전기적으로 폴 함으로써 호출 및 접속 상태를 검사한다. 상기 호출 시스템 인터페이스 40106은 다이얼, 보류 등과 같은 교환 기능을 포함하는 호출 데이터를 관리하기 위하여 DDE, OLE 또는 DLL 인터페이스 40207을 통하여 상기 호출 제어 시스템 40209와 통신하며 상기 영상 오퍼레이터 콘솔 40101 내부 데이터 구조 및 상기 호출 제어 시스템 40209 데이터 사이에서 번역한다. 상기 호출 제어 시스템은 차례로 상기 Incite MCP 40113 또는 호출 제어 인터페이스를 가지는 다른 프로그램 40216 어느 하나를 관리한다.
미디어 제어 시스템 40107은 DDE, OLE 또는 DLL 인터페이스를 통하여 상기 호출 제어 시스템 40209와 통신하는데, 상기 호출 제어 시스템 40209는 DDE 인터페이스 40110을 통하여 Incite MCP 어플리케이션 40113 또는 호출 제어 인터페이스를 가진 다른 프로그램 40216과 통신한다. 상기 Incite MCP 어플리케이션 40113은 직접적으로 DDE 인터페이스 40110을 통하여 내부 미디어 제어 시스템 40102에로 또는 호출 제어 시스템 40209를 통하거나 하여 영상 윈도우 placement 및 음성 제어와 같은 필요한 호출 셋업 특징 및 멀티미디어 특징 모두를 제공한다. 호출 제어 인터페이스를 가진 다른 프로그램 40216이 호출 셋업 및 멀티미디어 특징을 제공하기 위하여 사용된다면, 그것들은 호출 제어 시스템 40209를 통하여 미디어 제어 시스템 40107과 통신한다.
C 영상 회의 호출 흐름
도 99는 영상 오퍼레이터에 의하여 개시된 영상 회의 호출이 도96에서 도시된 시스템을 통하여 어떻게 접속되는 가를 보여준다. 호출 흐름 경로 40301에서 도시된 첫 번째 단계에서는 영상 오퍼레이터가 영상 오퍼레이터 터미널 40001로부터 MM 허브 40003을 통하여 BONDING 서버 40006으로 호출을 개시하는데, 여기에서 상기 BONDING 서버 40006은 상기 호출을 BONDING 호출로 변환한다. 호출 흐름 경로 40302에서 도시된 두 번째 단계에서는 상기 BONDING 서버 40006은 상기 BONDING 호출을 다시 한번 MM 허브 40003을 통하고 WAN 허브 40004를 통하고 MCI 40008을 통하여 클라이언트 터미널 40007에 전송한다. 상기 단계는 영상회의에 참가할 각 클라이언트 터미널 40007을 위하여 반복된다. 호출 흐름 경로 40303에 도시된 세 번째 단계에서는 영상 오퍼레이터가 영상 오퍼레이터 터미널 40001로부터 상기 MM 허브 40003을 통하고 WAN 허브 40004를 통하고 MCI 40008을 통하여 MCU 40005로 호출을 개시한다. 호출 흐름 경로 40304로 도시된 네 번째 단계에서는 상기 영상 오퍼레이터는 클라이언트 터미널 40007 및 MCU 40005로의 접속을 bridge하기 위하여 영상 오퍼레이터 터미널 40001을 사용한다. 상기 영상 오퍼레이터가 클라이언트 터미널 40007에서 회의 호출 클라이언트를 호출하는 각 시간마다 특정 회의 사이트를 위한 MCU의 ANI가 회의 호출에 참가하는 각 클라이언트를 정확한 회의 사이트와 식별하기 위하여 Calling Party Field에서 넘겨진다. 상기 MCU가 호출되는 때, 상기 클라이언트의 ANI가 넘겨진다. 상기 MCU는 그리고 나서 각 호출을 위하여 정확한 회의 사이트를 식별할 수 있다.
대체 실시 예에서는 상기 클라이언트가 클라이언트 터미널 40007로부터 MCI 40005를 통하고 WAN 허브 40004를 통하고 MM 허브 40003을 통하고 BONDING 서버 40006을 통하고 다시 한 번 MM 허브 40003을 통하여 영상 오퍼레이터 터미널 40001로 BONDING 호출을 개시한다. 그리고 나서 상기 영상 오퍼레이터는 호출 흐름 40303에서 도시된 바와 같이 호출을 상기 MCU로 배치하고 마지막으로 호출 흐름 경로 40304에서 도시된 바와 같이 두 개의 호출을 bridge한다. 클라이언트-개시 call을 위한 정확한 회의 사이트를 결정하기 위하여 개시 클라이언트의 ANI는 접속이 영상 오퍼레이터에 의하여 이루어질 때 MCU로 넘겨진다.
회의 호출이 진행중일 때, 영상 오퍼레이터는 상기 영상 오퍼레이터 터미널 40001로부터 각 호출을 검사한다. 상기 영상 오퍼레이터의 기능은 회의 상태에 관하여 상기 클라이언트에게 알리기 위하여 어떠한 호출이 여전히 접속되어 있는지의 검사, 단절된 호출의 재접속, 새로운 클라이언트를 회의에 추가 또는 회의에 결합하는 것을 포함한다.
모든 호출이 회의를 종료하기 위하여 단절되며, 영상 오퍼레이터 공유 데이터베이스 [도 98의 40214]가 갱신된 회의 스케줄을 반영한다.
D. 영상 오퍼레이터 소프트웨어 시스템
1 클래스 계층구조 (Class Hierarchy)
도 100은 영상 오퍼레이터 소프트웨어 시스템 클래스에 대한 클래스 계층구조를 보여준다. Visual C++프로그래밍 언어를 사용하는 일실시 예에서는 Voobject 40401 클래스는 상기 Visual C++base class cobject으로부터 확장된다. Voobject 40401은 영상 오퍼레이터의 콘솔 시스템을 위한 내부 소프트웨어 시스템의 오브젝트의 모든 class에 상위 클래스이고 따라서 내부 소프트웨어 시스템의 모든 오브젝트는 Voobject 40401로부터 속성을 물려받는다.
Vooperator 40402는 하나의 VOSchedule 40403 Part-1 Class Object 및 하나의 VOUserpreferences 40404 Part-2 Class object와 관련된 어셈블리 클래스이고, 따라서 정확히 하나의 VOschedule 40403 object 및 정확히 하나의 VOUserPreference 40404 object는 각 VOOperator 40402 object와 연관되어 있다. VOSchedule 40403은 차례로 0 또 그 이상의 VOSchedulable 40405 Part-1 Class object와 관련된 어셈블리 클래스이고, 따라서 어떠한 수의 VOschedulable 40405 오브젝트도 각 VOSchedule 40403 오브젝트와 연관될 수 있다.
VOSchedulable 40405는 VOConference 40406 Subclass-1 및 VOPlayback Session 40407 Subclass-2에 대한 상위 클래스이며, 따라서 VOConference 40406오브젝트 및 VOPlaybackSession 40407 오브젝트는 VOSchedulable 40405 오브젝트로부터 속성을 물려받는다. VOConference 40406은 둘 또는 그 이상의 VOConnection 40412 Part-1 Class 오브젝트 및 0 또는 하나의 VOPlaybackCall 40415 Part-2 Class 오브젝트에 관련된 어셈블리 클래스이고, 따라서 최소 두 개의 VOConnection 40412 오브젝트 및 가능하면 하나의 VOPlaybackCall 40415 오브젝트가 각 VOConference 40406 오브젝트에 관련되어 있다. VOPlaybackSession 40407은 하나의 VOPlaybackCall 40415 Part-1 클래스 오브젝트와 관련된 어셈블리 클래스이고, 따라서 정확히 하나의 VOPlaybackCall 40415 오브젝트는 각 VOPlaybackSession 40407 오브젝트에 연관되어 있다.
VOCallObjMgr 40408은 0 또는 그 이상의 VOCall 40410 part-1 클래스 오브젝트에 대한 어셈블리 클래스이고, 따라서 어떠한 수의 VOCall 40410 오브젝트도 각 VOCallObjMgr 40480 오브젝트에 관련될 수 있다. 유사하게 VOConnObjMgr 40409는 0 또는 그 이상의 VOConnection 40412 part-1 클래스 오브젝트에 대한 어셈블리 클래스이고, 따라서 어떠한 수의 VOConnection 40412 오브젝트도 각 VOConnObjMgr 40409 오브젝트에 관련될 수 있다. VOConnection 40412는 두 개의 VOCall 40410 part-1 클래스 오브젝트에 대한 어셈블리 클래스이고 따라서 정확히 두 개의 VOCall 40410 오브젝트는 각 VOConnection 40412 오브젝트에 관련되어 있다. VOCall 40410은 VOPalybackCall 40415 서브 클래스-1에 대한 상위 클래스이고 따라서 VOPalybackCall 40415 오브젝트는 VOCall 40410 오브젝트로부터 속성을 물려받는다. VOCall 40410은 또한 두 개의 VOSite 40413 part-1 클래스 오브젝트와 관련된 어셈블리 클래스이고, 따라서 정확히 두 개의 VOSite 40413 오브젝트는 각 VOCall 40410 오브젝트에 관련되어 있다. 마지막으로 VOCall 40410 클래스 오브젝트는 VORecorder 40411 클래스 오브젝트를 사용한다.
VOSite 40413은 VOMcuPortSite 40417 서브클래스-1, VOParticipantSite 40418 서브클래스-2 및 VOOperatorSite 40419 서브클래스-3에 대한 상위 클래스이고, 따라서 VOMcuPortSite 40417 오브젝트, VOParticipantSite 40481 오브젝트 및 VOOperatorSite 40419 오브젝트는 VOSite 오브젝트로부터 속성을 물려받는다.
VOPlaybackCall 40415는 하나의 VOMovie 40416과 관련된 어셈블리 클래스이고, 따라서 정확히 하나의 VOMovie 40416 오브젝트는 각 VOPlaybackCall 40415 오브젝트와 관련된다. VOPlaybackCall 40415 클래스 오브젝트는 또한 VOPlay 40414 클래스 오브젝트를 사용한다.
VOMessage 40420 오브젝트는 내부 소프트웨어 시스템의 모든 오브젝트에 대한 상위 클래스인 VOObject 40401의 속성을 물려받은 것 이외에는 어떠한 관련도 갖지 않는다.
2. 클래스 및 오브젝트 상세
a) VOObject
모든 내부 소프트웨어 시스템 클래스는 다음의 베이스 클래스로부터 물려받는다. 상기 베이스 클래스는 비주얼 C++ 베이스 클래스 CObject부터 확장된다.
클래스 VOObject
베이스 클래스 CObject
전수 형식 public
프랜드 클래스 -
(1) 데이터 타입
enum senderType_e{SENDER_INTERNAL,SENDER_SCHEDUL,
SENDER_CONFERENCE,SENDER_CONNECTION,SENDER_CALL,
SENDER_TIMER};
enum messageType_e{MSG_DEBUG,MDG_ERROR,MSG_WARNING,MSG
_APPLICATION_ERROR,MSG_STATE_UPDATE};
Delivery type flag: DELIVER_MESSAGE_QUEUE,DELIVER_LOG_FILE,
DELIVER_MODAL_DIALOG,DELIVER_MODELESS_DIALOG,
DELIVER_CONSOLEOUTPUT
(2) 속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| static | VOOperator* | m-pVO | 영상 오퍼레이터 포인터 |
| static | VOSchedule* | m_pSchedule | 스케줄러 포인터 |
| static | VOCallObjMgr* | m_pCallOM | 호출 오브젝트 매니저 포인터 |
| static | VOConnectionObjMgr* | m_pConnOM | 접속 오브젝트 매니저 포인터 |
| static | VOCallSystem* | m_pCallSys | 호출 시스템 인터페이스 포인터 |
(3) 방식
(a) 포스트메시지
virtual Postmessage(messageType_e type,int errCode,CString info='''',int
delivery=(DELIVERY_MSG_QUEUE│DELIVER_LOG_FILE),
senderType_e senderType=SENDER_INTERNAL,void*sender=NULL);
(i) 파라미터
타입 데이터 타입 섹션에서 규정된 바와 같은 메시지 타입
errCode 어플리케이션 리소오스에서 규정된 바와 같은 에러 또는 경고
Info 메시지의 일부로서 건네지는 특별한 텍스트 정보
전달 바람직한 메시지 전달 방식. 전달 옵션은 상기의 데이터 타입 섹션에서 보여 준다. 전달의 디폴트 방식은 클래스 멤버 변수 m_delivery에 저장되는데, 그것은 DELIVER_MESSAGE_QUEUE 및 DELIVER_LOG_FILE 양자로만 초기화되어야 한다.
senderType 데이터 타입 섹션에서 규정된 바와 같이 메시지 sender type
Sender 메시지 즉 상기의 것을 송신하는 오브젝트의 포인터
(ii) 서술
에러, 경고, 디버그, 로그 및 통지 메시지를 생성하기 위하여 상기 기능을 사용하라. 그것은 VOMessage 오브젝트를 생성할 것인데, 상기 VOMessage는 그리고 나서 delivery flag에 의하여 기술된 적절한 액션을 실행할 것이다.
(b) GetErrorString
virtual CString GetErrorString(int errorCode);
Return Value: 건네진 에러 코드에 대응되는 에러 스트링을 가지는 CString을 return한다.
errorCode parameter: the error code for which you want the error string. Error string은 리소오스로서 저장된다.
상기의 기능은 에러 코드에 대응되는 textual description을 얻기 위하여 호출된다.
b) Core Classes
(1) 클래스 리스트
사이트
참가자 사이트
MCU 포트 사이트
영상 오퍼레이터 사이트
호출
재생 호출
Movie
호출 오브젝트 매니저
접속
접속 오브젝트 매니저
메시지
영상 오퍼레이터
(2) 클래스 해설
(a) 사이트
이것은 참가자 사이트 및 MCU 포트 사이트 클래스와 같은 클래스가 유도될 수 있는 베이스 클래스이다. 그것의 주목적은 누가 또는 무엇이 호출에 참가하는가에 관한 적절한 정보를 포함하는 데이터 구조로서의 기능을 하는 것이다.
클래스 VOSite
베이스 클래스 VOObject
Inheritance Type publc
Friend Classes -
(i) 데이터 타입
enum Bandwidth_e{MULTIRATE, BONDING, AGGREGATED, H0};
(ii) 속성
| 액세스 레벨 | 타입 | 명칭 | 설명 |
| Cstring | m_name | 사이트명 | |
| ID_t | m_ID | 고유의 사이트명 | |
| ID_t | m_locationID | 물리적 로케이션 ID | |
| Cstring | m_timezone | 시간 영역 | |
| Cstring | m_dialNumber | 다이얼하기 위한 번호. 다중 번호 포맷을 위한 상기 호출 시스템 인터페이스 섹션을 본다. | |
| Bamdwidth_e | m_bandwidthUsage | Bandwidth usage | |
| int | m_maxNumChannels | 채널 capable의 최대 번호 | |
| VOCall* | m_pCall | pointer to Call object that this Site is a part of.*Codec or 터미널 타입(Picture Tel, MCP, etc)*Call Setup Type(dial-in, dial-out) |
(b) 참가자 사이트
VOSite 베이스 클래스로부터 계승된다.
모든 커스터머 및 회의 참가자는 VO 공유 데이터베이스에 저장되어 있는 그들의 정보를 가질 것이다.
Class VOParticipantsite
Base Class VOsite
Inheritance Type public
프랜드 클래시스 -
속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| Cstring | m_coordinatorname | 사이트 코디네이터 명칭 | |
| CString | m_coordinatonbr | 사이트 코디네이터 번호 | |
| ID_t | m_companyID | 상기 사이트가 속하는 회사의 ID | |
| VOMCUportsite* | m_pMCUport | 접속 오브젝트와 관련된 mcu 포트 사이트 |
(c) mcu 포트 사이트
VOSite 베이스 클래스로부터 계승된다.
모든 회의는 mcu 상에서 발생한다. 각 참가자 사이트는 mcu 상의 논리 "포트"에 접속될 필요가 있다.
클래스 VOMCUportsite
베이스 클래스 VOSite
계승 타입 public
프랜드 클래스 -
속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| ID_t | m_mcuID | mcu를 식별하는 ID | |
| VOParticipantSite* | m_pParticipant | 접속 오브젝트에 관련되어 있는 참가자 사이트 |
(d) 영상 오퍼레이터 사이트
VOSite 베이스 클래스로부터 계승된다.
모든 호출은 포인트-투-포인트 호출 상에서 상기 사이트 중의 하나로서 영상 오퍼레이터 사이트를 가질 것이다. 상기 구조는 영상 오퍼레이터의 실제 ani를 포함한다.
클래스 VOoperatorsite
베이스 클래스 VOSite
계승 타입 공용
프랜드 클래스 -
속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| ID_t | m_operatorID | 오퍼레이터의 ID | |
| CString | m_voicephone | 오퍼레이터의 음성 폰 넘버 | |
| ID-t | m_groupID | 오퍼레이터의 그룹 ID | |
| ID_t | m_superviserID | 슈퍼바이저의 ID | |
| coblist | m_calls | 상기 사이트가 일 부분을 이루는 호출 오브젝트의 리스트 |
(e) 호츨
호출은 두 개의 사이트 사이에서 전 이중 방식의 h.320 흐름으로서 규정된다. 모든 호출에서 영상 오퍼레이터 사이트는 상기 사이트 중의 하나일 수 있다. 호출의 결합 쌍은 접속으로 불린다.
클래스 VOCall
베이스 클래스 VOObject
계승 타입 공용
프랜드 클래스 -
(i) 데이터 타입
enum statecall_e {ERROR, INACTIVE, INCOMING, DIALING, ACTIVE, DISCONNECTED, HELD, lastcallstates};
enum callOperation_e{ERROR, DIAL, ANSWER, HOLD, PICKUP, DISCONNECT, HANGUP, lastCallOperations}
(ii) 속성
| 액세스레벨 | 타입 | 이름 | 서술 |
| ID_t | m_ID | 호출 ID | |
| VOSite* | m_pSite | 호출 사이트의 다른 쪽 끝(참가자, MCU포트 또는 미지) | |
| VOOperatorsite* | m_pOperatorSite | 오퍼레이터 사이트 | |
| boolean | m_operatorInitiated | 호출이 오퍼레이터(디폴트)에 의하여 개시되면 TRUE | |
| CTime | m_startTime | 호출이 실행될 때의 실제 시간 | |
| boolean | m_expectHangup | 행업이 기대되는지 여부의 결정에 도움을 주는 플래그 | |
| StateCall_e | m_state | 호출의 상태 | |
| StateCall-e[nCallStates][nCallOperations] | m_transitionToble | 상태 전이표 | |
| VORecorder* | m_pRecorder | 호출에 대한 레코더 오브젝트 | |
| VOConnection* | m_pConnection | 상기 호출이 속하는 접속 오브젝트에 대한 포인터 |
(ii) 방식
Disconnection(); 회선의 다른 쪽 끝이 행 업(hang up) 되거나 상기 회선이 사용 불능될 때를 나타낸다. 멤버 변수 m_expectHangup은 FALSE이어야 한다. 그렇지 않으면, Call Object's Hangup() 오퍼레이션은 호출될 것이다.
Reset(); 호출 상태를 비능동 상태로 재 설정한다.
RecordingStart(); 호출에 대한 H.320 입력 파이프 기록을 개시한다.
RecordingStop(); 호출에 대한 기록을 종료한다.
setState(callOperation_e operation);
오퍼레이션 파라미터: 상태 변경으로 귀착될 실행된 오퍼레이션을 나타낸다.
GCNF 상태에 영향을 미치는 오퍼레이션은 오퍼레이션이 실행된 후 setState를 호출하여야 한다. 상기 기능은 상태-전이표에서 현 상태 및 오퍼레이션을 참조함으로써 호출 상태를 변경할 것이다. VOMessage 오브젝트는 일종의 status_update로 생성될 것이고 어플리케이션 큐를 읽는 GUI 및 어떠한 다른 구성 요소는 따라서 상태 갱신을 통보 받을 것이다.
(f) 재생 호출
VOCall 베이스 클래스로부터 계승된다.
특별한 호출의 경우에는, 영상 오퍼레이터 음성 및 영상 출력은 영상 오퍼레이터 저장 및 재생 외부 구성 요소에 의하여 무비(movie)의 재생으로부터 h.320 흐름으로 대체된다.
클래스 VOplaycall
베이스 클래스 VOCall
계승 타입 공용
프랜드 클래스 -
(i) 속성
| 액세스레벨 | 타입 | 이름 | 서술 |
| VOMovie* | m_pMovie | 실행될 무비 오브젝트 | |
| VOPlayer* | m_pPlyer | 재생을 실행하는 플레이어 오브젝트 |
(ii) 방식
PlaybackStart(); 재생을 시작한다
PlaybackStop(); 재생을 종료한다
(g) 무비
무비는 h.320 호출의 기록이다. 위상 1을 위하여, 영상 오퍼레이터 저장 및 재생 시스템은 저장 및 검색뿐 아니라 무비의 기록 및 재생을 위하여 파일 및 h.320 데이터를 관리한다.
클래스 VOMovie
베이스 클래스 OObject
계승 타입 공용
프랜드 클래스
속성
| 액세스레벨 | 타입 | 이름 | 서술 |
| public | ID_t | m_movieID | 무비 ID |
| public | CString | m_description | 무비 설명 |
(h) 호출 오브젝트 관리자
호출 오브젝트 관리자가 호출 오브젝트의 건설 및 파괴를 실행하도록 함에 의하여, 영상 오퍼레이터의 장치상의 모든 호출 리스트는 유지될 수 있다. 이는 입중계 호출 및 일반적 목적 다이얼 아웃 호출을 포함하는 어떠한 회의 또는 재생 세션의 일부가 아닌 호출을 포함한다. 호출에 영향을 미치나 호출을 생성 또는 파괴하지 않는 오퍼레이션은 호출 오브젝트 자신에 의하여 실행될 수 있다.
클래스 VOCallObjManager
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스 -
(i) 속성
| 액세스레벨 | 타입 | 이름 | 서술 |
| int | m_numChannels | 사용되지 않는 채널의 총 숫자 | |
| int | m_numActive | 능동 채널의 총 숫자 | |
| CMapStringToOb | m_cllList | 호출의 리스트 |
(ii) 방식
Dial();
Dial(VOCall*pCalling);
pcall 파라미터: 비어 있지 않는 경우, 상기 포인터는 호출 오브젝트에 사용될 것이다. 상기 포인터는 비능동 또는 단절 상태에 있는 호출 오브젝트를 생성 또는 재 사용할 때 필요하다.
다이얼은 다이얼 아웃을 실행한다. 다이얼 호출하기 위한 번호는 m_psitecall 멤버 구조에 존재한다.
Answer();
Answer(VOCall*pIncoming);
pIncoming parameter: 비어 있지 않은 경우, 상기 포인터는 호출 오브젝트에 사용되어 질 것이다. 상기 포인터는 비능동 또는 단절 상태에 있는 호출 오브젝트를 생성 또는 재 사용할 때 필요하다.
응답은 입중계 호출에 응답한다.
Hangup(VOCall*pCall);
pCall parameter: 상기 호출에 대한 포인터
행업은 pcall에 의하여 지시된 호출을 행업한다.
Hold(VOCall*pCall);
pCall parameter: 상기 호출에 대한 포인터
보류는 지시된 호출을 보류 상태에 둔다.
VOCall*CallCreate();
VOCall*CallCreate는 호출 오브젝트를 생성한다.
VOPlaybackCall*PlaybackCallCreate();
VOPlaybackCall*PlaybackCallCreate()은 재생 호출 오브젝트를 생성한다.
VOCall*GetCallPtr(ID_t idCall);
idCall parameter: id를 호출한다.
VOCall*GetCallPtr은 idCall에 의하여 식별되는 호출에 대한 포인터를 가진다.
(i) 접속
접속은 결합 상태를 유지하는 호출 오브젝트 쌍으로서 식별되고, 각 호출은 실행되는 결합을 위하여 공용 포인트로서 영상 오퍼레이터 사이트를 가진다.
Class VOConnection
Base Class VOObject
Inheritance Type public
Friend
(i) 데이터 타입
enum StateConnection_e {ERROR, UNJOINED, JOINED, BROKEN, lastConnectionStates };
enum ConnectionOperation_e {ERROR, JOIN, UNJOIN, BREAK, RESET,
lastConnectionOperation};
(ii) 속성
| 액세스레벨 | 타입 | 이름 | 서술 |
| VOCall* | m_pParticipantCall | 참가자 호출에 대한 포인터 | |
| VOCall* | m_pMCUPortCall | mcu 포트 호출에 대한 포인터 | |
| VOParticipantSite* | m_pParticipantSite | 참가자 사이트에 대한 포인터 | |
| VOMCUSite | m_pMCUPortSite | mcu 포트 사이트에 대한 포인터 | |
| CTime | m_joinTime | 결합 시간 | |
| VOMovie* | m_pMovie | 기록 및 재생을 위한 무비 포인터 | |
| boolean | m_expectBreak | break가 기대되는지 여부의 결정에 도움을 주는 플래그 | |
| StateConnection_e | m-state | 접속 상태 | |
| StateConnection_e[nConnectionStates][nConnectionOps] | m_transitionTable | 상태 전이표 | |
| VOConference* | m_pConference | 상기 접속이 일부분인 회의에 대한 포인터 |
(iii) 방식
Join(); 참가자 및 mcu 포트 호출을 결합한다.
Unjoin(); 참가자 및 mcu 포트 사이트를 결합 해제한다.
SetParticipantCall(VOCall*participantCall);
participantCall 파라미터: 호출 오브젝트에 대한 포인터
setparticipantcall은 상기 호출이 참가자 호출이 되도록 설정한다. 이는 미지의 입중계 호출을 관리할 때 또는 마지막 순간 호출 사이트 치환에 유용하다.
SetMCUPortCall(VOCall*mcuPortCall);
mcuPortCall 파라미터: 호출에 대한 포인터
setmcuportcall은 상기 호출이 mcu 포트 호출이 되도록 설정한다. 이는 미지의 입중계 호출을 관리할 때 또는 마지막 순간 호출 사이트 치환에 유요하다.
DoparticipantCall(); 참가자 사이트를 호출하고 이것을 참가자 호출로 설정한다.
DoMCUPortCall(); mcu 포트 사이트를 호출하고 이것을 mcu 포트 호출로 설정한다.
setState(ConnectionOperation_e operation);
오퍼레이션 파라미터: 상태 변화로 귀착될 실행된 오퍼레이션.
접속 상태에 영향을 미치는 오퍼레이션은 상기 오퍼레이션이 실행된 후 setstate 기능을 호출하여야 한다. 상기 기능은 현재의 상태 및 상태-전이표의 오퍼레이션을 참조하여 접속의 상태를 변경하여야 한다. vom 오브젝트는 STATUS_UPDATE 타입으로 생성될 것이고, 어플리케이션 큐로 송신된다. 어플리케이션 큐를 읽는 GUI 및 다른 구성 요소는 따라서 상태 갱신을 통보 받을 것이다.
Protected Break(); 결합 접속이 결합 해제될 때 호출된다. 멤버 변수 m_expectbreak가 false인 경우, 그 때 호출 중 하나는 갑자기 단절되어야 한다. 그렇지 않으면, connection'unjoin() 오퍼레이션이 호출될 것이다.
protected Reset(); 접속 상태를 UNJOINED로 설정한다.
(j) 접속 오브젝트 관리자
호출 오브젝트 관리자와 유사하게, 영상 오퍼레이터의 장치상의 오퍼레이션의 모든 접속의 리스트는 유지되어야 한다. 접속의 생성 및 삭제로 귀착되는 모든 오퍼레이션은 접속 오브젝트 관리자를 사용하여야 한다.
Class VOConnectionObjMgr
Base Class VOObject
Inheritance Type public
Friend Classes
(i) 속성
| 액세스 레벨 | 타입 | 이름 | 서술 |
| CMapStringToOb | m_connectionsList | 모든 접속의 리스트 | |
| int | m_numJoined | 결합된 접속의 숫자 |
(ii) 방식
VOConnection*Create();
복귀 값: 접속 오브젝트에 대한 포인터
VOConnection*Create는 새로운 접속을 생성하고 이것을 리스트에 추가한다.
Remove(VOConnection*oldConnection);
구 접속 파라미터: 제거되는 접속 오브젝트
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
제거는 접속 오브젝트를 삭제하고 이것을 리스트로부터 제거한다.
VOConnection*GetConnectionPtr(ID_t idConnection);
복귀 값: 접속 오브젝트에 대한 포인터
idconnection 파라미터: 접속의 파라미터
VOconnection*getconnectionptr은 id에 의하여 식별된 접속 오브젝트에 대한 포인터를 복귀시킨다.
(k) 메시지
인터넷 시스템으로부터 영상 오퍼레이터 어플리케이션, 즉 화상 사용자 인터페이스의 거처(rest)로의 모든 일-방향 통신은 어플리케이션 큐에 배치되는 메시지로서 송신된다. 메시지를 생성하고 통지하는 기능은 베이스 클래스 VOObject에 존재하는데, 상기 베이스 클래스 VOObject로부터 모든 인터넷 시스템 소프트웨어가 계승된다. 모든 실행 시간 에러 및 디버그 정보는 메시지 오브젝트에 놓여지고 어플리케이션 큐로 통지되어 적절한 오브젝트가 상기 정보의 타입 및 severity에 따라 상기 정보를 처리한다. 그러므로, 특정한 타입을 복귀시키지 않는 모든 클래스 기능은 일이 잘못되는 경우(메모리 장애)인 경우 메시지를 통지하고 GUI에 의하여 디스플레이 되거나 파일로 로그 되는 디버그 정보를 통지한다.
Class VOMessage
Base Class VOObject
Inheritance Type Public
Friend Classes
(i) 데이터 타입
enum senderType_e {INTERNAL, SCHEDULE, CONFERENCE, CONNECTION, CALL, TIMER};
enum messageType_e {DEBUG, ERROR, WARNING, APPLICATION_ERROR, STATE_UPDATE};
Delivery type flags: DELIVER_MESSAGE_QUEUE, DELIVER_LOG_FILE, DELIVER_MODAL_ DIALOG, DELIVER_MODELESS_DIALOG, DELIVER_CONSOLEOUTPUT
(ii) 속성
| 액세스레벨 | 타입 | 명칭 | 서술 |
| int | m_errorCode | 에러 코드 | |
| int | m_delivery | 통지시 바람직한 메시지 전달을 위한 플래그 | |
| senderType_e | m_senderType | 송신자 타입 | |
| VOObject* | m_pObject | 송신자에 대한 포인터 | |
| messageType_e | m_messageType | 메시지에 대한 포인터 | |
| CString | m_info | 메시지 정보*메시지 또는 정보의 우선*메시지 또는 정보의 severity |
(iii) 방식
Post(); 어플리케이션 메시지 큐로 메시지를 통지한다.
Private static appendLog();
복귀 값: 오퍼레이션이 성공적인 경우 trueffm 복귀시킨다.
상기 방식은 VOObject::postmessage()에 의하여 DELIVER_LOG_FILE를 위한 플래그가 설정될 때 호출된다.
(l) 영상 오퍼레이터
일반적으로 장치마다 하나의 영상 오퍼레이터만이 존재할 것이다. 각 영상 오퍼레이터는 스케쥴 및 관리되는 커스터머 참가자 사이트의 리스트를 가지고 있다. 상기 호출 오브젝트 관리자 및 접속 오브젝트 관리자는 또한 영상 오퍼레이터의 일 부분이다.
Class VOOperator
Base Class VOObject
Inheritance Type public
Friend
(i) 속성
| 액세스 레벨 | |||
| ID_t | m_operatorID | 오퍼레이터 id | |
| VOSchedule | m_schedule | 현재의 오퍼레이터에 대한 스케쥴 | |
| CObList | m_MCUlist | mcu 오브젝트의 리스트 | |
| CObList | m_operatorSites | 오퍼레이터의 사이트 | |
| static | VOUserPreferences | m_userPreferences | 디폴트 어플리케이션 사용자 우선(preference) |
(ii) 방식
protected ScheduleStart(); 영상 스케쥴을 위한 스케쥴을 개시한다.
protected CallObjMgrStart(); 호출 오브젝트 관리자를 개시한다.
protected ConnectionObjMgrStart(); 접속 오브젝트 관리자를 개시한다.
protected CallSystemInterfaceStart(); 호출 시스템 관리자를 개시한다.
(m) 사용자 우선
영상 오퍼레이터 콘솔 어플리케이션은 수정될 수 있고 저장될 수 있는 디폴트 어플리케이션 프리퍼런스(preference)의 세트를 가지고 있다. 상기 변수의 값은 증가하는 프리퍼런스 순으로 다음의 신호원로부터 얻어진다: 하드-코드된 디폴트 값, 저장된 vo.ini 파일, 명령-줄 발동 인수(arghment), gui 엔트리 및 vo.ini 파일로 저장된 실행 시간 수정.
Class VOUserPreferences
Base Class VOObject
Inheritance Type public
Friend
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| ID_t | m_operatorID | 디폴트 오퍼레이터 id |
(ii) 방식
SavePrefs(); 모든 값은 vo.ini로 저장한다.
LoadPrefs(); 모든 값을 vo.ini로 로드 한다.
(n) mcu
모든 mcu 포트 사이트는 특정 mcu에 대응된다. 상기 클래스는 mcu 포트 사이트 저장에만 사용된다. 위상 2를 위하여 mcu 특정 오퍼레이션 및 인터페이스는 여기에서 실행될 수 있다.
Class VOMCU
Base Class VOObject
Inheritance Type public
Friend classes
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| ID_t | m_mcuID | mcu의 id | |
| CObList | m_portList | mcu 포트 사이트 오브젝트의 리스트 |
(ii) 방식
VOMCUPortSite*GetPortPtr(ID_t idPort)
복귀 값: mcu 포트 사이트 오브젝트에 대한 포인터
idport 파라미터:mcu 포트 사이트의 id
VOMCUPortSite*GetPortPtr는 id에 의하여 식별된 mcu 포트 사이트 오브젝트에 대한 포인터를 복귀시킨다.
VOMCUPortSite*CreatePort();
복귀 값: 새로운 mcu 포트 사이트 오브젝트에 대한 포인터
VOMCUPortSite*CreatePort()는 id에 의하여 식별되는 새롭게 생성된 mcu 포트 사이트에 대한 포인터를 복귀시킨다.
(3) 코어 클래스에 대한 상태 변수 전이도
도 101은 VOCall 오브젝트의 m_state 변수("상태 변수")에서 발생할 수 있는 상태 변화를 도시하는 상태 전이도이다. 상기 상태 변수는 비능동 40502 상태에서 40501을 시작한다.
VOCall 오브젝트가 비능동 40502 상태일 때 다이얼 40503 입력을 수신하는 경우, 상기 상태 변수는 다이얼링 40504 상태로 변경된다. 상기 다이얼링 40504 상태에서는, 상기 상태 변수가 통화중 40505 입력을 수신함과 동시에 비능동 40502 상태로 변경되거나 응답 40506 입력을 수신함과 동시에 능동 40507 상태로 변경된다. 능동 40507 상태에서는 상기 상태 변수가 보류 40509 입력을 수신함과 동시에 held 40510 상태로 변경되거나 단절 40514 입력을 수신함과 동시에 단절 40515 상태로 변경되거나 행 업 40508 입력을 수신함과 동시에 비능동 40502 상태로 변경된다. held 40510 상태에서는 상기 상태 변수가 pickup 40511 입력을 수신함과 동시에 능동 40507 상태로 변경되거나 단절 40513 입력을 수신함과 동시에 단절 40515 상태로 변경되거나 행업 40512 입력을 수신함과 동시에 비능동 40502 상태로 변경된다. 단절 40515 상태에서는, 상기 상태 변수가 재설정 40516 입력을 수신함과 동시에 비능동 40502 상태로 변경된다.
상기 VOCall 오브젝트가 비능동 40502 상태일 때 입중계 호출 40517을 수신하는 경우, 상기 상태변수는 입중계 40518 상태로 변경된다. 입중계 40518 상태에서, 상기 상태 변수는 reject 40520을 수신함과 동시에 비능동 40502로 변경되거나, 응답 40519 입력을 수신함과 동시에 능동 40507 상태로 변경된다.
도 102는 상기 VOconnection 오브젝트의 m_state 변수("상태 변수")에서 발생 할 수 있는 상태 변화를 도시하는 상태 전이도를 보여 준다. 상기 상태 변수는 분리 40602 상태에서 40601을 시작한다. 분리 40602 상태에서, 상기 상태 변수는 결합 40603 입력을 수신함과 동시에 결합 40604로 변경된다. 결합 40604 상태에서, 상기 상태 변수는 분리 40605 입력을 수신함과 동시에 분리 40602로 변경되거나 break 40606 입력을 수신함과 동시에 broken 40607 상태로 변경된다. broken 40607 상태에서, 상기 상태 변수는 결합 40608 입력을 수신함과 동시에 결합 40604 상태로 변경된다.
(c) 스케쥴링 시스템 클래스
(1) 클래스 리스트
재생 세션
회의
스케쥴
계획할 수 있는(schedulable)
(2) 클래스 서술
(a) 재생 세션
회의와 마찬가지로, 재생 세션은 계획 될 필요가 있다. 호출은 참가자 사이트 및 영상 오퍼레이터 사이트를 사용하여 호출이 이루어진다. 상기 영상 기억 장치 및 재생 외부 구성 요소는 av 출력을 참가자 사이트로 치환하는 계획되고 미리 선택된 무비를 재생할 것이다. 어떠한 mcu도 재생 세션에 사용되지 않고 오직 하나의 참가자 사이트만이 하나의 실시 예에 포함된다.
Class VOPlaybackSession
Base Class VOSchedulable
Inheritance public
Type
Friend Classes
(i) 데이터 타입
enum StatePlaybackSession_e {ERROR, INACTIVE, SETUP, ACTIVE, ENDING, FINISHED , lastPBSessionStates};
enum playbackSessionOperation_e {ERROR, PREPARE, START, CLOSE, FINISH,
lastPBSessionOperations};
(ii) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| public | ID_t | m_ID | 예약이 세션을 위하여 만들어질 때 할당되는 id |
| public | CString | m_name | 세션에 대한 약칭 |
| public | CString | m_description | 간단한 서술 |
| public | CTime | m_startTime | 개시 시간 |
| public | CTimespan | m_duration | 재생 세션의 지속 시간 |
| public | int | m_xferRate | 데이터 전송률(채널의 숫자) |
| protected | VOPlaybackCall* | m_playbackCall | 재생 호출 오브젝트 |
| protected | StatePlaybackSession_e | m_state | 재생 세션의 상태 |
| protected | StatePlaybackSession_e[lastPBSessionStates][lastPBSessionOps] | m_transitionTable | 상태 전이표 |
(iii) 방식
public boolean Setup();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 셋업()은 참가자를 호출함으로써 재생 호출을 셋업하고 VOplayer 오브젝트를 초기화한다. 상기 기능은 스케줄러에 의하여 호출될 수 있다.
Public boolean Start();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 개시는 재생 호출을 작동시키기 위하여 플레이어를 개시한다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
Public boolean Close();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 폐쇄는 영상 오퍼레이터에 메시지 송신하고 아마도 조만간 종료될 재생 세션인 참가자에게도 메시지를 송신할 것이다.
Public boolean Finish();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 종료는 플레이어 및 hangup the playback call을 종료시킨다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
public StatePlaybackSession_e StateGet();
복귀 값: 재생 세션의 상태를 복귀시킨다.
use the public stateplaybacksession_e stateget; 재생세션의 상태를 찾아내는 기능.
protected boolean StateSet(playbackSessionOperation_e operation);
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
오퍼레이션 파라미터: 상태 변화로 귀착될 실행된 오퍼레이션.
재생 세션의 상태에 영향을 미치는 오퍼레이션은 상기 오퍼레이션이 실행될 주 프로텍트된 불 stateset 기능을 호출한다. 상기 기능은 상태-전이표의 현 상태 및 오퍼레이션을 참조함으로써 재생 세션의 상태를 변경할 것이다. VOmessage 오브젝트는 status-update 타입으로 생성될 것이고 어플리케이션 큐로 송신될 것이다. 그러므로 어플리케이션 큐를 읽는 gui 및 어떠한 구성요소는 상태 갱신을 통보 받을 것이다.
(b) 회의
상기 영상 오퍼레이터의 주 기능은 회의를 관리하는 것이다. 스케쥴 시스템은 회의 오브젝트를 생성하는데, 상기 회의 오브젝트는 차례로 접속(또는 참가자-mcu 포트 사이트 호출쌍)의 리스트를 생성한다. 회의로 다시 재생되는 무비의 특별한 경우에, 특별한 호출이 mcu 포트로 이루어지고 상기 무비는 재생 세션과 유사한 방식으로 mcu로 재생된다. 상기 경과는 사용될 수 있는 특별한 mcu 포트 사이트를 필요로 하고 회의 개시 전에 계획되어져야 한다.
Class VOConference
Base Class VOSchedulable
Inheritance Type public
Friend Classes
(i) 데이터 타입
enum conferenceMode_e {CONTINUOUS_PRESENCE, VOICE_ACTIVATED, LECTURE,
DIRECTOR_CONTROL};
enum StateConference_e {ERROR, INACTIVE, SETUP, ACTIVE, ENDING, FINISHED,
lastConferencesStates};
enum conferenceOperation_e {ERROR, PREPARE, START, CLOSE, FINISH,
lastConferenceOperations};
(ii) 속성
| 액세스레벨 | 타입 | 명칭 | 서술 |
| ID_t | m_ID | 예약이 이루어질 때 주어지는 회의 id | |
| CString | m_name | 회의에 대한 명칭 | |
| CString | m_description | 간단한 서술 | |
| CString | m_timeZone | 시간 영역 | |
| CTime | m_startTime | 회의의 개시 시간 | |
| CTimeSpan | m_duration | 회의의 지속 시간 | |
| int | m_transferRate | 전송률 | |
| int | m_numActiveConns | 능동 회의의 숫자 | |
| conferenceMode_e m_mode | 접속 모드 | ||
| boolean | m_recordingScheduled | 상기 회의가 기록되는 경우 true | |
| CObList | m_connectionsList | 접속 오브젝트를 저장하는 리스트 | |
| CMapStringToObj | m_participantSiteList | 참가자 사이트의 리스트 | |
| VOPlaybackCall | m_playbackCall | 회의에서 재생이 존재하는 경우, 이것은 유효하다. | |
| StateConference_e | m_state | 회의의 현 상태 | |
| StateConference_e [lastConferenceStates] [lastConferenceOps] | m_transitionTable | 상태 전이표*호출셋업 타입*음성 프로토콜*영상 프로토콜 멀티 mcu 회의*h.243 좌석 제어 및 패스워드 |
(iii) 방식
public boolean Setup();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
고용 불 셋업은 적절한 각 참가자 사이트 및 mcu 포트 사이트를 호출함으로써 접속 리스트의 각 접속(및 필요하다면 재생 호출)을 셋업하고 상기 접속을 생성하기 위하여 결합 오퍼레이션을 실행한다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
Public boolean Start();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 개시는 상기 회의를 개시한다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
Public boolean End();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
Public boolean End는 회의에서의 접속을 해체하는 것을 개시하거나 상기 회의가 조만간 종료될 것임을 나타내는 경고를 발행한다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
Public boolean Finish();
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 불 종료는 상기 회의를 종료하고 회의에서의 모든 호출을 행 업한다. 상기 기능은 스케쥴러에 의하여 호출될 수 있다.
public StateConnference_e StateGet();
복귀 값: 회의 상태를 복귀시킨다.
use the public stateconferance_e stateget는 회의의 상태를 찾아내는 기능을 한다
protected boolean StateSet(conferenceOperation_e operation);
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
오퍼레이션 파라미터: 상태 변화로 귀착될 실행된 오퍼레이션.
회의 상태에 영향을 미치는 오퍼레이션은 상기 오퍼레이션이 실행된 후 보호 불 stateset 기능을 호출하여야 한다. 상기 기능은 상태-전이표의 현 상태 및 오퍼레이션을 참조함으로써 회의의 상태를 변경할 것이다. VOmessage 오브젝트는 state-update 타입으로 생성될 것이고 어플리케이션 큐로 송신될 것이다. 어플리케이션 큐를 읽는 gui 및 어떠한 다른 구성요소는 따라서 상태 갱신을 통보 받을 것이다.
(c) 스케쥴
스케쥴링 시스템은 회의 및 재생 세션의 리스트를 유지한다. 각 회의 및 재생 세션은 그것의 시작 시간 전에 특정한 시간 간격에서 생성된다. 메모리의 스케쥴 및 현 영상 오퍼레이터에 대한 영상 오퍼레이터 공유 데이터베이스에 저장된 스케쥴은 항상 동기에 일어나야 한다.
Class VOConference
Base Class VOSchedulable
Inheritance Type public
Friend Classes
(i)속성
| 액세스레벨 | 타입 | 명칭 | 서술 |
| ID_t | m_operatorID | 책임 있는 오퍼레이터 id | |
| CMapStringToObj | m_schedItems | 스케쥴 오브젝트(회의 및 재생 세션)의 리스트 | |
| CMapWordToOb | m_schedAlarms | 스케쥴 오브젝트상(건설 및 삭제)의 오퍼레이션을 위하여 설정된 경보 리스트 |
(ii) 방식
SynchWithDb(); 스케쥴을 위하여 VO 공유 데이터베이스와 동기에 일어나게 한다.
AddSchedulable(VOSchedulable*pSchedulable);
pschedulable parameter: 리스트에 추가되는 스케쥴 오브젝트에 대한 포인터
addschedule은 리스트에 스케줄 오브젝트를 추가한다.
DeleteSchedulable(ID_taSchedulable);
aschedulable 파라미터: 리스트로부터 제거되는 계획할 수 있는 오브젝트
deleteschedulable은 schedulable 오브젝트를 삭제하고 리스트로부터 제거한다.
(d) schedulable
위상 1에서 계획되는 항목 및 오브젝트는 회의 및 재생 세션이다. 상기 클래스는 우리들이 어떠한 타입의 이벤트에 대한 스케쥴을 생성하는 것을 허용한다.
클래스 VOSchedulable
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스 -
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| ID_t | m_requestor | 요청자의 id | |
| Ctime | m_startTime | 계획된 개시 시간 | |
| CTimeSpan | m_duration | 이벤트 계획된 지속 시간 | |
| Ctime | m_endTime | 이벤트의 계획된 종료시간 | |
| MMRESULT | m_alarmID | 현재 설정된 경보의 id |
(ii) 방식
public SetAlarm(Ctime time, LPTIMECALLBACK fune);
time 파라미터: 트리거(trigger)된 경보를 위한 시간
func 파라미터: 경보가 트리거 될 때 callback 기능에 대한 포인터
복귀 값: 오퍼레이션이 성공적인 경우 true를 복귀시킨다.
공용 setalarm은 구체적인 시간에 경보가 트리거 되게 한다. 상기 경보가 트리거 될 때, 상기 callback은 호출될 것이다. 이는 회의 개시 전 15분, 회의 종료 전 5분 및 회의가 종료된 후 30분과 같이 시간 종속 이벤트에 유용하다.
public KillAlarm();
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
공용 killalarm은 setalarm()에 의하여 설정된 마지막 경보를 소멸시킨다. 이는 회의 등을 중지하는 경우에 사용될 수 있을 것이다.
(3) 스케쥴 시스템 클래스에 대한 상태 변수표 다이어그램
도 103은 VOconference 오브젝트의 m_state 변수("상태 변수")에서 발생할 수 있는 상태 변화를 도시하는 상태 전이도를 보여준다. 상태 변수는 비능동 40702 상태에서 개시된다. 비능동 40702 상태에서, 상태 변수는 "계획된 시간 전 15분" 40703 입력을 수신함과 동시에 접속셋업 40704 상태로 변경된다. connectionsetup 40704 상태에서, 상기 상태변수는 startconference 40705 입력을 수신함과 동시에 능동 40706 상태로 변경된다. 능동 40706 상태에서, extendconference 40707 입력을 수신함과 동시에 능동 40706 상태로 유지되거나 closeconference(propertermination) 40708 입력은 수신함과 동시에 ending 40707 상태로 변경된다. ending 40707 상태에서, finish 40710 입력을 수신함과 동시에 finished 40711 상태로 변경된다.
d) 기록 및 재생 클래스
(1) 클래스 리스트
레코더
플레이어
(2) 클래스 상세
(a) 레코더
레코더는 호출의 입력 파이프의 실제 무비 생성 및 기록을 실행하는 어떠한 외부 구성요소 무엇과도 통신한다. 상기 외부 구성요소는 영상 오퍼레이터 기억 장치 및 재생 시스템으로 알려져 있다.
클래스 VORecorder
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스 -
(i) 데이터 타입
enum StateRecorder_e {ERROR, IDLE, RECORDING, PAUSED, FINISHED,
lastRecorderStates};
enum recorderOperation_e {ERROR, BEGIN, PAUSE, RESUME, STOP,
lastRecorderOpsP}
(ii) 속성
| 액세스레벨 | 타입 | 명칭 | 서술 |
| VOMovies* | m_movie | 무비 | |
| VOCall* | m_pCall | (기록을 위한)호출 포인터 | |
| Cstring | m_info | 참가자 및 회의 명칭 | |
| Ctime | m_startTime | 개시 시간 | |
| Ctime | m_endTime | 종료 시간 | |
| CtimeSpan | m_duration | 총 기록 시간 | |
| StateRecorder_e | m_state | 상태 | |
| StateRecorder_e [lastRecorderStates] [lastRecorderOps] | m_transitionTable | 상태 전이표*vsf 오브젝트*기록 모드 |
(iii) 방식
InitMovie(); VOspsms 기록을 초기화 한다. 이것은 상기 vsop에게 기록을 준비하도록 지시한다.
start(); vsop는 기록을 개시한다.
stop(); vsop는 기록을 종료한다.
setState(recorder-Operation_e operation);
오퍼레이션 파라미터: 상태 변화로 귀착될 실행된 오퍼레이션.
레코더의 상태에 영향을 미치는 오퍼레이션은 오퍼레이션이 실행된 후 setstate 기능을 호출하여야 한다. 상기 기능은 상태-전이표에서 현 상태 및 오퍼레이션을 참조함으로써 레코더의 상태를 변경할 것이다. VOmessage 오브젝트는 status_update 타입으로 생성될 것이고 어플리케이션 큐로 송신될 것이다. 상기 어플리케이션 큐를 읽는 gui 및 어떠한 다른 구성요소는 따라서 상태 갱신을 통보 받을 것이다.
(b) 플레이어
플레이어는 호출의 출력 파이프로 무비의 실제 재생을 실행하는 어떠한 외부 구성요소와도 통신한다. 위상 1을 위하여, 상기 외부 구성요소는 영상 오퍼레이터 기억 장치 및 재생 시스템으로 알려져 있다.
클래스 VOPlayer
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스
(i) 데이터 타입
enum StatePlayer_e {ERROR, IDLE, PLAYING, PAUSED, FINISHED, nPlayerStates};
enum playerOperation_e {ERROR, BEGIN, PAUSE, RESUME, STOP, RESET, nplayerOps}
(ii) 속성
| 액세스레벨 | 타입 | 명칭 | 서술 |
| VOMovie* | m_pmovie | 무비 | |
| VOCall* | m_pCall | (재생을 위한)호출 포인터 | |
| Cstring | m_info | 참가자 및 회의 명칭 | |
| Ctime | m_startTime | 개시 및 종료 시간 | |
| Ctime | m_endTime | ||
| CtimeSpan | m_duration | 총 재생 시간 | |
| StateRecorder_e | m_state | 상태 | |
| StateRecorder_e [nPlayerStates] [nPlayerOps] | m_transitionTable | 상태 전이표*vsf 오브젝트*재생 무비 |
(iii) 무비
public InitMovie();
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
공용 initmovie VOsp는 재생을 초기화 한다. 이것은 상기 VOsp에게 재생을 준비하도록 지시한다.
public Start();
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
공용 개시 VOsp는 재생을 개시한다.
public Stop();
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
공용 종료 VOsp는 재생을 종료한다.
setstate(playerOperation_e operation);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
오퍼레이션 파라미터: 상태 변경으로 귀착될 실행된 오퍼레이션.
플레이어의 상태에 영향을 미치는 오퍼레이션은 상기 오퍼레이션이 실행된 후 setstate 기능을 호출하여야 한다. 상기 기능은 상태 전이표에서 현 상태 및 오퍼레이션을 참조함으로써 플레이어의 상태를 변경한다. VOmessage 오브젝트는 stasus_update 타입으로 생성될 것이고 어플리케이션 큐로 송신될 것이다. 어플리케이션 큐를 읽는 gui 및 어떠한 다른 구성요소는 따라서 상태 갱신을 통보 받을 것이다.
(3) 기록 및 재생 클래스를 위한 상태 전이도
도 104는 VOrecorder 오브젝트의 m_state 변수에서 발생될 수 있는 상태 변화를 도시하는 상태 전이도를 보여준다. idle 40802에서, 상태 변수는 begin recording 40803 입력을 수신함과 동시에 recording 40804 상태로 변경된다. 기록 40804 상태에서, 상태 변수는 pause 40805를 수신함과 동시에 paused 40806 상태로 변경되거나 stop 40808 입력을 수신함과 동시에 finished 40801 상태로 변경된다. paused 40806 상태에서, 상기 상태 변수는 resume 40804 입력을 수신함과 동시에 recording 40804 상태로 변경되거나 stop 입력을 수신함과 동시에 finished 40810으로 변경된다.
도 105는 VOplayer 오브젝트의 m_state 변수에서 발생할 수 있는 상태 변화를 도시하는 상태 전이도를 보여 준다. 상태 변수는 idle 40920 상태에서 40910을 개시한다. idle 40902 상태에서 상기 상태 변수는 begin playing 40903 입력을 수신함과 동시에 playing 40904 상태로 변경된다. playing 40904 상태에서, 상기 상태 변수는 pause 40905 입력을 수신함과 동시에 paused 40906 상태로 변경되거나 stop 40908 입력을 수신함과 동시에 finished 40901 상태로 변경된다. 상태 paused 40906 상태에서, 상기 상태 변수는 resume 40907 입력을 수신함과 동시에 playing 40904 상태로 변경되거나 stop 40909 입력을 수신함과 동시에 finished 40910 상태로 변경된다. finished 40910 상태에서, 상기 상태변수는 replay 40911 입력을 수신함과 동시에 playing 40904 상태로 변경된다.
(e) 호출 시스템 인터페이스 클래스 서술
호출 제어 시스템은 영상 오퍼레이터가 관리할 수 있는 모든 호출을 관리할 것이다. 상기 호출은 기록 및 재생과 같은 입중계 및 출중계 h.320 호출 관리 및 호출상의 저 레벨 오퍼레이션을 포함한다. 상기 영상 오퍼레이터 어플리케이션은 모든 호출을 균일한 방식으로 관리하는 호출 제어 시스템 외부 구성요소와의 통신을 하기 위하여 호출 시스템 인터페이스를 사용한다. 이것은 상기 영상 오퍼레이터가 다른 외부 프로그램, 장치에의 특별 코덱의 추가 또는 원격 장치 상에의 호출 관리까지도 요구하는 호출을 관리하는 것을 허용한다.
클래스 VOCallSys
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스
(1) 데이터 타입
enum Bandwidth_e {MULTIRATE, BONDING, AGGREGATED, H0}
Q.931 UserInfo for a call using BONDING:
0x00 0x01 0x07 0x44 0x79 0x00 0x00
0 1 7 447-9000
Bonded, 1 unmber, 7 digits long, 447-9000
Q.931 UserInfo for Aggregation:
0x01 0x02 0x07 0x44 0x79 0x00 0x00 0xFF 0x01
1 2 7 447-9000
Aggregated, 2 numbers. 7 digits long, 447-9000, 447-9001
(2) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| public | int | m_numCalls | 사용 가능한 호출의 총 개수 |
| public | int | m_numConnections | 사용 가능한 접속의 총 개수 |
(3) 방식
public Dial(Bandwidth_e calltype, CString destination);
public Dial(Bandwidth_e calltype, CString destination, CString origination);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
호출타입 파라미터: 만들어지는 호출의 타입을 상세히 서술한다.
착신지 파라미터: 다이얼 호출되는 착신지 번호를 상세히 서술한다.
발신지 파라미터: 오퍼레이터의 콘솔의 실제 번호 대신에 사용되는 발신지 번호를 상세히 서술한다.
공용 다이얼은 다이얼 아웃 한다.
public Answer(ID_t call);
호출 파라미터: 응답되기를 기다리는 호출의 호출 id
공용 응답은 입중계 호출에 대하여 응답한다.
public Hangup(ID_t call);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
호출 파라미터: 행업 되는 호출의 호출 id
공용 행업은 호출을 행업한다.
public Hold(ID_t call);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
호출 파라미터: 보류되는 호출의 호출 id
공용 보류는 상기 호출을 보류 상태에 둔다.
public Join(ID_t call1, ID_call2);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
호출1 파라미터: 호출의 호출 id.
호출2 파라미터: 호출의 호출 id.
공용 결합은 두 개의 호출을 결합한다.
(ID_t connection);
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
접속 파라미터: 분리되는 접속의 id.
공용 분리는 특정한 접속을 분리시킨다.
public StateCall_e CallStatus(ID_t call);
복귀값: 호출 상태를 복귀시킨다.
접속 파라미터: 분리되는 접속의 id
공용 statecall_ecallstatus는 특정한 호출의 상태를 보고한다.
publicStateConnection_eJoinStatus(ID_tconnection);
복귀값: 접속 상태를 복귀시킨다.
접속 파라미터: 분리되는 접속의 ID
공용 stateconnection_ejoinstatus는 특정한 결합의 상태를 보고한다.
protected LaunchMCP();
복귀값: 오퍼레이션이 성공적인 경우, true를 복귀시킨다.
보호된 launchmcp는 incite's mcp 어플리케이션을 입사시킨다(launch).
E. 화상 사용자 인터페이스 클래스
1. 클래스 계층
도 106은 영상 오퍼레이터 화상 사용자 인터페이스("GUI") 클래스를 위한 클래스 계층을 보여 준다. 일반적으로, 영상 회의 오퍼레이터는 상기 영상 오퍼레이터 콘솔 gui("콘솔 gui")와 상호 작용함으로써 여기에서 기술된 영상 회의 오퍼레이터 시스템의 모든 특징을 실행할 것이다. 콘솔 gui의 주 구성요소는 주 콘솔 윈도우, 스케쥴 및 접속 리스트 윈도우, 회의 및 접속 윈도우, 메시지 영역, 음성 및 영상 제어, 적시에 정보를 제공하는 대화 상자 및 드물게 실행될 수 있는 실행에 대한 메뉴 항목이다. mcu 오퍼레이션 및 특징은 영상 오퍼레이터 콘솔 gui에서 실행될 수 없고, 따라서 다른 mcu 모델 차입을 채용하는 영상 오퍼레이터 시스템의 다른 실시 예를 허용한다. vendor-specific mcu 오퍼레이션은 mcu 오퍼레이션에 부수하는 vendor의 소프트웨어에 의하여 실행될 것이다. 영상서버의 mcs를 채용하는 일 실시 예에서는, 상기 mcs 워크스테이션 소프트웨어는 회의 종료 시간 확장, 음성 및 영상 블로킹(blocking), 회의 디렉터 제어 등과 같은 특징을 실행하는데 사용될 수 있다. 상기 소프트웨어는 상기 영상 오퍼레이터 gui와 병렬으로 실행될 수 있다.
오브젝트-지향 프로그램밍 용어로 기술된 상기 gui는 내부에 모든 윈도우를 생성 유지하는 주 어플리케이션 오브젝트를 가지고 있다. 상기 주 윈도우는 VOconsoleapp 41008에 의하여 생성된 VOmainframe 41109이다. 상기 주프레임 윈도우는 VOschedulewnd 41016, VOalertwnd 41015, VOconferencevw 41014 및 VOvideowatch 41013을 생성한다. 상기 VOschedulewnd 및 VOalertwnd는 그들의 부모 윈도우의 한 측면에 어태치되는 것을 의미하는 도킹할 수 있는 윈도우이다. 상기 경우에, tdrl 부모 윈도우는 VOmainframe 41109 윈도우이다. 또한 상기 도킹할 수 있는 윈도우는 상기 윈도우를 멀리 드래깅(dragging)함으로써 경계로부터 분리될 수 있다. 상기와 같은 상황에서, 상기 윈도우는 정규 도구 윈도우처럼 실행될 것이다.
오브젝트의 각 클래스의 기능은 다음과 같이 요약된다. VOconsoleapp 41008은 주 어플리케이션 클래스이고 VOmainframe 41009는 나머지 모든 윈도우를 포함하는 주 윈도우이다. VOschedulewnd 41016은 에러 메시지 및 경보가 디스플레이 되는 윈도우이다. VOchildframe 41010은 다중 도큐먼트 인터페이스("mdi") 윈도우에 대한 프레임(frame) 윈도우이다. VOchildframe 41010은 각 뷰에 대한 메인프레임 윈도우처럼 실행될 것이고, VOchildframe 41010으로부터 도출된 VOconference 41018은 회의 뷰에 대한 프레임 윈도우이고, VOconferencevw 41014는 회의 정보를 디스플레이 하는 윈도우이다. VOconferencedoc 41012는 VOconferencevw 41014와 대응되는 도큐먼트 클래스이다. VOchildframe 41010으로부터 도출된 VOvideowatchframe 41017은 영상 시각 뷰에 대한 프레임 윈도우이고, VOvideowatchvw 41013은 호출을 만들기 위하여 영상 흐름 및 제어를 디스플레이 하는 윈도우이다. VOvideowatchdoc 41011은 videowatchview에 대응하는 도큐먼트 클래스이다.
프로그램밍 언어로서 비주얼 c++를 사용하는 일 실시 예에 있어서, cwind 41001은 cmdiframewnd 41005 서브클래스-1, cmdichildwnd 41006 서브클래스-2, cfromview 41007 서브클래스-3 및 cdialogbar 41002 서브클래스-4에 대한 상위 클래스이고, 따라서 cmdiframewnd 41005 클래스 오브젝트, cmdichildwnd 41006 클래스 오브젝트, cfromview 41007 클래스 오브젝트 및 cdialogbar 41002 클래스 오브젝트는 cwnd 41001 클래스로부터 속성을 계승한다. cmdiframewnd 41005는 VOMainframe 41009 서브클래스-1에 대한 슈퍼클래스이다; CMDIChildWND 41006은 VOCHILDFrme 41010 서브클래스-1에 대한 슈퍼클래스이다; CFromView 41007은 VOVideowatchVw 41013 서브클래스-1 및 VOConferenceVw 41014 서브클래스-2 양자에 대한 슈퍼클래스이다; 그리고 CDialogBar 41002는 VOALERTWnd 41015 서브클래스-1 및 VOScheduleWnd 41016 서브클래스-2 양자에 대한 슈퍼클래스이다. VOCHILDFrme 41010은 VOVideoWatchFrame 41017 서브클래스-1및 VOConferenceFrame 41018 서브클래스-2 양자에 대한 슈퍼클래스이다. CWinApp 41003은 VOConsoleApp 41008 서브클래스-1에 대한 슈퍼클래스이고 CDocument 41004는 VOVideoWatchDoc 41011 서브클래스-1 및 VOConferenceDoc 41012 서브클래스-2 양자에 대한 슈퍼클래스이다.
VOConsoleApp 41008은 하나의 VOMainframe 41009 part-1 클래스 오브젝트와 관련된 어셈블리 클래스이고, 따라서 정확히 하나의 VOMainframe 41009 오브젝트가 각 VOConsoleApp 41008 오브젝트에 관련되어 있다. VOMainframe 41009는 하나의 VOVideoWatchFrame 41017 part-1 클래스 오브젝트, 하나의 VOConferenceFrame 41018 파트-2 클래스 오브젝트, 하나의 VOALERTWnd 41015 파트-3 클래스 오브젝트 및 하나의 VOScheduleWnd 41016 파트-4 클래스 오브젝트와 관련되어 있는 어셈블리 클래스이고, 따라서 정확히 하나의 VOVideoWatchFrame 41017 오브젝트, 정확히 하나의 VOConferenceFrame 41018 오브젝트, 정확히 하나의 VOALERTWnd 41015 오브젝트 및 정확히 하나의 VOScheduleWnd 41016 오브젝트가 각 VOMainframe 41009 오브젝트에 관련되어 있다.
VOVideoWatchFrame 41017은 하나의 VOVideoWatchDoc 41011 파트-1 클래스 오브젝트 및 VOVideowatchVw 41013 파트-2 클래스 오브젝트와 관련된 어셈블리 클래스이고, 따라서 정확히 하나의 VOVideoWatchDoc 41011 오브젝트 및 정확히 하나의 VOVideowatchVw 41013 오브젝트가 각 VOVideoWatchFrame 41017 오브젝트에 관련되어 있다. 상술한 바와 같이 CDocument 41004로부터 확장되어지는 각 VOVideoWatchDoc 41011 오브젝트는 CFromView 41007 클래스 오브젝트로부터 확장되어지는 VOVideowatchVw 41013 오브젝트를 사용한다.
유사하게, VOConferenceFrame 41018은 하나의 VOConferenceDoc 41012 파트-1 클래스 오브젝트 및 하나의 VOConferenceVw 41014 파트-2 클래스 오브젝트와 관련되는 어셈블리 클래스이고, 따라서 정확히 하나의 VOConferenceDoc 41012 오브젝트 및 정확히 하나의 VOConferenceVw 41014 오브젝트가 각 VOConferenceFrame 41018 오브젝트와 관련되어 있다. VOConferenceDoc 41012는 VOConferenceVw 41014를 사용한다.
2. 클래스 및 오브젝트 상세
a) 사용자 인터페이스 클래스
(1) 클래스 리스트
VOConsoleApp 주 어플리케이션 클래스
VOMainFrame 다른 모든 윈도우를 가지고 있는 주 윈도우
VOScheduleWnd 오퍼레이터의 스케쥴을 디스플레이 하는 윈도우
VOOutputWnd 에러 메시지 및 경보가 디스플레이 되는 윈도우
VOChildFrame mdi 윈도우에 대한 프레임 윈도우. 이것은 각 뷰에 대한 주프레임처럼 실행된다.
VOConferenceFrame 회의 뷰에 대한 주 윈도우. 이것은 VOchildframe로부터 도출된다.
VOConferenceVw 회의 정보를 디스플레이 하는 윈도우
VOConferenceDoc VOconferencevw에 대응되는 도큐먼트 클래스.
VOVideoWatchFrame 영상 시각 뷰에 대한 프레임 윈도우. 이것은 VOchildframe로부터 도출된다.
VOVideoWatchVw 호출을 하기 위한 영상 흐름 및 제어를 디스플레이 하는 윈도우.
VOVideoWatchDoc 영상 시각 뷰에 대응되는 도큐먼트 클래스.
(2) 클래스 상세
(a) VOConsoleApp
클래스 VOConsoleapp
베이스 클래스 CWinApp
계승 타입 public
프랜드 클래스
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 서술 |
| protected | VOOperator* | m_pOperator | 영상 오퍼레이터에 로그된 것에 대한 포인터 |
(ii) 방식
Retcode CreateVideoOperator(CString login, CString password);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
로그인 파라미터: 오퍼레이터를 위한 로그인 id
패스워드 파라미터: 오퍼레이터의 패스워드.
retcode creativevideooperator 기능은 어플리케이션 개시동안 처음으로 호출된다.
Retcode InitializeCallSystemComponents();
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
retcode initializecallsystemcomponents 기능은 영상 오퍼레이터 생성 후에 어플리케이션 개시동안 처음으로 호출되는데, 상기 어플리케이션 개시는 내부 소프트웨어 시스템에 의하여 개시된 VOCallsysteminterface, VOCallogjmgr 및 VOconnectionobjmgr 오브젝트에 대한 포인터의 로컬 복사를 만든다.
void OnGetVOMessage(VOMsg VOMsg);
VOmsg 파라미터: 내부 소프트웨어 시스템에 의하여 전달된 메시지 오브젝트
void OnGetVOMessage 기능은 어플리케이션이 메시지를 적절한 윈도우로 리다이렉트(redirect)하기 위하여 내부 소프트웨어 시스템으로부터 메시지를 수신할 때 호출된다. 최초 실행에서, 상기 메시지는 VOmainframe으로 전달될 것인데, 상기 VOmainframe은 상기 메시지를 번역한다. 상기 메시지의 타입에 따라, 상기 메시지는 VOoutputwnd에서 디스플레이 되거나 메시지 상자에서 디스플레이 되거나 VOconferencevw 및 VOvideowatch 윈도우로 전달되거나 한다.
(b)VOMainFrame
클래스 VOMainFrame
베이스 클래스 CFrameWnd
계승 public
프랜드 클래스
(i) 속성
| 액세스레벨 | 타입 | 명칭 | 해설 |
| protected | VOOperator* | m_pOerator | 영상 오퍼레이터에 로그된 것에 대한 포인터 |
| VOScheduleWnd* | m_pScheduleWnd | 계획된 윈도우에 대한 포인터 | |
| VOOutputWnd* | m_pOutputWnd | 출력 윈도우에 대한 포인터 | |
| VOConferneceVw* | m_pConfVw | 회의 윈도우에 대한 포인터. 이것은 우리가 동일한 시간에 실행되는 다중 회의 윈도우를 가진다면 컬렉션(collection)이 될 것이다. | |
| VOVideoWatchVw* | m_pVideoWatchVw | 영상 시각 윈도우에 대한 포인터 |
(ii) 방식
Retcode synchWithDb();
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
로그인 파라미터: 오퍼레이터를 위한 로그인 id
패스워드 파라미터: 오퍼레이터의 패스워드
스케쥴이 변경되었고 데이터베이스와 동기에 일어날 필요가 경우, retcode synchwithdb 기능이 호출된다.
Retcode DisplayMessage(VOMsg VOMsg);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
vomsg 파라미터: 내부 소프트웨어 시스템으로부터 수신된 vomsg 오브젝트
retcode displaymessage 기능은 출력 윈도우에 vomsg 오브젝트의 컨텐트를 디스플레이 한다. severity에 기초하여, 또한 경보 상자도 디스플레이 된다.
void OnConferenceStatusChanged(VOConference*pConference);
pconference 파라미터: 상태가 변경된 회의 오브젝트에 대한 포인터
void OnConferenceStatusChanged 기능은 특정 회의가 변경될 때 호출된다.
(c) VOschedulewnd
클래스 VOScheduleWnd
베이스 클래스 CDialogBar
계승 타입 public
프랜드 클래스
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| VOMainFrame* | m_pMainframe | 주프레임 윈도우에 대한 포인터 | |
| VOSchedule* | m_pSchedule | 영상 오퍼레이터의 스케쥴에 대한 포인터 |
(ii) 방식
Retcode DisplaySchedeule(BOOL filter =0);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
필터 파라미터: 스케쥴의 디스플레이에 적용되는 필터. 필터+0 은 전체 스케쥴을 디스플레이 한다. 필터=1은 단지 능동 회의 및 재생 호출만을 디스플레이 한다.
retcode displayschedule 기능은 스케쥴 윈도우에 회의 및 재생 호출의 리스트를 디스플레이하기 위하여 호출된다.
Retcode DisplayConfSites(VOConference*pConference);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
pconference 파라미터: 사이트는 회의 오브젝트를 위하여 스케쥴 윈도우의 사이트 리스트 상자에 디스플레이 되어야 하는데, 상기 회의 오브젝트에 대한 포인터.
retcode displayconfsites 기능은 스케쥴 윈도우의 사이트 리스트 상자에서 사이트의 리스트를 디스플레이하기 위하여 호출된다.
Retcode OnClickScheduledItem();
복귀값: 선택이 이전 선택과 다른 경우 0이 아닌 숫자를 복귀시킨다. 그렇지 않은 경우 0을 복귀시킨다.
retcode onclickscheduleditem 기능은 사용자가 스케줄 리스트 상자에서 한 항목을 클릭 할 때, 호출된다. 개시 실행은 회의 또는 사이트에 대응 사이트를 디스플레이하고 재생 호출에 무비 상세를 디스플레이 한다.
Retcode OnDblClickScheduledItem();
복귀값: 회의 윈도우가 열리는 경우 0이 아닌 숫자를 복귀시킨다. 그렇지 않으면 0을 복귀시킨다.
retcode ondblclickscheleduditem 기능은 사용자가 스케쥴 리스트 상자에서 한 항목을 더블 클릭 할 때 호출된다. 최초 실행은 계획된 항목을 위하여 새로운 VOconferencevw를 생성한다.
Retcode OnClickSite();
복귀값: 선택이 이전 선택과 다른 경우 0이 아닌 숫자를 복귀시킨다. 그렇지 않은 경우 0을 복귀시킨다.
(d) VOoutputwnd
클래스 VOOutputWnd
베이스 클래스 CDialogBar
계승 타입 public
프랜드 클래스
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| protected | VOMainframe* | m_pMainframe | 주프레임에 대한 포인터 |
(ii) 방식
Retcode DisplayMessage(CString info, VOMsg*pVoMsg=NULL);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키다. 그렇지 않은 경우 0을 복귀시킨다.
info 파라미터: 디스플레이 되는 추가적인 정보
pVOmsg 파라미터:VOmsg 오브젝트에 대한 포인터
retcode displaymessage는 출력 윈도우에 메시지 텍스트를 디스플레이 한다. pvomsg=null인 경우, 오직 상기 정보만이 디스플레이 된다.
(e) VOconferencevw
클래스 VOConferenceVw
베이스 클래스 CFormView
계승 타입 public
프랜드 클래스
(i) 속성
| 액세스레벨 | 타입 | 명칭 | 해설 |
| protected | VOOperator* | m_pOperator | 영상 오퍼레이터에 로그된 것에 대한 포인터 |
| VOMainFrame* | m_pMainframe | 주프레임 윈도우에 대한 포인터 | |
| VOVideoWatchVw* | m-pVideoWatchVw | 영상 시각 윈도우에 대한 포인터 | |
| VOOutputWnd* | m_pOutputWnd | 출력 윈도우에 대한 포인터 |
(ii) constructor(s)
protected VOConferneceVw();
VOConferenceVw(VOConference*pConference);
VOConferenceVw(VOPlaybackSession*pPbSession);
pconference 파라미터: 뷰는 회의 오브젝트를 위하여 생성되는 것인데, 상기 회의 오브젝트에 대한 포인터.
pPbsession 파라미터: 뷰는 재생 세션 오브젝트를 위하여 생성되는 것인데, 상기 재생 세션 오브젝트에 대한 포인터.
회의 뷰는 어떠한 회의 또는 계획된 재생 세션에 관한 정보를 디스플레이 하는데 사용된다. 상기 뷰는 사용자가 스케쥴 윈도우에서 회의/재생 세션을 더블 클릭 할 때 주프레임만에 의해서 생성된다.
(iii) 방식
(VOConference*pConference);
pconference 파라미터: 상태가 변경되는 회의 오브젝트에 대한 포인터.
void onconferencestatuschanged는 ui가 적절히 갱신될 수 있게 하기 위하여 회의 상태가 변경될 때 호출된다.
void OnPbSessionStatuschanged(VOPlaybackSession*pPbSession);
ppbsession 파라미터: 상태가 변경되는 재생 세션 오브젝트에 대한 포인터.
void onpbsessionstatuschanged는 ui가 적절히 갱신될 수 있게 하기 위하여 재생 세션의 상태가 변경될 때 호출된다.
void OnConnStatusChanged(VOConnection*pConnection)
pConnection 파라미터: 상태가 변경되는 접속 오브젝트에 대한 포인터.
void onconnectionstatuschanged는 ui가 적절히 갱신될 수 있게 하기 위하여 접속의 상태가 변경될 때 호출된다.
void OnCallStatusChanged(VOCall*pCall);
pCall 파라미터: 상태가 변경되는 재생 세션 오브젝트에 대한 포인터.
void oncallstatuschanged는 ui가 적절히 갱신될 수 있게 하기 위하여 현 회의/재생 세션의 상태가 변경될 때 호출된다.
void OnPbCallStatusChagned(VOPbCall*pPbCall);
ppbcall 파라미터: 상태가 변경되는 재생 세션 오브젝트에 대한 포인터.
void onpbcallstatuschanged는 ui가 적절히 갱신될 수 있게 하기 위하여 재생 세션의 상태가 변경될 때 호출된다.
(VOConnection*pConnection);
pConnection 파라미터: 상태가 변경되는 접속 오브젝트에 대한 포인터.
void displayconnectionstatus는 접속의 상태를 디스플레이하기 위하여 호출된다.
void displayCallStatus(VOCall*pCall);
pcall 파라미터: 상태가 변경되는 호출 오브젝트에 대한 포인터.
void displaycallstaus는 호출의 상태(참가자 또는 mcu)를 디스플레이하기 위하여 호출된다.
void DisplayRecordingStatus(); 회의의 어떠한 호출이 기록되고 있는 경우, 기록 상태를 디스플레이하기 위하여 호출된다.
void displayWatchStatus();현 회의 또는 재생 세션에서 어떠한 호출이 검사되고 있는가에 관한 지시를 디스플레이하기 위하여 호출된다.
void displayPlaybackstatus();재생 세션을 디스플레이하기 위하여 호출된다.
Retcode OnDialSite();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode ondialsite는 참가자 측의 다이얼 버튼이 클릭 될 때 호출된다. 이것은 선택된 접속의 참가자를 다이얼 호출할 것이다.
Retcode OnDiaIMC();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode ondialmcu는 mcu측의 다이얼 버튼이 클릭 될 때 호출된다. 이것은 선택된 참가자에게 할당된 mcu 포트를 다이얼 호출할 것이다.
Retcode OnHangupSite();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode onhangupsite는 참가자에게 상기 호출을 행업한다.
Retcode OnHangupMCU();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode onhangupmcu는mcu에게 상기 호출을 행업한다.
Retcode OnHoldSite();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onholdsite 기능은 참가자를 보류 상태에 둔다(상기 호출이 능동 상태인 경우).
Retcode OnHoldMCU();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onholdmcu 기능은 상기 mcu를 보류 상태에 둔다(상기 호출이 능동 상태인 경우).
Retcode OnWatchSite();
복귀값: 성공적이면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onwatchsite 기능은 현 참가자를 검사할 것이다. 참가자에 대응되는 영상 흐름은 영상 시각 윈도우에 디스플레이 될 것이다.
Retcode OnWatchMCU();
복귀값: 성공적이면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onwatchmcu는 회의에서 참가자에 대응되는 mcu leg를 검사하는 것을 개시한다. 영상 흐름은 영상 시각 윈도우에 디스플레이 된다.
Retcode OnRecordMCU();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onrecordmcu는 mcu 흐름의 기록을 개시한다. 기록이 이미 진행중이면 상기 기능은 기록을 중지/종료시킬 것이다.
Retcode OnRecordSite();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode Onrecordsite는 선택된 참가자에 대응하는 흐름의 기록을 개시한다. 기록이 이미 진행중이면 기록은 정지/종료될 것이다.
Retcode MakeAutoConnection();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode makeautoconnection은 참가자 및 mcu를 자동으로 접속하기 위하여 호출되고 성공할 때는 그것들을 결합한다.
Retcode MakeAutoDisconnection();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode makeautodisconnection은 참가자 및 mcu로의 호출을 자동으로 분리시키고 단절시키기 위하여 호출된다.
Retcode ConnectAll();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode connectall은 하나씩 자동적으로 모든 접속을 하기 위하여 호출된다.
Retcode DisconnectAll();
복귀값: 오퍼레이션이 성공적으로 개시되면 0이 아닌 숫자를 복귀시키고, 그렇지 않으면 0을 복귀시킨다.
retcode disconnectall은 모든 회의 접속을 자동적으로 차단하기 위하여 호출된다.
(f) VOVideoWatchVw
클래스 VOMainFrame
베이스 클래스 CFrameWnd
계승 타입 public
프랜드 클래스
(i) 속성
| 액세스 레벨 | 타입 | 명칭 | 설명 |
| protected | VOOperator* | m_pOperator | 영상 오퍼레이터에서 로그된 것에 대한 포인터 |
| VOCallObjMgr* | m_pCallMgr | 호출 오브젝트 관리자에 대한 포인터 | |
| VOScheduleWnd* | m_pscheduleWnd | 스케쥴 윈도우에 대한 포인터 |
(ii) construction(s)
VOVideoWatchVw();
(iii) 방식
void OnDial(); 착신지 편집 상자에서 번호를 다이얼 호출한다.
void OnTransfer(); 현 호출을 번호로 전송한다. 이것은 사용자가 호출이 전송되는 number top을 입력시키는 곳인 대화상자를 처음에 디스플레이 한다.
void OnAnswer();응답 버튼이 클릭 될 때 호출된다.
void OnForward();전달 버튼이 클릭 될 때 호출된다. 모든 호출은 제공된 전달 번호로 전달될 것이다.
void OnMute(); 무성 버튼이 클릭 될 때 호출된다. 무성을 키거나 끈다.
void OnHngup();행업 버튼이 클릭 될 때 호출된다. 현 호출을 행업한다.
void OnHold();보류 버튼이 클릭 될 때 호출된다. 현 호출을 보류 상태에 둔다.
void OnPrickup(); 포착 버튼을 클릭 할 때 호출된다. 보류 상태의 호출을 포착한다.
void OnPrivacy();프라이버시 버튼이 클릭 될 때 호출된다. 프라이버시를 키거나 끈다.
void OnPlayMovie(); 작동 버튼이 클릭 될 때 호출된다. 이것은 선택된 무비의 리스트를 가지는 대화 상자를 디스플레이 할 것이다. 일단 무비가 선택되면 상기 무비는 작동될 것이다.
void OnRecordCall();기록 버튼이 클릭 될 때 호출된다.
void OnJoinToConference();join confbutton이 클릭 될 때 호출된다. 이것은 능동 회의 및 사이트 리스트 또는 재생 세션을 디스플레이 할 것이다. 오퍼레이터는 현 호출에 대응하는 사이트를 선택할 것이고 상기 호출은 회의에 결합될 것이다.
void WatchVideo(BOOL selection);
복귀값: 성공적인 경우 0이 아닌 숫자를 복귀시키고, 그렇지 않은 경우 0을 복귀시킨다.
선택 파라미터: 무엇을 보아야 하는지를 상세히 설명한다.
선택: VDOWATCH_CONFERENCE는 보기 위하여 선택된 사이트/mcu로부터의 영상을 디스플레이 한다.
선택:VDOWATCH_SELF는 영상 오퍼레이터의 카메라의 출력을 디스플레이 한다.
선택: VDOWATCH_CALL은 영상 시각 윈도우에 제공된 리스트 상자로부터 선택된 호출로부터의 영상 또는 가능하다면 입중계 호출로부터의 영상을 디스플레이 한다.
보기 위한 영상 흐름을 선택하기 위하여 void watchvideo 기능을 호출한다.
void OnDisplay Callswindow();'호출' 버튼이 클릭 될 때 호출된다.
void OnSelfView(); 'selfview'검사 상자가 첵크 되거나 체크되지 않을 때 호출된다. selfview 가 체크될 때, 영상 오퍼레이터의 카메라 출력이 분리 소 윈도우에 디스플레이 된다.
void OnLocalVolume();로컬 볼륨 슬라이드 바 포지션(local volume slide bar position)이 변경될 때 호출된다. 이것은 로컬 볼륨을 조절할 것이다.
void OnRemoteVolume(); 원격 볼륨 슬라이드 바 포지션이 변경될 때 호출된다. 이것은 원격 볼륨 신호를 조절할 것이다.
b) 미디어 제어 클래스 해설
(1) vomediacontrol
클래스 VOMediaControl
베이스 클래스 VOObject
계승 타입 public
프랜드 클래스
(a) 속성
| 액세스 레벨 | 타입 | 명칭 | 해설 |
| protected | struct MtsLinkPortInfo | m_portInfo | 상기 구조는 mcp와 통신에 사용된다. |
(b) constructor(s)
VOMediaControl();
(c) 방식
public void SetVolume(short rightVolume,shorleftVolume);
우측 볼륨 파라미터: 0-1000 사이의 정수.
좌측 볼륨 파라미터: 0-1000 사이의 정수.
public void setvolume은 볼륨 제어를 설정한다.
public short GetVolume(short channel);
복귀값: 구체적인 채널에 대한 볼륨을 복귀시킨다.
채널 파라미터: 우측 볼륨 세팅을 위하여 채널=PORT_CHANNEL_RIGHT를 설정하고 좌측의 볼륨 세팅을 위하여 채널=PORT_CHANNEL_LEFT를 설정한다.
public short getvolume은 구체적인 채널에 대한 현 볼륨을 복귀시킨다.
public void SetSeIfView(long flags);
flags 파라미터: self view의 상태 량을 설정한다. 유효한 플래그는 다음과 같다.
SELFVIEW_ON 셀프 뷰를 디스플레이 한다;
SELFVIEW_OFF 셀프 뷰를 숨긴다; 그리고
SELFVIEW_MIRRORED 셀프 뷰를 경영(mirror)한다.
public void setselfview는 셀프 뷰 상태 량을 설정한다.
public long GetSelfview();
복귀 값:셀프 뷰 세팅을 복귀시킨다.
public long getselfview 기능은 셀프 뷰가 보이는지 또는 감추어져 있는지 또는 경영되어 있는지를 찾아내는데 사용될 수 있는 셀프 뷰 세팅을 복귀시킨다.
public void SetselfViewSize(short size);
사이즈 파라미터: 셀프 뷰에 대한 미리 규정된 사이즈중의 하나.
public void setselfviewsize는 셀프 뷰 윈도우의 사이즈를 설정한다. 유효한 값은 FULL_CIF, HALF_CIF 및 QUARTER_CIF이다.
public short GetSelfViewsize();
복귀값: 현 셀프 뷰 사이즈를 복귀시킨다.
public short getselfviewsize 기능은 현 셀프 뷰 윈도우 사이즈를 복귀시킨다. 값은 미리 규정된 사이즈 값 중의 하나이다. 사이즈의 해설을 위하여 setselfviewsize를 보라.
public void SetAutoGain(BOOL autoGain=TRUE);
autogain 파라미터: 자동 게인(gain)을 가능하게 하기 위해서는 true가 되어야 하고, 불가능하게 하기 위해서는 false가 되어야 한다.
public void setautogain 기능은 자동 게인 값에 의존하는 자동 게인을 하게 하거나 하지 못하게 한다.
public BOOL GetAutoGain();
복귀값: 현 자동 게인 세팅을 복귀시킨다.
public bool getautogain 기능은 현 자동 게인 세팅을 복귀시킨다. 자동 게인이 진행되면 true, 그렇지 않으면 falserk 된다.
pubilc void SetEchoCancellation(bool bCancel);
bcancel 파라미터: bcancel이 true이면 취소가 가능하고; false이면 취소는 불가능하다.
public void setechocancellation은 에코 취소를 가능 또는 불가능하게 한다.
public BOOL GetEchoCancellation();
복귀값: 현 에코 취소 상태를 복귀시킨다.
public bool getechocancellation은 현 에코 취소의 현 상태를 획득한다.
public BOOL GetechoCancellation
public short GetVideoMode(short mode=MODE_RX);
복귀값: 영상 모드를 복귀시킨다.
모드 파라미터: 수신 또는 전송 모드를 표시한다.
public short getvideomode는 모드 값에 의존하는 수신 또는 전속을 위한 음성 모드를 획득한다. 수신을 위하여는 모드=MODE_RX 그리고 전송을 위하여는 모드=MODE_TX.
public short GetAudioMode(short mode=MODE_RX);
복귀값: 음성 모드를 복귀시킨다.
모드 파라미터: 수신 또는 전송 모드를 표시한다.
public short getaudiomode는 모드 값에 의존하는 수신 또는 전송을 위한 음성 모드를 획득한다. 수신을 위하여는 모드=MODE_RX 그리고 전송을 위하여는 모드=MODE_TX이다.
public void SetVideoWnd(HWND hWnd);
hwnd 파라미터: 영상이 디스플레이 되는 윈도우에 대한 포인터.
public void setvideownd 기능은 hwnd에 의하여 식별되는 윈도우에 영상을 디스플레이 한다.
public HWND GetVideo Wnd();
복귀값: 영상이 디스플레이 되고 있는 윈도우 핸들(handle)을 복귀시킨다. 어떠한 윈도우도 설정되어 있지 않으면, null이 복귀된다.
public hwnd getvideownd 기능은 영상이 디스플레이 되고 있는 윈도우 핸들을 검색하기 위하여 호출된다.
public void MakeeVideoWndResizeable(BOOL bResize=TRUE);
bresize 파라미터:bresize가 true이면, 영상 윈도우는 사이즈 변경이 가능하다; false이면, 사이즈 변경이 불가능하다.
public void makevideowndresezeable 기능은 bresize=true이면 영상 윈도우를 사이즈 변경이 가능하게 한다. 상기 윈도우를 고정 사이즈로 만들기 위해서는 bresize를 false로 한다.
public BOOL IsVideoWndResizeable();
복귀값: 영상 윈도우가 사이즈 변경이 가능하면 true를 복귀시키고 그렇지 않으면 false를 복귀시킨다.
영상 윈도우가 사이즈 변경이 가능한 지를 결정하기 위하여 public bool isvideowndresizeable 기능을 호출한다.
F. 영상 오퍼레이터 공유 데이터베이스
1.데이터베이스 스키마(Schema)
도 107은 영상 오퍼레이터 공유 데이터베이스에 대한 데이터베이스 스키마를 보여준다(도 98의 40214 참조). 일 실시 예에서, 데이터베이스는 다음의 표를 포함한다. 회의 41104는 계획된 회의에 관한 상세를 리스트하며 참가자 41105는 회의 참가자를 리스트하고 CON_PARTCIPANT 41108은 회의 41104 및 참가자 41105 표로부터의 키이를 포함하고 있는데, 그것은 어떠한 주어진 회의의 참가자를 결정하는데 사용된다. MCU 41102는 다양한 제공자로부터의 다른 MCU의 특성을 포함하고 있고, MCUPORT 41106은 회의에 접속하기 위하여 참가자에 의하여 사용되는 MCU의 포트뿐 아니라 MCU 41102로부터의 MCU 식별 번호를 포함하고 있다. VOPERATOR은 영상 오퍼레이터 속성을 리스트 한다; VOTYPES는 회의 또는 참가자들을 규정하는데 사용되는 모든 타입을 리스트 한다: 그리고 VOTYPE VALUES 41107은 각각의 규정된 타입에 대한 값을 리스트 한다.
VDO_OPERATOR 41101 표에서의 각 영상 오퍼레이터 기록은 각 영상 오퍼레이터를 회의 41104 표에 개략적으로 서술된 특정 회의에 할당하는 그 ID 필드에서 고유 식별 번호를 포함하고 있는데 상기 번호는 회의 41104 표의 오퍼레이터ID 필드에 나타날 수 있다. 상기 회의 41104 표에서의 각 회의 기록은 차례로 그 ID 필드에서 고유한 식별 번호를 포함하고 있는데, 상기 번호는 CONF_PARTICIPANT 41108 표의 confID 필드에서 나타날 수 있다. 유사하게 상기 참가자 41105 표에서의 각 참가자 기록은 그 ID 필드에서 고유 식별 번호를 포함하는데, 상기 번호는 CONF_PARTICIPANT 41108 표의 참가자ID 필드에 나타날 수 있다. 마지막으로 MCU 41102 표에서의 각 MCU 기록은 MCU와 관련된 MCU 포트 세트를 식별하는 그 ID 필드에서 고유 식별 번호를 포함하고 있는데, 상기 번호는 MCUPORT 41106 표의 mcuID 피드에 나타날 수 있다. MCUPORT 41106 표에서의 각 MCU 포트 기록은 차례로 그 ID 필드에서 고유식별 번호를 포함할 수 있는데, 상기 번호는 CONF_PARTICIPANT 41108 표의 mcuPortID 필드에서 나타날 수 있다. CONF_PARTICIPANT 41108 표 내에서의 confID, 참가자ID, 및 mcuPortID 값은 특정 회의를 주어진 회의 프로파일, 참가자 세트 및 MCU 포트로 규정하기 위하여 교차-참조 키이로 사용된다.
또한 VOTYPE 41103 표에서의 각 VOType 기록은 VOType에 관련된 수치 세트를 식별하는 그 ID 필드에서 고유 식별 번호를 포함하는데, 상기 번호는 VOTYPEVALUE 41107 표의 typeID 필드에 나타날 수 있다.
G. 영상 오퍼레이터 콘솔 화상 사용자 인터페이스 윈도우
1. 메인 콘솔 윈도우
도 108은 영상 오퍼레이터 터미널[도 96의 1]에 나타나는 바와 같이 메인 콘솔 윈도우 41201의 일 실시 예를 보여주는데, 상기 실시 예는 스케쥴 윈도우 41201, 회의 윈도우 41203, 영상 시각 윈도우 41204 및 콘솔 출력 윈도우 41205의 가능한 배치를 보여 준다. 메인 콘솔 윈도우 41201은 영상 오퍼레이터가 영상 회의를 관리할 수 있게 한다.
2. 스케쥴 윈도우
도 109는 스케쥴 윈도우 41202의 일 실시 예를 보여 주는데, 상기 스케쥴 윈도우는 다음 8 시간 동안 현 영상 오퍼레이터에 의하여 조정되는 모든 회의 41305 및 재생 세션 41306을 디스플레이 한다. 일 실시 예에서는 리스트가 어플리케이션 개시와 동시에 갱신되고 15분의 인터벌을 갖고 그리고 매 시간 회의는 종료한다.
상기 스케쥴 윈도우는 두 개의 스크롤드 텍스트 영역(scrolled text area)을 가질 수 있는데- 하나는 회의 41301을 위한 것이고 , 다른 하나는 선택된 회의에 참가하는 사이트 41302를 위한 것이다. 회의 명이 더블 클릭되면 적절한 회의 윈도우[도 108, 110의 4123]이 나타날 것이다.
3. 회의 윈도우
도 110은 회의 윈도우 41203의 일 실시 예를 보여 주는데, 상기 회의 윈도우 41203을 오퍼레이터가 스케쥴 윈도우 41202에서 회의 또는 재생 세션을 선택 할 때 디스플레이 된다. 회의 윈도우 41203의 디스플레이는 회의 또는 재생 세션이 스케쥴 윈도우 41202로부터 선택되는지 여부에 의존한다. 한 번에 오직 하나의 회의 윈도우만이 디스플레이 된다. 새로운 회의 윈도우가 열릴 때 현재의 윈도우는 숨겨진다. 회의 윈도우가 숨겨 질때도 회의 및 접속 상태는 여전히 검사된다. 도 110은 회의 세션 41401을 보여 준다. 회의 윈도우 41203은 호출 설정, 보기, 재생 및 기록을 포함하는 개별 접속을 선택적으로 작동하는 라디오 버튼 및 회의 참가자 41415의 리스트를 디스플레이 한다.
지속 시간, 시작 시간, 종료 시간, 재생 및 기록 상태와 같은 회의에 관한 정보와 회의 타입이 윈도우의 하단에 디스플레이 된다. 오퍼레이터가 클릭킹 로케이션과 관련된 실행이 없는 회의 윈도우 41203 내부에서 더블 클릭 하면 상태량 상자[도 113의 41701]이 회의 세팅에 디스플레이 된다.
회의는 종료 회의 버튼을 누름으로써 종료된다. 이는 회의에 관련된 모든 호출을 단절 시킬 것이다.
상기 회의 윈도우 41203은 회의에서의 접속 및 아직 결합되지 않은 접속 41421을 위하여 예약된 어떠한 자유 MCU 포트 슬로트를 포함하는 그들의 접속 상태 41417을 디스플레이 한다.
각 접속 리스팅은 라디오 버튼 41422, 참가자 사이트명 41423 및 상태 등 41418-41420을 포함한다. 두 개의 호출 상태 및 결합은 회의 윈도우 41203에서 사이트명과 함께 검사되고 디스플레이 된다. 상태 상자 41418-41420은 채색 상자인데, 다른 색깔은 다른 호출 상태(예를 들면 무호출, 진행중의 호출, 능동 호출 또는 단절된 호출 능동 호출)를 표시한다.
상기 회의 윈도우 41203은 참가자 사이트가 MCU 포트사이트에 접속되고 영상 오퍼레이터를 통하여 경로 지정되는 순서를 규정하는 41417을 클릭하기 위하여 버튼을 설치하고 있다. 윈도우의 상기 부분으로부터 사용될 수 있는 다른 특징은 호출로부터 영상 입력을 감시하고 어느 한 호출로부터 영상 입력을 기록하고 정규 영상 호출을 참가자 사이트 또는 MCU에 하는 것이다.
화살표 41424의 색깔은 각 호출의 상태를 표시한다. 상기 화살표의 색깔은 접속 리스트에서 상태등 41418-41420에 또한 복제된다.
회의와 관련된 재생 접속 41425가 있다면, 오직 하나의 호출만이 MCU 포트 사이에 필요하다. 정규 참가자 사이트 호출 셋업 인터페이스는 액세스 할 수 없을 수 있고 결합 제어 41405가 재생을 위한 개시 및 정지 스위치가 될 수 있다.
자유 MCU 포트는 규정된 접속을 위한 MCU 포트 호출이 휴지(또는 단절)될 때만 도달될 수 있다. 이는 상기 오퍼레이터가 참가자인 것처럼 회의에 결합하는 것을 허용한다. 이는 자유 MCU 포트 호출과의 접속을 선택함으로써 달성된다. 접속될 때 상기 오퍼레이터는 나머지 참가자들에게 상기 오퍼레이터가 접촉 또는 접속의 회복을 시도하고 있음을 알릴 수 있다.
상기 회의 윈도우 41203의 반영할 수 있는 어떠한 기능적 제한이 있다. 상기 회의 윈도우 41203은 실행될 수 없는 기능으로의 액세스를 허용해서는 안 되는데, 예를 들면
·영상 오퍼레이터는 한번에 하나의 호출을 뷰(view)만 할 수 있다.
·영상 오퍼레이터는 소프트웨어 단-방향 디코더에 어떠한 시간에 어떠한 호출을 기록 할 수 있다.
·재생 접속 선택은 호출 셋업 버튼을 적절히 바꾼다.
·영상 오퍼레이터는 MCU 포트 호출이 휴지 상태일 때만 회의에 참가 할 수 있다.
·영상 오퍼레이터는 참가자가 단절 상태일 때만 참가자 사이트와 이야기 할 수 있다.
간단히 말하면, 상기 회의 윈도우를 사용하는 단순한 접속이 다음과 같이 진행한다. 참가자 사이트 상자 41402 가까이에 있는 호출 버튼을 누름으로써, 오퍼레이터는 아담(또는 선택적으로 아담이 오퍼레이터를 호출할 수도 있다)을 호출하고 그리고 나서 상기 오퍼레이터는 호출을 보류 41407 상에 배치한다. MCU 포트 사이트 상자 41403 가까이에 있는 호출 버튼을 누름으로써 상기 오퍼레이터는 상기 MCU를 호출하고 그리고 나서 상기 호출을 보류 41408 상에 배치한다. 결합 버튼 41405를 누름으로써 두 개의 호출은 결합된다. 또 다른 실시 예에 따르면, 상기와 같은 것은 수동 프로세스보다는 자동 프로세스가 될 수 있다. 아담과 상기 MCU는 이제 H.320 영상 호출로서 접속된다. 세 개의 모든 화살표 41424는 녹색이 될 것이다.
4. 영상
도 111은 영상 시각 윈도우 41204의 일실시 예를 보여주는데, 상기 윈도우 41204는 선택된 회의 접속의 호출 또는 분리된 입중계 또는 출중계 호출으로부터의 H.320 입력을 디스플레이 한다. 상기 영상 시각 윈도우 41204는 또한 정규 호출을 하기 위한 제어 41512 및 음성 제어 41509-41510과 같은 미디어 제어기를 가지고 있다.
상기 영상 시각 윈도우는 선택된 호출의 영상 출력의 단방향 H.320 디코드를 위한 디스플레이이다. 디폴트에 의하여 첫 번째 능동 사이트의 MCU 호출이 디스플레이 될 것이다. 어떠한 다른 호출을 뷰하기 위하여 적절한 뷰 버튼이 회의 윈도우에서 눌러져야 한다. 볼륨(volume) 제어 41509-41510, 그림 크기 41511 등과 같은 상기 윈도우를 위한 영상 및 음성 제어는 영상 제어 패널(panel)로부터 관리된다.
상기 오퍼레이터가 능동 회의에서 사이트 또는 사용 가능한 슬로트에 정규 H.320 영상 호출을 할 것을 결정할 때, 상기 영상 시각 윈도우 41204가 영상을 뷰하기 위하여 사용된다. 소형 셀프-뷰 영상 윈도우는 상기 오퍼레이터가 셀프 뷰 버튼 41506을 선택할 때 가까이 나타나야 한다.
5.콘솔 출력 윈도우
도 112는 모든 에러 메시지 및 경보 41601을 디스플레이 하는 콘솔 출력 윈도우 41205의 일 실시 예를 보여 준다. 상기 윈도우는 영상 오퍼레이터가 현 세션에서 발생하는 모든 에러를 볼 수 있도록 스크롤할 수 있다. 상기의 메시지들은 또한 장래의 참조를 위하여 텍스트 파일로 로그 된다.
6. 상태량 대화 상자
도 113은 상태량 대화 상자 41701을 보여 준다. 대화 상자는 과도기적이고 오직 임시적으로만 디스플레이 되는 윈도우이다. 상기 윈도우는 일반적으로 즉각적인 주의를 요하는 데이터 또는 표시 정보를 입력하기 위하여 사용된다. 이 것은 특정 회의 또는 사이트의 상태량을 디스플레이 하는 무방식의 대화 상자일 수 있다. 언제든지 단 하나의 그러한 윈도우가 열릴 수 있다. 상기 사용자가 또 다른 회의 윈도우 또는 접속 윈도우에 포커스를 맞추면, 동일한 대화 상자가 적절한 상태량과 함께 갱신된다. 도 113은 사이트 코디네이터 41702, 사이트 전화번호 41703, 시간 41704, 접속 타입 41705 및 터미널 타입 41706을 포함하는 특정한 사이트와 관련된 상태량을 도시한다. 닫힘 버튼 41707은 상태량 대화 상자 41701을 닫는다.
XVII. WORLD WIDE WEB(WWW) BROWSER CAPABILITIES
A. 사용자 인터페이스
화상 사용자 인터페이스는 워크스테이션으로부터 서버로의 단일 IP 만이 요구되도록 설계되어 있다. 상기 단일 IP 접속은 WWW 브라우저 및 WWW 사이트 사이의 인터넷 접속과 PC 클라이언트 및 유니버설 인박스(즉 메시지 센터) 사이의 메시지 접속 양자를 지원한다. PC 클라이언트 인터페이스는 WWW 브라우저 인터페이스에 통합되고 따라서 양 구성 요소는 두 개의 어플리케이션 사이에 상충됨이 없이 동일한 워크스테이션에 존재할 수 있고 단일 IP 접속을 공유할 수 있다.
WWW 브라우저 액세스는 어떠한 상업적 사용 가능한 WWW 브라우저 인터페이스로부터 지원된다:
·마이크로소프트 인터넷 익스플로러;
·넷츠스케이프 네비게이터 (1.2,2.X); 또는
·Spyglass Mosaic.
또 상기 WWW 브라우저 인터페이스는 윈도우 95를 지원하는데 최적화되어 있다; 그러나 윈도우 3.1 및 윈도우 3.11도 마찬가지로 지원된다.
상기 WWW 브라우저 인터페이스는 사용자의 워크스테이션의 디스플레이 특징을 검출하고 상기 워크스테이션의 디스플레이 세팅은 지원하는 프리젠테이션을 채택한다. 상기 프리젠테이션은 640x480 픽셀 디스플레이 주변에서 최적화되나 또한 800x600(그 이상도) 모니터의 강화된 해상도 및 디스플레이 질을 이용할 수 있다.
실행을 개선하기 위하여 상기 사용자는 '극소 화상' 또는 '전면 화상' 프리젠테이션을 선택할 수 있다. 상기 WWW 브라우저는 사용자가 '극소 화상' 또는 '전면 화상'을 선택하였는지 여부를 검출할 수 있고 적절한 화상 파일만을 송신할 수 있다.
B. 성능
상기 WWW 사이트 또는 퍼스널 홈페이지로부터 상기 사용자의 워크스테이션 또는 터미널로의 정보 다운로드에 소요되는 응답시간은 다음의 벤치마크를 충족한다.
워크스테이션 구성배치:
-프로세서: 486DX-33MHz;
-메모리: 12MB;
-모니터:VGA, Super VGA 또는 XGA;
-액세스: 다이얼업;
-윈도우 95;
-프리젠테이션 옵션; Full Graphics; 그리고
-주번 기기: 음성 카드, 음성 플레이어 소프트웨어, 14.4Kbs 모뎀
| 요구 조건 | 평균치 | NOT TO EXCEED VALUE |
| 검색 및 퍼스널 홈 페이지. 시간은 상태 표시줄 이 "Document: Done"라 나타날 때까지 사용자가 북마크를 선택할 때로부터 측정된다. | 20초 | 30초 |
| 홈 페이지 이외의 WWW 스크린의 검색. 시간은 상태 표시줄 이 "Document: Done"라 나타날 때까지 사용자가 하이퍼 텍스트 링크 또는 탭을 선택할 때부터 측정된다. | 5초(텍스트만인 경우)또는15초(스케쥴링 스크린) | 5초(텍스트만인 경우)또는30초(스케쥴링 스크린) |
| 음성메일 메시지의 작동을 개시. 시간은 유동 음성 파일이 사용자의 워크스테이션 상에서 playing을 시작하기까지 사용자가 메시지 센터에서 음성 메시지를 선택할 때부터 측정된다. | 10초 | 15초 |
스크린 또는 페이지가 WWW 사이트로부터 워크스테이션으로 다운로드된 후 첫 번째 요구되는 필드 또는 갱신될 수 있는 필드 상에 미리 위치한다.
C. 퍼스널 홈페이지
상기 시스템은 가입자에게 통신하는 사람 또는 가입자와의 스케쥴 미팅을 위한 전달 수단을 제공하는 퍼스널 홈페이지를 설정할 수 있는 능력을 제공한다. 가입자의 퍼스널 홈페이지에 액세스하는 사람은 게스트로 언급되고 퍼스널 홈페이지를 가지는 사용자는 가입자로 언급된다.
퍼스널 홈페이지로의 게스트-액세스는 다음의 특징을 지원할 것이다:
·네트워크MCI 페이징을 통하여 텍스트에 기초하는 페이저를 생성하고 송신한다;
·이메일(MCI 메일 또는 인터네MCI) account로 이메일 메시지를 생성하고 송신한다; 그리고
·미팅을 계획하기 위하여 가입자의 캘린더로 액세스한다.
가입자의 퍼스널 홈페이지 통하여 만들어진 메시지는 가입자의 네트워크MCI 또는 SkyTel Pager 또는 MCI 이메일 어카운트로 향한다.
게스트에 의하여 구성된 이메일은:
·이메일 header에 가입자의 이메일 어드레스가 아닌 가입자명을 나타낼 것이다;
·다음을 위하여 이메일 헤더에 필드를 제공할 것이다:
-송신자명(요구되는 필드)
-송신자의 이메일 어드레스(선택적 필드), 그리고
-주제(선택적인 필드).
게스트는 가입자의 퍼스널 홈 페이지 상에 선정을 '요청한다'.
·가입자의 퍼스널 홈 페이지상의 요청된 선정은 처음을 "(R)"로 시작할 것이다.
·승인된 appointment는 처음을 "(A)"로 시작 할 것이다.
가입자는 정기적으로 그들의 캘린더 및 승인하는 "(A)"를 점검하거나 요청된 선정을 지우고 요청하는 측으로 필요한 후속의 통신을 개시하는데 책임이 있다. 승인된 선정은 "(A)"에 의하여 시작될 것이다.
보안 요구조건
상기 퍼스널 홈페이지로부터의 캘린더 액세스는 보안의 두 단계를 지원하도록 설계된다:
·No Pin Access:
-Times Only, 또는
-Times ＆ Events;
·Pin Access:
-Times Only, 또는
-Times ＆ Events.
1. 기억 장치 요구조건
상기 시스템은 다음과 같은 방식으로 과거 및 미래의 선정을 축적하고 유지한다:
·일련의 캘린더 선정의 지난 6개월에 더하여 현재의 월
·미래의 캘린더 선정의 다음 12개월에 더하여 현재의 월.
가입자에게는 데이터베이스에 오버라이트 되는 것으로 계획된 월 선정의 컨텐트를 다운로드할 수 있는 선택권이 제공된다. 가입자에게 다운로드될 캘린더 정보는 콤마 경계 지정 또는 DBF 포맷으로 존재하고 마이크로 소프트 스케쥴+, ACT 또는 Asend내로 끌어들여 질 수 있다.
2.On Screen Help Text
On Screen Help Text는 퍼스널 홈 페이지 내에서 작동하는 특정한 "Help"지시를 처리하기 위하여 게스트 및 가입자 아이콘 액세스를 제공한다. Help Text는 다음을 기술하는 정보를 제공하여야 한다:
·퍼스널 홈페이지로부터 네트워크MCI를 통하여 가입자에게 텍스트에 기초한 페이저 메시지를 송신하는 방법;
·퍼스널 홈페이지로부터 MCI 이메일 어카운트로 가입자에게 이메일 메시지를 송신하는 방법;
·가입자의 캘린더에 액세스하고 갱신하는 방법;
·사용자의 퍼스널 홈 페이지를 위치하는 방법; 그리고
·MCI를 통하여 당신 소유의 퍼스널 홈 페이지를 배열하는 방법.
3. 퍼스널 홈 페이지 디렉토리
상기의 것은 게스트에게 현재의 MCI 홈 페이지를 통하여 퍼스널 홈 페이지 디렉토리로 액세스할 수 있는 능력을 제공한다. 상기 디렉토리는 상기 게스트가 성(필수적임), 이름(선택적임), 단체(선택적임), 주(선택적임), 및/또는 Zip 코드(선택적임)를 상세히 나타냄으로써 특정 퍼스널 홈 페이지 어드레스를 위하여 모든 설정된 퍼스널 페이지 어카운트를 검색하는 것을 허용한다. 퍼스널 홈 페이지 디렉토리 검색으로부터의 결과는 다음의 정보를 돌려준다: 성, 이름, 미들 이니셜, 단체, 도시, 주 및 Zip 코드. 검색 분야에서 도시는 비록 요구되지는 않았지만 검색 결과에서는 제공된다.
게스트가 퍼스널 홈 페이지에 위치할 수 있는 또 다른 방법은 WWW 브라우저를 통하여 이루어진다. 많은 WWW 브라우저는 '네트 디렉토리'에 대한 검색 기능을 만들어 놓고 있다. 사용자의 홈 페이지는 WWW 브라우저에 의하여 제공되는 인터넷 어드레스의 디렉토리 내에 리스트 된다. MCI 홈 페이지로부터 당신의 검색을 안내하는 것의 잇점은 퍼스널 홈 페이지만이 인덱스 된다는(그리고 검색된다는) 것이다. WWW 브라우저 메뉴 옵션을 통하여 검색을 안내하는 것은 상기 검색을 퍼스널 홈 페이지로 한정할 수 없고 따라서 URS의 광범위한 리스트를 통하여 검색을 안내할 것이다. 또 게스트는 검색을 실행하는 것보다 퍼스널 홈 페이지를 위하여 특별한 URL(즉 오픈 로케이션)을 입력하는 기능을 가지고 있다. 이는 디렉토리에 리스트 되지 않은 그들의 퍼스널 홈 페이지를 가지고 있는 상기 가입자에게는 특히 중요하다.
4. 제어 표시줄
제어 표시줄 은 퍼스널 홈 페이지의 아래쪽에 나타난다. 제어 표시줄 은 상기 게스트가 상기 MCI 홈 페이지로부터 퍼스널 홈 페이지를 선택한 후에 나타난다. 상기 제어 표시줄 은 게스트 액세스에 다음과 같은 특징을 제공한다:
·Help Text
·MCI Home Page
·Personal Home Page 디렉토리
·Feedback
5. 홈 페이지
상기 홈 페이지는 가입자가 WWW 브라우저로부터 프로파일 관리를 실습하고 메시지 검색을 실행하기 위한 입구점이다. 상기 홈 페이지는 사용자가 메시지 센터 또는 프로파일 관리로의 용이한 액세스를 제공하도록 설계되어 있다.
6. 보안 요구조건
메시지 센터 또는 프로파일 관리로의 액세스는 허가된 사용자로 한정된다. 사용자는 메시지 센터 또는 프로파일 관리로의 액세스하기 전에 그들의 사용자 ID 및 패스워드를 입력할 것이 촉구된다. 3번의 시도의 실패 후에는 상기 사용자는 메시지 센터 또는 프로파일 관리로의 액세스가 저지되고 경고 메시지가 상기 가입자에게 MCI Customer Support Group과 접촉할 것을 충고한다. 상기 셈은 대표 MCI Customer Support가 상기 셈을 회복시킬 때까지 비활성 된다. 상기 셈이 회복되면 상기 가입자는 그의 패스워드를 갱신할 것이 요구된다.
메시지 센터로의 성공적인 로그온은 상기 사용자가 또 다른(즉 동일한) 사용자 ID 및 패스워드에 대한 요구 없이 프로파일 관리에 액세스할 수 있게 한다. 이는 역시 프로파일 관리에 성공적으로 액세스한 사용자에게도 동일하게 적용된다- 그들은 또 다른(즉 동일한) 사용자 ID 및 패스워드의 요구 없이 메시지 센터에 액세스하는 것이 허용된다.
패스워드는 한 달 동안 유효하다. 사용자는 패스워드가 기간 만료되는 경우 그들의 패스워드를 갱신하도록 독촉된다. 패스워드의 갱신에는 사용자가 기간 만료되는 패스워드 및 새로운 패스워드를 두 번 입력하도록 요구된다.
7. OnScreen Help Text
가입자에게 홈 페이지 내에서 작동하는 특정 "Help" 지시를 필드하기 위하여 아이콘 액세스를 제고한다. 상기 Help Text는 다음을 설명하는 정보를 제공한다:
- 메시지 센터에 액세스하는 방법;
- 프로파일 관리에 액세스하는 방법;
- MCI 홈 페이지에 액세스하는 방법;
- 퍼스널 홈 페이지에 액세스하는 방법;
- 메시지 센터를 통하여 메시지를 송신(즉 생성 또는 전달)하는 방법;
- 메시지 센터를 통하여 메시지를 파일링하는 방법;
- directlineMCI 프로파일 을 갱신하는 방법;
- 정보 서비스 프로파일을 갱신하는 방법;
- 그들의 퍼스널 홈 페이지를 갱신하는 방법;
- 홈 페이지 상에 피드백을 제공하는 방법; 그리고
- 사용자 가이드를 정렬하는 방법.
제어 표시줄
제어 표시줄 은 홈 페이지의 하단에 표시된다. 상기 제어 표시줄 은 게스트에게 다음의 특징으로의 액세스를 제공한다:
-Help Text;
-MCI Home Page;
-퍼스널 홈페이지 디렉토리; 그리고
-피드백
8. 프로파일 관리
전술한 On-Screen Help Text 및 제어 표시줄 에 더하여 프로파일 관리 스크린은 제목 표시줄을 나타낸다. 제목 표시줄은 가입자에게 프로파일 관리 구성 요소로의 용이한 액세스 및 메시지 센터로의 신속한 액세스를 제공한다. 상기 프로파일 관리 구성 요소로의 액세스는 다음을 포함하는 탭의 사용을 통하여 제공된다:
- directlineMCI;
- 정보 서비스;
- 퍼스널 홈 페이지;
- 리스트 관리; 그리고
- 메시지 처리
상기 directlineMCU 탭은 다음과 같은 directlineMCI의 기초적인 구성 요소를 위한 추가적인 탭을 포함한다:
- 음성메일;
- 팩스메일;
- 페이징
directlineMCI 프로파일 관리 시스템은 어카운트 프로파일 정보를 다음과 같은 것을 하도록 처리할 수 있는 기점인 프로파일 관리 페이지를 제공한다:
- 새로운 directlineMCI 프로파일을 생성하고 상기 프로파일에 이름을 할당한다;
- 현재의 directlineMCI 프로파일을 갱신한다.
- directlineMCI 프로파일의 생성 및 갱신의 규칙에 근거한 논리를 지원한다(예를 들면, 음성메일과 같은 오직 하나의 호출 경로 지정 옵션의 선택은 음성메일로의 오버라이드 경로 지정 및 페이징 통지와 같이 영향을 받은 모든 스크린을 통하여 하나의 스크린 물결(ripple)에 만들어진 갱신을 야기한다);
-directlineMCI 번호를 허가한다;
- 오버라이드 루팅 번호를 허가하고 규정한다;
- FollowMe 루팅을 허가하고 규정한다; 그리고
- directlineMCI FollowMe 루팅 순서에서 각 번호에 대한 RNA 파라미터를 규정한다;
- 다음과 같은 것으로의 마지막 경로 지정(전에는 호출된 교호의 경로 지정)을 허가하고 규정한다:
-음성메일 및 페이저,
- 오직 음성메일,
- 오직 페이저, 그리고
- 마지막 메시지;
- 둘 또는 그 이상의 호출 경로 지정 옵션(FollowMe, 음성메일, 팩스메일 또는 페이저)이 허가되면 메뉴 경로 지정을 불러낸다;
- 음성메일을 허가한다;
- 팩스메일을 허가한다;
- 페이징을 허가한다;
- 팩스메일 전달을 위하여 디폴트 번호를 규정한다;
- 음성메일을 위하여 페이징 통지를 활성화시킨다;
- 팩스메일을 위하여 페이징 통지를 활성화시킨다;
- 다른 directlineMCI 프로파일을 활성화/비활성화 시키기 위하여 스케쥴을 규정한다;
- 긴급한 전달을 위하여 음성메일을 분류할 수 있는 옵션을 게스트에게 제공한다;
- 메시지가 수신된 시간을 식별하는데 사용될 수 있는 모든 메시지 타입을 위하여 시간 존(zone)을 구성 배치한다;
-다음과 같은 것에 대한 호출 스크린닝 파라미터를 규정한다:
- 이름 및 ANI.
- 오직 ANI, 그리고
- 오직 이름; 그리고
- 파크(park) 및 페이지를 허가하거나 허가하지 아니한다.
9. 정보 서비스 프로파일 관리
정보 서비스 프로파일 관리는 가입자에게 정보 신호원 및 컨텐트네 의존하는 전달 주파수, 정보 신호원, 전달 기구(음성메일, 페이저, 이메일)를 선택할 수 있는 능력을 제공한다. 특히, 상기 가입자는 다음과 같은 어떠한 정보 신호원을 구성 배치할 수 있는 능력을 가지고 있다:
- 주식 시세 및 경제 뉴스; 및
- 헤드라인 뉴스.
주식 시세 및 경제 뉴스는 가입자에게 다음과 같은 것을 제공한다:
- 거래 뉴스 헤드라인;
- 주식 시세(10분 이내에)
- 주식 시장 리포트(시간대별, 오전/오후 또는 COB);
- 귀금속 리포트(시간대별, 오전/오후 또는 COB); 및
- 상품 리포트(시간대별, 오전/오후 또는 COB).
거래 뉴스 헤드라인은 하루에 한 번 이메일을 통하여 전달된다. 리포트(주식 시장, 통화 및 채권, 귀금속 및 상품)는 가입자에 의하여 특정한 인터벌을 가지고 전달된다. 시간대별 리포트는 이메일 메시지가 상기 시간 후 10분에 시간 검인을 받을 것을 요구한다. 오전/오후 리포트는 하나의 이메일 메시지는 아침(동부 시간 오전 11:10)에 전송될 것을 요구하고 하나의 이메일 메시지는 저녁(동부 시간 오후 5:10)에 전송될 것을 요구하며, COB 리포트는 동부 시간 오후 5시 10분에 전송된다.
주식 시장 리포트의 컨텐트는 다음을 포함하고 있다:
- 주식 또는 뮤추얼 펀드 시세 표시 심벌;
- 주식 또는 뮤추얼 펀드 개장 시세;
- 주식 또는 뮤추얼 펀드 폐장 시세;
-주식 또는 뮤추얼 펀드의 마지막으로 기록된 입찰 시세;
- 주식 또는 뮤추얼 펀드의 마지막으로 기록된 청구(ask) 시세;
- 주식 또는 뮤추얼 펀드의 52주 최고가; 및
- 주식 또는 뮤추얼 펀드의 52주 최저가.
주식 시세 및 경제 뉴스는 또한 매수 가능한 주식 및 뮤추얼 펀드의 리스트로부터 선택할 수 있고 음성메일 또는 텍스트에 기초한 페이지가 제공되는 기준을 규정할 수 있는 능력을 가입자에게 제공한다. 상기의 규정할 수 있는 기준은 '트리거 포인츠(trigger points)'로 언급되고 다음의 상황의 어느것 또는 모든 것이 될 수 있다:
-주식 또는 뮤추얼 펀드가 52주 최고가에 달하고 있다;
-주식 또는 뮤추얼 펀드가 52주 최저가에 달하고 있다;
-주식 또는 뮤추얼 펀드가 사용자가 규정한 최고점에 달하고 있다;
-주식 또는 뮤추얼 펀드가 사용자가 규정한 최저 점에 달하고 있다.
트리거 포인트 상황이 충족된 후에 메시지(음성메일 또는 텍스트에 기초한 페이저)가 1분내에 가입자에게 전송된다. 음성메일 메시지는 상기 사용자의 directlineMCI 어카운트에 규정된 가입자의 메일박스로 향한다. 주식 시세 및 경제 뉴스에 대한 정보 컨텐트는 10분 또는 그 미만의 새로운 정보이다.
10. 퍼스널 홈 페이지 프로파일 관리
퍼스널 홈 페이지 프로파일 관리는 그들의 퍼스널 홈 페이지를 주문 생산할 수 있고 게스트가 그들과 통신을 할 수 있는 방법(이메일 또는 텍스트에 기초한 페이저)을 규정할 수 있는 능력을 가입자에게 제공한다. 또한 프로파일 관리는 가입자가 그들의 캘린더로의 게스트 액세스를 제어할 수 있게 한다. 특히, 상기 가입자는 다음과 같은 것을 할 수 있다:
-인사말 메시지를 설정하고 유지하는 것;
-접촉 정보를 설정하고 유지 하는 것;
- 퍼스널 캘린더를 설정하고 유지 하는 것;
- 게스트가 페이징, 이메일 또는 캘린더로 액세스하는 것을 허용하거나 허용하지 않는 것;
- 표준 또는 특권화 액세스를 위하여 PIN을 규정함으로써 캘린더로의 게스트 액세스를 제어하는 것;
- 퍼스널 홈 페이지상의 기 규정된 로케이션에 개인 사진 또는 단체 로고와 같은 승인된 가입자의 제출된 화상을 짜 넣는 것.
퍼스널 홈 페이지의 생성과 동시에, 접촉 정보는 가입자의 전달 어드레스 정보에 위치된다. 상기 가입자는 접촉 정보 내에 어드레스 정보가 포함하고 있는 것을 갱신할 수 있는 능력을 가진다.
11. 리스트 관리
리스트 관리는 가입자에게 리스트를 생성하고 갱신할 수 있는 능력을 제공한다. 프로파일 관리는 메시지 분산을 위하여 메시지 센터를 통하여 액세스 할 수 있는 리스트를 규정할 수 있는 능력을 제공한다. 일 실시 예에 따르면, 리스트 관리는 집중되고 따라서 팩스 브로드캐스트 리스트 관리 능력은 리스트의 단일 데이터베이스를 제공하기 위하여 directlineMCI 리스트 관리 능력에 통합된다. 대체 실시 예에 따르면, 두 개의 리스트 관리 시스템은 사용자가 리스트의 어느 하나의 데이터베이스에 액세스할 수 있도록 분리되어 있다.
리스트는 가입자가 리스트명을 추가 삭제할 수 있도록 하는 PC 클라이언트 상의 어드레스 북(book)과 유사한 인터페이스를 통하여 제공된다. 이메일 어드레스, 팩스메일 어드레스(즉, ANI), 음성메일 어드레스(즉, ANI) 및 페이저 번호는 각 개인명과 관련되어 있다. 메시지가 메시지 센터 인박스(즉, 유니버설 인박스)에 위치할 때 상기 어드레스 북은 관련된 메시지 타입의 신호원 어드레스와 함께 갱신된다.
가입자가 분산 리스트를 선택할 때, 가입자는 이름, 타입 및 리스트의 식별명을 선택할 것이 독촉된다. 생성된 모든 리스트는 이름의 알파베트 순으로 이용될 수 있다. 리스트의 타입(음성, 팩스, 이메일, 페이지)은 리스트명을 동반한다. 또, 리스트 식별명은 알파베트 문자로 구성될 수 있다.
그리고 나서 상기 가입자는 분산 리스트를 생성하기 위하여 수령자 이름 및 어드레스를 독촉 받는다. 상기 가입자는 수령자 정보에 대한 어드레스 북에 액세스할 수 있다. 상기 가입자는 그의 리스트에 동일한 어드레스 타입을 기록할 것으로 제한 받지 않는다; 리스트가 팩스 타입으로 생성되는 경우, 상기 가입자는 상기 리스트에 ANI, 이메일, 페이징 어드레스를 포함할 수 있다. 상기 가입자는 생성, 재조사, 삭제, 편집(수령자 추가 및 삭제) 및 재명명 능력과 함께 그의 분산 리스트를 관리할 수 있다.
사용자가 WWW 브라우저 인터페이스를 통하여 리스트를 수정할 것을 선택할 때, 그는 어드레스 타입(음성, 팩스, 페이징, 이메일)을 선택할 것을 독촉되고 사용자의 분산 리스트의 리스트는 상기 어드레스 타입으로 제공되어야 한다. 상기 사용자는 또한 리스트가 위치하는 리스트명을 입력할 수 있다. 사용자는 생성, 재조사, 편집(수령자의 추가, 삭제), 삭제 및 재명명 명령을 통하여 리스트를 수정할 수 있다.
가입자가 수령자 추가, 삭제 또는 어드레스 변경을 통하여 리스트를 수정할 때마다, 그는 상기 수정을 글로벌 변경(global change)으로 만들 수 있다. 예를 들면, 사용자는 하나의 리스트에서 브라운 씨에 대한 음성 메일박스 어드레스를 변경한다. 그는 상기의 것을 모든 분산 리스트에서 브라운 씨에 대한 어드레스를 변경하는 글로벌 변경으로 만들 수 있다. 상기 가입자가 PC에 더하여 ARU 및 VRU를 통하여 분산 리스트를 생성하고 수정할 수 있을 때, 강화 리스트 유지 능력은 상기 WWW 브라우저 인터페이스를 통하여 지원된다.
상기 가입자는 이름 또는 다른 어드레스 필드에 의하여 검색 및 정렬을 할 수 있다. 예를 들면 사용자는 검색 기능 내에서 *DOLE* 명령을 사용하여 *DOLE*를 포함하는 모든 리스트를 검색할 수 있다. 또한 사용자는 어떠한 어드레스 필드를 사용하는 리스트를 검색할 수 있다. 예를 들면, 사용자는 수령자 번호, 'to'명 또는 zip 코드에 근거하여 검색할 수 있다. 사용자는 리스트명, 식별자 및 타입 또는 어떠한 어드레스 필드에 의하여 리스트를 정렬할 수 있다.
검색 능력에 더하여, 상기 분산 리스트 소프트웨어는 사용자가 현재의 부산 리스트 기록으로부터 서브-리스트를 복사하고 생성하는 것을 가능하게 한다. 상기 사용자는 외부 데이터베이스 구조로부터 수령자 데이터를 반입 또는 반출할 수 있다.
또한 사용자 사이에서 리스트를 공유하고 호스트에게 리스트를 upload하는 능력도 존재한다.
12. 글로벌 메시지 처리
글로벌 메시지 처리는 가입자에게 "유니버설 인박스"에 나타날 수 있는 또는 메시지 센터를 통하여 액세스 된 메시지 타입을 규정하는 능력을 제공한다. 다음과 같은 메시지 타입은 선택될 수 있다:
- directlineMCI 음성메일;
- directlineMCI 팩스메일;
- networkMCI 및 Sky Paging; 및
- MCI email account로부터의 이메일(즉, MCI Mail 또는 internetMCI)
가입자가 특정 서비스에 등록되지 않은 경우, 그때 그 옵션은 grayed-out될 것이고 따라서 글로벌 메시지 처리 내에서 선택될 수 없을 것이다. 글로벌 메시지 처리의 어떠한 갱신도 메시지 센터로 실 시간 갱신으로 귀착된다. 그 일 예는 가입자가 음성 메시지가 상기 메시지 센터에 나타나는 것을 허용하는 것을 선택할 수 있다는 것이다. 상기 메시지 센터는 음성메일 데이터베이스 내에 존재하는 모든 음성메일 메시지 오브젝트를 자동적으로 검색한다.
D. 메시지 센터
상기 메시지 센터는 메시지 오브젝트의 검색 및 처리를 위한 "유니버설 인박스"로 기능 한다. 상기 "유니버설 인박스"는 사용자에게 발송되는 메시지를 포함하는 폴더로 이루어져 있다. 메시지 센터로의 액세스는 WWW 브라우저로부터 지원되나 상기 "유니버설 인박스"에 포함되어 있는 컨텐트는 다음과 같은 메시지 타입을 나타낸다:
-음성메일: 사용자의 directlineMCI 어카운트로 발송된다;
- 이메일: 사용자의 MCI 이메일(즉, MCI 메일 또는 internetMCI) 어카운트로 발송된다;
- 팩스메일: 사용자의 directlineMCI 어카운트로 발송된다; 그리고
- 페이징: 사용자의 networkMCI 페이징 어카운트(또는 SkyTel 페이징 어카운트).
이전 섹션에서 기술된바 있는 On-Screen Help Text 및 제어 표시 줄에 저하여 상기 메시지 센터 스크린은 제목 표시줄을 표시한다. 상기 제몫 표시줄은 가입자에게 메시지 센터 기능으로의 용이한 액세스를 제공하고 프로파일 관리로의 신속한 액세스를 제공한다. 제목 표시줄을 통하여 지원되는 메시지 센터 기능은 다음과 같다:
- 파일: 사용자의 규정된 폴더를 리스트하고 사용자가 폴더를 선택하는 것을 허용한다;
-생성: 새로운 이메일 메시지를 구성한다;
- 전달: 음성메일은 이메일-어태치먼트(attachments)로서 전달된다;
- 검색: 메시지 타입, 송신자 이름 또는 어드레스, 주제 또는 날짜/시간에 기초하여 검색할 수 있는 능력을 제공한다; 그리고
- 저장: 사용자가 메시지를 유니버설 인박스 상의 폴더, 워크스테이션상의 파일 또는 디스켓에 저장하는 것을 허용한다.
상기 메시지 센터를 통하여 메시지를 구성 또는 전달할 때, 사용자는 이메일 또는 팩스메일 어느 한 가지로서 메시지를 송신할 수 있는 능력을 가지고 있다. 음성메일이 오직 음성메일 또는 이메일 어태치먼트로서 전달될 수 만 있다는 것이 유일한 제한이다. 다른 모든 메시지 타입은 상호 변경될 수 있고 따라서 이메일은 팩스 머신으로 전달될 수 있거나 페이저 메시지는 이메일 텍스트 메시지로서 전달될 수 있다. 팩스메일 메시지로서 송신된 메시지는 G3 포맷에서 만들어지고 팩스 브로드케스트로 리스트로의 분산을 지원한다.
상기 메시지 센터의 프리젠테이션 레이아웃은 PC 클라이언트의 프리젠테이션 레이아웃과 일치하고 따라서 그것들은 동일한 외양과 느낌을 가지고 있다. 상기 메시지 센터는 nMB v3.x.에 의하여 지원되는 프리젠테이션과 유사하게 메시지 헤더 프레임(Message Header Frame) 및 메시지 프리뷰 프레임(Message Preview Frame)을 나타내도록 설계되어 있다. 상기 사용자는 상기 메시지 헤더 프레임 및 메시지 프리뷰 프레임의 높이를 동적으로 어떤 치수로 다시 만들 수 있는 능력을 가질 것이다. 상기 메시지 헤더 프레임은 다음의 앤벌로프(envelope) 정보를 디스플레이 할 것이다.
-메시지 타입(이메일, 음성, 팩스, 페이지);
-송신자 이름, ANI, 이메일 어드레스;
-주제;
- 날짜/시간; 및
- 메시지 크기.
상기 메시지 프리뷰 프레임은 이메일 메시지 바디(body)의 첫 행, 팩스메일 메시지 첫 페이지의 첫 행, 페이저 메시지, 음성메일 메시지를 실행하는 방법에 관한 지시를 디스플레이 한다. WWW 브라우저를 통한 음성메일 메시지의 실행은 흐름 음성 능력으로서 지원되고 따라서 가입자는 그것의 작동 전에 가입자의 워크스테이션으로 음성을 다운로드하는 것이 요구되지 않는다. 상기 흐름 음성은 사용자가 상기 메시지 헤더 프레임의 음성메일 헤더 상에서 선택(한 번의 마우스 왼쪽 단추 클릭)한 후에 개시된다. 팩스메일 메시지의 디스플레이는 상기 사용자가 메시지 헤더 프레임의 펙스메일 헤더 상에서 선택(한 번의 마우스 왼쪽 단추 클릭)한 후에 개시된다.
상기 메시지 센터는 또한 상기 가입자가 프로파일 관리에서 생성된 분산 리스트를 사용하는 것을 허용한다. 상기 분산 리스트는 다른 메시지 타입 사이에서 메시지를 송신하는 것을 지원한다.
기본적인 메시지 검색 및 메시지 분산에 더하여 상기 메시지 센터는 유니버설 인박스 내의 메시지 폴더(또는 디렉토리)의 생성 및 유지를 지원한다. 처음에 사용자는 다음과 같은 폴더로 제한을 받는다:
-Draft: 송신되지 않은 저장된 모든 메시지를 보유한다;
- Inbox: "유니버설 인박스"에 의하여 수신된 모든 메시지를 보유하는데 그것은 사용자가 메시지 센터에 액세스 할 때 나타나는 디폴트 폴더이다.
- 송신: 송신된 모든 메시지를 보유한다; 그리고
- 쓰레기통: 삭제로 표시된 모든 메시지를 7일간 보유한다. 가입자는 결국은 폴더(및 폴더 내의 폴더)를 생성(및 재명명)할 수 있을 것이다.
1. 저장 요구조건
처음에, 사용자는 directlineMCI 음성메일 및 directlineMCI 팩스메일을 위한 저장 공간의 제한된 양을 할당받는다. 페이저 리콜 메시지 및 이메일 메시지는 소모된 저장 공간의 양보다는 수신된 메시지의 날짜/시간 스탬프에 근거하여 제한된다. 결국은 저장 요구조건은 일반적인 측정 단위에 근거하여 실행된다. 이는 메시지가 데이터베이스로부터 삭제될 때 및 게스트가 그들의 "유니버설 인박스"에 메시지를 축적하는 것을 저지 당할 때를 사용자가 인식하는 것을 용이하게 한다. 이것을 지원하기 위하여 상기 인박스에 보유되는 메시지에 대한 저장 요구조건은 다음과 같다:
-directlineMCI 음성메일: 60분;
-directlineMCI 팩스메일: 50 페이지;
- networkMCI 페이지: 99 시간; 그리고
- 이메일: 6개월.
가입자에게는 쓰레기통 폴더에 보유되는 메시지를 제외하고 데이터베이스에 덮어쓰는(overwritten) 것으로 계획된 메시지를 다운로드할 수 있는 옵션이 제공된다.
E. PC 클라이언트 Capabilities
1. 사용자 인터페이스
PC 클라이언트 인터페이스는 축적 및 전달 환경에서 작동하기를 원하는 가입자를 지원한다. 상기 사용자는 국부적으로 처리 또는 저장되는 메시지를 다운로드하기를 원한다. 상기 PC 클라이언트는 프로파일 관리를 지원하도록 설계되어 있지는 않고 상기 PC 클라이언트 인터페이스가 메시지(음성메일, 팩스메일, 이메일, 텍스트-페이지)를 나타내기만 한다. 프로파일 관리 능력으로의 액세스는 ARU 인터페이스 또는 WWW 브라우저 인터페이스를 통하여 사용될 수 있을 뿐이다. PC 클라이언트 인터페이스는 WWW 브라우저 인터페이스와 통합되며 따라서 양 구성 요소는 동일한 워크스테이션 상에 존재할 수 있으며 단일 IP 접속을 공유할 수 있다. 상기 PC 클라이언트 인터페이스는 윈도우 95를 지원하는데 최적화되어 있다. 윈도우 3.1도 마찬가지로 지원된다.
화상 사용자 인터페이스는 nMB v3.x에 의하여 지원되고 WWW 브라우저에 의하여 지원되는 프리젠테이션과 유사한 메시지 헤더 윈도우 및 메시지 프리뷰 윈도우를 나타내도록 설계되어 있다. 상기 사용자는 상기 메시지 헤더 윈도우 및 상기 메시지 프리뷰 윈도우의 높이를 동적으로 다시 크기 조정할 수 있는 능력을 가지고 있다. 상기 메시지 헤더 윈도우는 다음의 엔벌로프 정보를 디스플레이 한다:
- 메시지 타입(이메일, 음성, 팩스, 페이지);
- 송신자의 이름, ANI, 이메일 어드레스;
- 주제;
- 날짜/시간; 그리고
- 메시지 크기.
상기 메시지 프리뷰는 이메일 메시지 또는 페이저 메시지 바디의 첫 행 또는 팩스메일 메시지를 디스플레이 하는 방법 또는 음성메일 메시지를 실행하는 방법에 관한 지시를 디스플레이 한다. PC 클라이언트로부터의 음성메일 메시지의 실행은 PC 상에 제공되는 음성 카드를 필요로 한다. 팩스메일 메시지의 디스플레이는 PC 클라이언트 내에 팩스메일 판독기(reader)를 불러낸다.
메시지 센터는 사용자가 프로파일 관리에서 생성된 분산 리스트를 사용하는 것을 허용한다. 상기 분산 리스트는 다른 메시지 타입 사이의 메시지 송신을 허용한다.
2. 보안
PC 클라이언트 및 서버 사이의 사용자 확인은 다이얼-업 로그온 세션동안 교섭된다. 보안은 지원되고 따라서 사용자 ID 및 패스워드는 인터페이스를 설정할 때 PC 클라이언트 및 서버 사이에서 건네지는 정보에 각인 된다. 가입자는 그들의 사용자 ID 및 패스워드를 수동으로 입력할 것이 요구되지 않는다. 또한 패스워드에 대한 갱신은 PC 클라이언트와 통신된다.
3. 메시지 검색
메시지 검색은 가입자에게 "유니버설 인박스"에 위치하는 음성메일, 팩스메일, 페이지 및 이메일을 선택적으로 검색할 수 있는 능력은 제공한다. PC 클라이언트로부터 디스플레이 또는 실행된 베시지 타입은 다음을 포함한다:
- directlineMCI 음성메일;
- directlineMCI 팩스메일;
-networkMCI 페이징; 그리고
- MCI 이메일 어카운트로부터의 이메일;
상기 PC 클라이언트는 상기 "유니버설 인박스"로부터 모든 메시지 타입을 검색하기 위하여 단일 통신 세션을 개시한다. 상기 단일 통신 세션은 음성메일, 팩스메일, 이메일 및 페이지를 포함하는 업스트림(upstream) 데이터베이스에 액세스할 수 있다.
상기 PC 클라이언트는 또한 선택적인 메시지 검색을 실행할 수 있고 따라서 사용자는 다음과 같은 것을 할 수 있다:
- 모든 메시지를 검색하는 것;
- 선택된 메시지 헤더에 대한 full text(또는 body)를 검색하는 것;
-편집할 수 있는 검색 기준에 근거하여 메시지를 검색하는 것:
-우선 메시지;
- 이메일 메시지;
- 페이저 메시지;
- 팩스메일 메시지(완전한 또는 헤더만);
- 음성메일 메시지(완전한 또는 헤더만);
- 송신자 이름, 어드레스 또는 ANI;
- 메시지 상의 날짜/시간 스탬프; 그리고
- 메시지 크기.
"유니버설 인박스"로부터의 표제만의 팩스메일 메시지는 메시지 바디가 검색될 때까지 "유니버설 인박스"에 보유된다. 음성메일 메시지는 가입자가 WWW 브라우저(즉, 메시지 센터) 또는 ARU를 통하여 "유니버설 인박스"에 액세스하고 상기 메시지를 삭제할 때까지 "유니버설 인박스"에 보유된다. "유니버설 인박스"로부터 검색된 메시지는 데스크탑 폴더로 이동된다.
또한 PC 클라이언트는 백그라운드 및 계획된 폴링을 지원할 수 있고 따라서 사용자는 PC 클라이언트가 메시지를 검색하고 있을 때 메시지 처리(생성, 편집, 전달, 저장 등)를 실행할 수 있다.
4. 메시지 처리
메시지 처리는 가입자에게 다음과 같은 많은 표준 메시징 클라이언트 조치를 실행할 수 있는 능력이 있다:
- 이메일, 팩스메일 또는 페이저 메시지의 구성(생성);
- 모든 메시지 타입의 전달;
- 저장;
- 편집;
- 삭제;
- 분산;
- 어태치(Attach);
-검색; 및
- 메시지의 디스플레이 또는 실행.
F. 오더 엔트리(Order Entry) 요구조건
directlineMCI 또는 networkMCI Business 커스터머에게는 프로파일 관리 및 메시지 관리 기능을 실행하기 위하여 추가적인 인터페이스 옵션이 제공된다. directlineMCI 및 networkMCI Business 커스터머 양자에게는 다른 인터페이스 타입을 통하여 사용될 수 있는 특징 및 기능에 액세스하기 위하여 어카운트가 자동적으로 제공된다. networkMCI Business 커스터머에게로 어카운트를 제공할 수 있는 능력도 또한 지원된다. 그러나 networkMCI Business 커스터머 모두에게 어카운트가 제공되는 것은 아니다. 오더 엔트리는 필요한 만큼의 networkMCI Business 커스터머를 위한 어카운트를 발생시키는데 충분할 만큼 유연하다.
오더 엔트리는 시스템에서 제공되는 추가적인 인터페이스 타입 및 서비스로의 액세스가 directlineMCI 또는 networkMCI Business 커스터머에게 자동적으로 제공되도록 설계된다. 예를 들면 directlineMCI(또는 networkMCI Business)에 주문하는 커스터머에게는 프로파일 관리 또는 메시지 센터를 위한 홈 페이지에 액세스하기 위하여 어카운트가 제공된다. 커스터머에 두 개의 어카운트(directlineMCI로부터 하나 및 networkMCI Business로부터 하나)가 구성 배치되는 것을 방해하기 위하여 검사가 이루어진다. 이를 달성하기 위하여 두 개의 오더 엔트리 절차 사이의 통합이 설정된다.
오더 엔트리로의 통합된 접근은 단일 인터페이스를 요구한다. 상기 인터페이스는 오더 엔트리 능력을 통합하고 따라서 상기 오더 엔트리는 하나의 오더 엔트리 시스템에 위치하는 것으로 나타나고 다중 오더 엔트리 시스템에 독립적인 로그온 세션을 설정하기 위하여 오더 엔트리 관리자를 요구하지 않는다. 상기 통합 오더 엔트리 인터페이스는 모든 서비스에 동일한 오더 엔트리 방법론을 지원하고 필요한 오더 엔트리 시스템으로부터 정보를 얻을 수 있다. 또한 상기 인터페이스는 사용자의 현재 업무와 관련된 서비스를 볼 수 있는 능력을 지원한다.
통합 오더 엔트리 인터페이스 시스템의 특정 조건은 다음과 같다:
- MCI 이메일(MCI 메일 또는 internetMCI) 어카운트를 규정하는 자동 공급;
-networkMCI 페이징 어카운트(또는 SkyTel 페이징 어카운트)를 규정하는 자동 공급;
- directlineMCI 어카운트를 규정하는 자동 공급;
-팩스 브로드케스트 능력을 가능하게 하는 자동 공급;
-MCI 이메일 어카운트, networkMCI 페이징 어카운트 또는 directlineMCI 어카운트 정보를 수동으로 입력할 수 있는 능력;
- 내국행 정보 서비스로의 액세스를 가능 또는 불가능하게 할 수 있는 능력; 그리고
- 외국행 정보 서비스로의 액세스를 가능 또는 불가능하게 할 수 있는 능력.
상기 능력은 오더 엔트리 관리자에게 기 존재하는 MCI 서비스(이메일, 페이징, directlineMCI) 어카운트 정보에 근거하여 사용자를 추가하는데 유연성을 제공한다. 택일적으로 상기 오더 관리자는 기초를 이루는 서비스를 상세히 설명할 때 사용자를 추가 할 수 있다.
상기 오더 엔트리 시스템은 하향류 요금부과 시스템에 필요한 커스터머 어카운트 및 서비스 정보를 제공한다. 상기 시스템은 또한 MCI가 복제 플랫포옴 소프트웨어(즉, PC 클라이언트) 및 도큐먼트(즉, 사용자 가이드)를 송신하는 것을 방해할 수 있도록 하기 위하여 최초 커스터머 오더 및 모든 후속 갱신을 트랙(track)한다. 또한 오더 엔트리 프로세스는 관리자가 다음과 같은 정보를 얻는 것을 가능하게 한다:
-커스터머 전달 및 이름의 기록;
-미국 및 캐나다 어드레스의 지원, 및
-P. O. boxes로의 전달을 방해하는 능력의 제공;
-커스터머의 요금부과 어드레스, 전화 번호, 접촉 이름의 기록;
-오더 날짜 및 후속 하는 모든 갱신의 기록;
-오더를 제출했던 Account Representative의 이름, 번화 번호, 구역의 기록;
-사용자의 directlineMCI 번호의 기록 및 입수;
-사용자의 networkMCI 페이징 PIN의 기록 및 입수;
-사용자의 MCI 이메일 어카운트 ID의 기록 및 입수;
-전기적으로 실행 하우스로 송신되는 실행 리포트의 발생; 그리고
-수신 오더의 번호;
-networkMCI 페이징 (또는 SkyTel 페이징) 어카운트를 생성하는 오더 번호;
-MCI 이메일 어카운트를 생성하는 오더 번호; 그리고
-directlineMCI 어카운트를 생성하는 오더 번호.
퍼스널 홈 페이지는 커스터머를 위하여 주문 받을 수 있다. 오더 엔트리 동안 기록된 커스터머 전달 정보는 사용자의 퍼스널 홈 페이지로부터 제공된 디폴트 어드레스 정보이다. 또한 상기 오더 엔트리 프로세스는 특별한 화상의 설치 및 요금 부과를 지원할 수 있다.
특별한 화상을 위한 현재의 특징/기능 'on' 및 'off'를 변화시키는 능력이 존재한다. 사용자에 의하여 관리될 수 있는 특징은 오더 엔트리 시스템 내에서 식별된다. 상기 특징은 그리고 나서 사용자의 디렉토리 어카운트 내에서 관리를 위하여 능동화 된다.
실 시간 액세스 능력이 오더 엔트리 시스템과 사용자의 디렉토리 어카운트 사이에 존재한다. 상기 어카운트는 사용자의 모든 서비스, 상품 특징/기능 및 어카운트 정보에 피관리 사용자 여부를 떠나 위치 공간을 제공한다. 피관리 사용자로서 식별되지 않는 상기 항목은 사용자의 인터페이스를 통하여 액세스 할 수 없다.
1. 준비 및 성취
액세스 요구 조건은 시스템으로의 내국행 액세스 및 시스템으로부터 외국행 액세스의 항목에서 규정된다. 내국행 액세스는 사용자 또는 호출자가 시스템에 액세스할 수 있는 방법을 포함하고 있다. 바람직한 실시 예에 따르면, 외국행 액세스는 사용자가 시스템에 의하여 처리되는 방법을 포함하고 있다. 인터넷은 내국행 및 외국행 프로세싱 모두에 지원된다.
다음의 구성 요소는 내국행 액세스를 제공할 수 있다;
- directlineMCI: 800/8XX;
- MCIMail: 800/8XX, 이메일 어드레스;
- networkMCI 페이징: 800/8XX; 및
- networkMCI 메일: 800/8XX, POP3 이메일 어드레스.
다음의 구성 요소는 외국행 액세스를 위하여 식별된다:
-directlineMCI: 다이얼 1;
- 팩스 브로드캐스트: 800/8XX, local;
- MCI Mail: 800/8XX, 이메일 어드레스; 및
- networkMCI 메일: 800/8XX, POP3 이메일 어드레스.
G. 통화 시스템
통화는 현 MCI 절차에 따라 지원된다.
H. 가격 결정
처음에 상기 특징은 기초적인 구성 요소에 대하여 규정된 현 가격 결정 구조에 따라 가격 결정된다. 또한 세금부과 및 할인 능력은 현재 지원되는 것처럼 기초적인 구성 요소에 대하여 지원된다. 할인은 또한 다중 서비스에 가입한 커스터머에 대하여 지원된다.
I. 요금 부과
요금 부과 시스템은:
-directlineMCI 강화 서비스(음성메일, 팩스메일, 양자)에 대한 요금부과를 지원한다;
-최고점 및 최저점 요율에 대한 요금부과를 지원한다;
-서비스 수에 근거하여 바뀌는 다중 서비스(directlineMCI, networkMCI 비즈니스, networkMCI 페이징, networkMCI 셀룰러)에 대한 할인을 지원한다;
-directlineMCI 호출(발신 및 착신)에 대한 networkMCI 셀룰러 요금부과를 억제하는 능력을 지원한다;
-직접 MCI 용법에 민감한 월 요금에 대한 부과를 지원한다;
-directlineMCI 용법에 근거한 무료 시간의 형식에 판매 촉진을 지원한다;
-퍼스널 홈 페이지에 대한 요금 부과를 지원한다;
-퍼스널 홈 페이지에 대한 요금 부과를 억제하는 능력을 지원한다; 그리고
-SCA 가격 결정을 지원한다.
일 실시 예에 따르면, 요금 부과 시스템은 각 기초적인 구성 요소에 대하여 존재하는 현 구매서 송부 절차를 지원한다. 대체 실시 예에 따르면, 요금부과는 모든 기초적인 구성 요소를 포함하는 확고한 구매서 송부를 제공한다. 구매서 송부에 더하여 직접 요금 부과는 현재 직접 요금 부과를 지원하는 기초적인 구성 요소 전부에 대하여 지원된다.
XVIII. DIRECTLINEMCI
directlineMCI 시스템의 사용을 위하여 수정된 상기 시스템의 구조에 대한 기술은 다음과 같다. 상기 도큐먼트는 directlineMCI 플랫포옴에서의 일반적 데이터 및 호출 흐름을 다루고 상기 흐름을 지원하는데 필요한 네트워크 및 하드웨어 구조를 상세히 기술한다. 하향류 시스템의 요금 부과 흐름은 매우 높은 수준에서 다루어진다. 상향류 시스템의 오더 엔트리(OE) 흐름은 매우 높은 수준에서 다루어진다. directlineMCI 구조의 어떠한 부분은 현 구성 요소를 재 사용한다(예를 들면 음성 응답 유닛(ARU)). 새로운 directlineMCI 구조의 상기 부분은 좀 더 상세히 다루어진다.
A. 개요
요금 부과, 오더 엔트리, 경보에 더하여 directlineMCI 시스템은 도 43에서 도시되는 세 개의 주 구성 요소로 이루어진다:
- ARU(음성 응답 유닛)502
-VFP(음성 팩스 플랫포옴) 504
- DDS(데이터 분산 서비스) 506
아래의 서브섹션은 각각의 주 구성 요소를 높은 수준에서 기술한다. 도 43은 주 시스템 구성 요소 사이의 높은 수준의 관계를 보여준다.
1. ARU(음성 응답 유닛) 502
ARU 502는 directlineMCI에 대한 최초 내국행 호출을 처리한다. 어떠한 특징(find me/follow me과 같은)은 전적으로 ARU상에서 실행된다. 내국행 팩스는 ARU에 의하여 톤-검출되고 VFP 504로 확장된다. ARU에 의하여 제공되는 menuing은 음성메일/팩스메일 특징으로의 액세스를 요청하는데 사용되는데, 상기와 같은 경우에도 또한 호출이 VFP로 확장된다.
2. VFP(음성 팩스 플랫폼) 504
상기 VFP는 외국행 팩스 및 음성 전달과 페이저 통지뿐 아니라 음성메일/팩스메일 특징에 menuing을 제공한다. 상기 VFP는 또한 ARU에 의하여 작동되고 기록되는 주문 생산 가입자 프롬프트를 위한 중앙 데이터 저장소이다.
3. DDS(데이터 분산 서비스) 506
상기 DDS는 OE 프로파일 및 Billing Details Record(BDR)에 대한 보관소이다. OE 프로파일은 DDS에 축적되는데, 상기 DDS는 적절한 모든 시스템으로 프로파일을 분산을 초래한다. DDS 506은 BDR을 수집하고 BDR을 하향류 요금부과 시스템으로 수송한다.
B. 이론적 근거
directlineMCI에 대한 요구조건은 단일 800 번호에 의하여 액세스되는 단일 서비스로 다양한 서비스 구성 요소를 통합하는 것이다. 상기 서비스 구성 요소의 번호는 ISN ARU 플랫폼 상에 미리 전개되어 있다. ARU상에 나타나지 않는 서비스는 메일 박스 서비스 및 팩스 서비스이다. 시스템 500의 ARU 502는 Texas Instruments(TI)로부터 구입한 음성메일/팩스메일 플랫폼을 통합한다. 상기 소프트웨어의 부분은 성능, 신뢰성 및 확장성(scalability)을 위하여 DEC Alpha machine상에서 작동하기 위하여 포트된다. directlineMCI 실행을 위한 또 다른 요구 조건은 주 흐름(현 MCI) 요금부과와 오더 엔트리 시스템과의 통합이다. 상기 DDS는 directlineMCI와 주 흐름 오더 엔트리 시스템 사이의 내국행 및 외국행 인터페이스를 제공한다.
C. 상세
도 43은 주 시스템 구성 요소 사이의 관계를 보여준다. 상기 OE 시스템 508은 DDS 506을 통하여 SRU 502 및 음성 팩스 플랫폼(VFP) 504로 다운로드되는 가입자 프로파일을 발생한다. 상기 ARU 502 및 VFP 504에 의하여 발생된 BDR은 DDS를 통하여 요금 부과 시스템 510으로 공급된다. 상기 ARU 502는 모든 내국행 호출을 처리한다. 팩스 톤이 검출되거나 음성메일/팩스메일 특징이 요구되면, 상기 호출은 ARU 502로부터 VFP 504로 확장된다. 메일박스 상태(예를 들면 "You have three messages")를 위하여 상기 aru 502는 VFP 504에 상태를 문의하고 프롬프트를 작동시킨다.
가입자의 주문 생산 프롬프트는 VFP 504에 저장된다. 상기 ARU가 주문 생산 프롬프트를 작동시킬 때 또는 새로운 프롬프트를 기록할 때, 상기 프롬프트는 VFP 504 상에 액세스된다. ARU 502 및 VFP 504로부터의 경보는 Local Support Element(LSE)로 송신된다.
1. 호출 흐름 구조 520
directlineMCI에 대한 호출 흐름 구조는 도 44에 도시된다. 상기 도면의 상부는 상기 호출을 이송하는데 사용되는 네트워크 522 접속성을 보여준다. 상기 도면의 하부는 다양한 호출 타입에 대한 호출 방향을 보여준다. 아래의 서브섹션은 도면에 수반되는 서술을 제공한다.
2. 네트워크 접속성
모든 내국행 ISN 호출은 MCI 네트워크 522에 접속된 자동 호출 분산기(ACD)에서 수신된다. 액세스 제어 포인트(ACP)는 통합 서비스 네트워크 어플리케이션 프로세서(ISNAP) 526으로부터 내국행 호출을 수신하는데, 상기 프로세서는 ACD 524로의 제어/데이터 인터페이스이다. 네트워크 음성 시스템(NAS)은 ACP의 제어 하에서 T1 인터페이스를 통하여 ACD로 음성을 작동하고 기록한다. 미국에서는 디지털 다중 시스템은 T1로 알려진 첫 번째 수준의 다중 전송이 4-회선 케이블(신호를 '송신'하는 한 쌍의 회선, 신호를 수신하는 한 쌍의 회선)을 통하여 24 디지트화된 음성 채널을 결합시키는 곳에 채용된다. T1 캐리어 상의 종래의 비트 포맷은 DS1(즉, 첫 번째 수준 다중 디지털 서비스 또는 디지털 신호 포맷)로 알려져 있는데, 상기 DS1은 각 프레임이 8 개 비트 각각의 24 PCM 음성 채널(또는 DS0 채널)을 가지는 연속적인 프레임으로 이루어져 있다. 각 프레임은 제어 목적으로 추가적인 프레임 비트를 가지고 있어 프레임 당 총 193 비트를 가진다. T1 전송률은 초당 8000 프레임 또는 초당 1.544 메가비트이다. 상기 프레임은 시간 분할 다중화(TDM)로 알려진 기술을 사용하는 T1 전송을 위하여 집합되는데, 여기에는 각 DS0 채널에는 한 개당, 프레임 내에 24 순차적 시간 슬로트가 할당되어 있어 각 시간 슬로트는 8-비트 워드를 포함하고 있다.
로컬, regional, 장거리 서비스 프로바이더의 네트워크를 통한 전송은 다중 캐리어의 다양한 스위치 및 계층 구조를 통하여 정교한 호출 프로세싱을 포함하고 있다. 종래의 고속 전송의 정점에는 동시성 광 네트워크(SONET)가 있는데, 상기 네트워크는 광섬유 미디어를 이용하고 기가 비트(초당 10억 비트를 초과하는) 범위에서 전송을 할 수 있다. 네트워크를 통한 전달 후에 고 수준의 다중 캐리어는 개별 DS0 라인으로 다시 역다중화되고, 복호되고 그리고 개별 가입자 전화로 연결된다.
전형적으로 다중 신호는 단일 라인을 통하여 다중화 된다. 예를 들면 DS3 전송은 전형적으로 동축 케이블에 의하여 반송되고 44.736Mbps로 28 DS1 신호를 결합시킨다. 광 계층에서 낮은 수준에 존재하는 OC3 광 섬유 캐리어는 155.52Mbps로 세 개의 DS3 신호를 결합하는데, 단일 광 섬유 케이블의 2016 개별 음성 채널에 커패서티를 제공한다. 광섬유에 의하여 반송되는 SONET 전송은 매우 높은 전송률이 가능하다.
NSA/ACP 결합은 ARU 502로 언급된다. 상기 ARU 5092가 호출이 VFP 504로 확장되어야 함을 결정하면 상기 ARU 502는 VFP 504로 다이얼 호출한다. 상기 VFP 미디어서버는 T1을 통하여 MCI 네트워크 522로 접속된다. 상기 ARU 502로부터 상기 VFP로의 데이터 전달은 각 호출 상에서 이중 톤 다중 주파수를 통하여 달성된다.
3. 호출 흐름
도 44의 호출 시나리오는 아래에 상세히 기술되어 있다. 어떠한 내국행 호출의 시작에 있어서 상기 ARU 502는 호출을 이미 수신하였고 상기 호출이 directlineMCI 호출인지 여부를 결정하기 위하여 어플리케이션 선택을 실행한다.
a) 내국행 팩스:
내국행 팩스 호출은 상기 aru 502로 전달된다. 상기 aru는 팩스톤 검출을 실행하고 VFP 504로 호출을 확장한다. 어카운트 넘버 및 방식은 DTMF 시그널링을 이용하는 VFP로 전달된다.
b) 내국행 음성, ARU only:
내국행 음성 호출은 가입자 또는 게스트 방식 어느 하나로 이루어지는데, ARU 502를 사용하는 상기 특징들만이 액세스된다. 상기 ARU는 방식(가입자 또는 게스트)을 결정한다. 가입자 방식에서는 상기 ARU는 메시지 넘버를 결정하기 위하여 VFP 504에 문의한다. 어떠한 추가적인 네트워크 액세스도 이루어지지 않는다.
c) 내국행/외국행 음성, ARU only:
호츨이 ARU 502로 이루어지고 페이저 통지 또는 find me/follow me 특징 어느 하나가 액세스된다. 상기 aru 502는 외부 번호로 acd 524를 통하여 다이얼 호출된다.
d) 내국행 음성, vfp 특징:
호출은 aru 502로 이루어지고 상기 호출은 vfp 504로 확장된다. 어카운트 넘버 및 방식은 dtmf를 통하여 vfp로 송신된다. 게스트 방식은 다음과 같다:
1. 음성메일을 축적한다.
2. 팩스메일을 축적한다.
3. 팩스메일을 수집한다.
가입자 방식은 다음과 같다:
1. 메일을 수신하고 송신한다.
2. 브로드캐스트 리스트를 유지한다.
3. 메일박스 이름 기록을 수정한다.
상기 vfp 504는 vfp 세션동안 사용자를 계속 독촉한다.
e) 외국행 팩스/음성/페이저, vfp only:
팩스 또는 음성 전달 또는 페이저 통지를 위하여 상기 vfp는 직접적으로 mci 네트워크 522상에서 다이얼 호출한다.
f) 재발신/철회
내국행 가입자 호출이 vfp 504에 접속될 때, 사용자는 2초 동안 파운드 키이를 누름으로써 aru 502 directlinemcu 메뉴의 최고 레벨로 돌아갈 수 있다. 네트워크 522는 vfp 504로부터 상기 호출을 다시 가지고 가고, aru 502로 호출을 재 발신한다.
4. 데이터 흐름 구조
도 45는 directlinemci 구조 520의 주 데이터 흐름을 묘사한다: OE 기록(커스터머 프로파일)은 상향류 시스템에서 입력되고 dds 주프레임 532로 530에서 다운로드된다. 상기 dds 주프레임은 상기 OE 기록을 aru/acp 및 vfp/실행 서버 상에서 네트워크 정보 분산 서비스(nids) 서버 534로 다운로드한다. 상기 다운로드는 ISN 토큰(token) 링 네트워크 538을 통하여 이루어진다. 실행 서버 536상에서는 상기 OE 기록이 로컬 실행 서버 데이터베이스(미도시)에서 저장된다.
BDR은 실행 서버 536 및 acp 540 양자에 의하여 절단된다. 상기 BDR은 오퍼레이터 네트워크 센터(onc) 서버 542에 저장되고 dds 주프레임 532로 업로드 된다. onc 서버 542로부터 dds 주프레임으로의 업로드는 상기 ISN 토큰 링 네트워크 538을 통하여 이루어진다.
상기 aru 502는 가입자에게 그들의 음성메일/팩스메일 메시지 번호를 독촉한다. 가입자가 가지는 메시지 번호는 ISNAP Ethernet 544를 통하여 acp 540에 의하여 vfp 504로부터 입수된다. 상기 acp 540이 어떠한 상기 ISN 사이트에 존재할 수 있다는 것을 주의하라.
NAS 546에 의하여 작동된 user-recorded ad hoc은 vfp 504상에 저장되고 NAS 546에 의하여 요구가 있는 즉시 네트워크를 통하여 작동된다. NFS 프로토클 548은 ISNAP 로컬 에어리어 네트워크(lan) 544 및 광역 네트워크(wan) 550을 통하여 사용된다.
D. 음성 팩스 플랫폼(vfp) 504의 상세한 구조
1. 개요
도 46은 첫 번째 실시 예에 대한 directlinemci 시스템의 음성 팩스 부분 504의 하드웨어 구성 요소를 보여 준다. 상기 시스템의 주 구성요소는 다음과 같다:
TI 멀티서버 400 미디어 서버 560.
DEC 8200 실행 서버 536.
Cabletron MMAC+hub 562.
알파스테이션 200 콘솔 매니저 및 터미널 서버 564.
Bay 네트워크 5000 허브 566.
또 다른 실시 예에 따르면, 상기 Cabletron 허브는 상기 구성 배치로부터 제거될 수 있고 상기 Bay 네트워크 허브는 모든 네트워크 통화를 반송할 수 있다.
2. 이론적 근거
상기 TI 멀티서버 4000 560은 directlinemci의 음성메일/팩스메일 부분을 위하여 mci에 의하여 선택된다. 상기 멀티서버 4000은 상당히 느린 nubus backplane상의 상당히 느린 68040 장치이다. 상기 68040/nubus 장치는 TI에 의하여 양 미디어 서버(TI인터페이스, 음성 및 팩스를 위한 dsp)로서 또한 실행 서버(데이터베이스 및 오브젝트 기억장소)를 위하여 사용된다. 비록 상기 하드웨어는 미디어 서버 사용에 적당하지만 수백 또는 수천 기가 바이트의 음성 및 팩스 데이터와 수천의 미디어 서버 포트에 서비스하기 위한 실행 서버로서는 부적당하다. 또한 상기 미디어 서버 하드웨어에 사용될 수 있는 클러스터링(성능 또는 여유를 위한)은 존재하지 않는다. 따라서 상기 TI 실행의 실행 서버 부분은 아래에 기술된 DEC Alpha 8200 클러스터 536상에 작동하기 위하여 MCI에 의하여 포트 된다. 상기 클러스터링은 장애극복(failover) 및 로드공유(loadsharing)(따라서 확장성 (scalability))양자를 제공한다.
유사하게 고속 8200 플랫포옴으로부터 이동되어야 하는 기가 바이트는 네트워크를 통하여 TI 미디어 서버로 이동되어야 한다. 섬유 분산 데이터 인터페이스(FDDI) 및 스위치된 10bT 접속성 양자를 가지는 Cabletron 허브 562는 실행에 중추를 제공한다. 각 미디어 서버 560은 여분의 스위치된 Ethernet 포트 쌍에 어태치된다.
각 포트는 스위치된 포트이기 때문에, 각 미디어 서버는 상기 허브에 전용 10 Mb 대역폭을 가진다. 8200 서버 536은 각각 많은 미소 10Mb Ethernet 파이프에 서비스하기 위하여 대 네트워크 파이프를 필요로 한다. 첫 번째 실시 예에, FDDI 인터페이스 568이 사용될 수 있다. 그러나 통화 프로젝션(projections)은 필요한 통화가 FDDI 용량을 몇 시간정도 초과하고, 따라서 바람직한 실시 예에서는 ATM과 같은 고속 네트워킹 기술을 사용할 것이다. 상기 허브 562는 완전히 여분 구성이다.
알파 스테이션 200 워크스테이션 514는 오퍼레이션 지원에 필요하다. 상기 알파 스테이션 200은 DEC의 폴리센터 콘솔 매니저(Polycenter Console Manager)를 통하여 각 driectline MCI VFP 504 구성 요소에 콘솔 관리를 제공한다. 상기 알파 스테이션 200은 또한 DEC 폴리센터 성능 분석기(Polycenter Performance Analyzer) 소프트웨어를 작동시킨다. 성능 분석기 소프트웨어는 튜닝 목적으로 8200으로부터 데이터를 수집하고 분석한다.
3. 상세
도 47은 프로덕션 사이트에 VFP 504의 프로덕션 설치를 보여준다. 도 47과 도 46과의 관계에 주의하라. DEC Alpha 8200 536은 장애극복(failover) 구성에 존재한다. 중앙 랙(rack)은 공유 디스크 배열이다.
TI 멀티서브 4000 560은 실질적으로 단일 캐비넷의 네 개의 분리 미디어 서버의 복합체이다. 본 도면에 후속 하는 도면은 분리체로서 각 분체(멀티 서버 4000의 4개의 미디어 서버 중 하나)를 보여준다. 4개의 각 16FGD TI는 각 분체에 접속된다.
알파 스테이션 200 워크스테이션 564 및 터미널 서버는 콘솔 및 시스템 관리를 제공하는데 사용된다. Cabletron 허브 562는 서버 560 및 실행 서버 536 사이에 네트워크를 제공한다.
Bay 네트워크 허브 566은 VFP 504 및 네트워크 루터 569 사이에 네트워크를 제공한다.
a) 내부 하드웨어 네트워크
도 48은 VFP 내부 하드웨어/네트워크 구조를 보여준다;
도 47-49에 관한 일반적인 주해;
좌 DEC 8200 장치 536은 도시된 ATM 및 FDDI 접속 570 모두와 함께 도시되어 있다. 우 DEC 8200은 도시된 Ethernet 접속 572와 함께 도시되어 있다. 실제 배치에서는 양 기구가 도시된 ATM, FDDI, 토큰 링 및 Ethernet 접속 570 및 572 모두를 가지고 있다.
각 8200 536이 단지 네트워크 접속성의 절반하고만 도시되어 있으므로 상기 Cabletron 허브 562는 포트로의 접속을 실제 발생하는 것보다 더 적게 보여주고 있다. 또한 4개의 미디어 서버 560 중의 하나만이 상기 Ethernet 포트에 접속되는 것으로 도시되어 있다. 실제적으로는 각 미디어 서버에 대하여 한 개의 송.수신기와 두 개의 Ethernet 접속이 존재한다.
Bay 허브 566은 도 48에 도시되어 있지 않다. 상기 Bay 허브 566은 도 49, directlineMCI VFP External LAN Network Connectivity에 나타나 있다.
DEC 8200 536의 도 48 상단부부터 시작하면;
상 유닛은 오퍼레이팅 시스템, 스왑(swap) 등을 위하여 세 개의 4GB 드라이브 574를 포함한다. 시스템 CD 드라이브 576은 역시 여기에 위치한다.
상기 유닛은 주 시스템 579로부터 Single-Ended Small Computer Systems Interface(SCSI)(도면상에는 "SES")인터페이스 578에 의하여 제어된다.
테이프 스태커 580은 단일 드라이브 및 10 테이프 스택을 가지는 140GB 테이프 유닛이다. 상기 유닛은 주 시스템 579로부터 Fast-Wide SCSI (본 도면에서는 "FWS")인터페이스 582에 의하여 제어된다.
주 시스템 유닛 579는 다섯 개의 사용 가능한 슬로트 세 개를 이용한다. 슬로트 1은 주 CPU 카드 584를 가지고 있다. 상기 카드는 하나의 300MHz CPU를 가지고 있으며 두 개의 CPU로 업데이트될 수 있다. 슬로트 2는 512 메모리 카드 586을 가지고 있다. 상기 카드는 2GB로 업데이트 될 수 있고 또 다른 메모리가 추가될 수 있다. 최대 시스템 메모리는 4GB이다.
슬로트 3 및 4는 비어 있으나 추가적인 CPU, 메모리 또는 I/O 보드를 위하여 사용될 수 있다. 슬로트 5는 주 I/O 카드 588을 가지고 있다. 상기 카드는 8 개의 I/O 인터페이스를 가지고 있다:
하나의 Fast-wide SCSI 인터페이스 582는 테입 스태커를 제어한다.
두 개의 fast-wide SCSI 인터페이스 590-592는 사용되지 않는다.
single-ended SCSI 인터페이스 578은 로컬 시스템 드라이브를 제어한다.
fddi 인터페이스 594는 하나의 허브로 접속된다.
PCI 슬로트 596은 PCI 확장 클래식 598로 접속된다.
하나의 포트는 전용 thinnet Ethernet을 통하여 다른 8200 536에서 대응 카드로 접속되는 10baseT Ethernet 카드 600이다. 상기 네트워크는 하나의 시스템 failover heartbeats에 요구된다.
일 실시 예는 PCI/ISA 확장 클래식 598에서 1/9의 사용 가능한 슬로트를 이용한다. 슬로트 1 및 2는 디스크 어댑터 602를 가지고 있다. 각 디스크 어댑터 602는 연쇄된 또 다른 디스크 제어기 604(나머지 장치 상에)를 가지고 있는 raid 디스크 제어기 604로 접속되어 있는데, 상기 또 다른 디스크 제어기 604는 차례로 상기 장치 상에서 디스크 제어기 504로 접속되어 있다. 따라서 각 8200 장치 536은 각 디스크 어댑터 602의 부착된 두 개의 디스크 제어기 604를 가지고 있다. 상기 장치 536은 주 클러스터링인데, 왜냐하면 각 장치가 PCI 클래식 598 아래에서 도 48에 위치하는 디스크 모두를 제어할 수 있기 때문이다. 슬로트 3은 prestoserve 보드 606을 가진다. 상기 보드 606은 네트워크 파일 서버(NFS) 가속기이다.
슬로트 4는 FDDI 보드 608을 가지고 있다. 상기 fddi 접속은 상기 주슬로트 5로부터 이루어지는 FDDI 접속과는 다르게 허브로 이루어진다.
슬로트 5 및 6은 ATM 보드 610을 가진다. 상기 ATM 보드 610은 전용 thinnet Ethernet을 통하여 나머지 8200 536에서 대응 카드로 접속되는 10baseT Ethernet 카드 612를 가지고 있다. 상기 네트워크는 하나의 시스템 failover heartbeats에 요구된다. 슬로트 10은 비어 있다.
PCI 클래식 아래의 두 개의 유닛은 inexpensive disks(raid) 디스크 제어기 604의 중복 배열이다. 각 디스크 제어기 604는 중간의 두 개의 디스크 제어기 604 및 각 말단의 디스크 어댑터 602(각 장치당 하나)와의 SCSI 연쇄상에 존재한다. 따라서 여기에는 두개의 연쇄가 존재하는데 각각은 두개의 디스크 제어기 604 및 두 개의 디스크 어댑터 602와 연쇄된다. 이 것은 주 시스템 579로의 접속성이다. 각 디스크 제어기 604는 6 개의 single-ended SCSI 연쇄를 지원한다. 상기 구성에서 두개의 연쇄 각각은 두 개의 ses 접속을 가진 하나의 디스크 제어기 및 세 개의 접속을 가지는 하나의 디스크 제어기를 가진다. 각 연쇄는 중앙 rack에 도시된 디스크 드라이브의 5 개의 세트 614(또는 "drawers")를 가지고 있다. 상기 drawer에서의 raid 디스크 제어기로의 중복 동력 공급에 주의하라.
cabletron mmac+hub 562(도 47)는 중복 쌍으로 구성되어 있다. 양 허브 562로의 8200 536 및 TI 미디어 서버 560 접속 양자와 두 개의 허브 562는 또한 상호 접속되어 있다. 상기 허브의 좌측으로부터 출발하면: fddi 집중 장치 카드 616은 8 개의 포트 fddi 링을 제공한다. 각 8200은 각 허브 562상에 fddi 카드 616으로의 하나의 접속을 가진다. 24 개의 포트 Ethernet 카드 618은 TI 미디어 서버 560에 접속성을 제공한다. 각 미디어 서버 560은 각 허브 상에서 하나의 Ethernet 포트 618로 접속한다. 각 허브에는 추가적인 fddi, ATM 또는 Ethernet 확장에 사용될 수 있는 8개의 빈 슬로트 620이 존재한다.
"멀티서브 4000"으로 불리는 단일 rack에는 장착된 네 개의 TI 미디어 서버 560이 존재한다. 상기 rack의 각 미디어 서버는 동일하다. 상 유닛으로부터 출발하고 그리고 나서 주 슬로트에 내하여 우측으로 좌향 전진하면: 상 유닛 622는 두 개의 1GB 디스크 드라이버 및 제거 가능한/hot-insertable 테입 드라이브를 포함하는 drawer이다. 여기에는 네 개의 미디어 서버 사이에서 공유될 수 있는 두 개의 테입 드라이브가 있다. "DSP xxx"로 라벨된 좌측의 7 개의 보드는 6 개의 입력 및 7 개의 출력 채널을 각각 지원하는 TI mpb 보드이다. 상기 보드 624는 3 개의 세트로 집단화된다. 여기에는 세 개의 보드로 이루어진 우측 그룹이 있고 세 개의 보드로 이루어지는 중간 그룹이 있으며 좌측에는 하나의 그룹이 있다. 각 그룹은 하나의 TI를 가지고 있다. 상기 TI은 "TIM"으로 표시된 인터페이스에서 종료된다. 상기 인터페이스는 기본 T1 인터페이스이다. T1 채널은 기본/종속 보드에 의하여 한계가 설정된 보드 세트에 의하여 공유될 수 있고 브리지 모듈에 의하여 연쇄될 수 있다. 최 우측 보드 626은 주 CPU/IO 보드이다. 상기 보드는 디스크 drawer에 SCSI 인터페이스 628을 지원하고 특별한 송수신기 632에 Ethernet 접속 630을 지원하고 콘솔(미 도시)을 위하여 시리얼 포트를 제공한다.
상기 cpu/io 보드의 우측의 송수신기 632는 두 개의 주 허브 562 각각에서 Ethernet 포트로 접속된다. 상기 송수신기는 Ethernet 접속이 실패할 경우 이를 감지하고 나머지 포트로 통화를 경로 지정한다.
b) 외부 하드웨어/네트워크 접속
도 49는 vfp 504로부터 외부 네트워크로의 하드웨어 및 네트워크 접속을 보여 준다. 도 49에서는 다음을 주목하라:
각 8200 536은 SNA를 통한 dds 액세스 및 IP를 통한 BDR 액세스를 위하여 bay 허브를 통하여 ISN 토큰 링 640 상으로 접속된다. 터미널 서버 642 쌍은 각 장치 및 허브의 콘솔 포트로의 접속을 가진다. dec 알파스테이션 200 564는 터미널 서버 642로 접속된 포트에 액세스하기 위하여 콘솔 매니저 소프트웨어를 작동시킨다. decnis 루터는 bay 허브 566 및 두 개의 dec 8200 536사이에서 접속된 fddi 링 568(도 46)상에 모두 존재한다.
bay 허브 566은 도시된 7 개의 루터 644를 통하여 외부 네트워크로 vfp 시스템 504를 접속한다.
E. 음성 분산의 상세한 구조
1.개요
음성 분산은 구조의 일부분으로서의, NAS 546(도45)이 프로토콜을 사용하는 vfp 504로부터/로 lan 또는 wan을 통하여 가입자의 ad hoc 프롬프트를 읽고 쓰는 곳에 관하여 언급한다.
2. 이론적 근거
일 실시 예에 따르면 음성 분산은 각 ISN 사이트에 서버를 위치시키고 복잡한 배치 프로세스를 통하여 각 서버로부터 다른 각각의 서버로 데이터를 복제함으로써 실행된다.
"large object management"(lom) 프로젝트는 네트워크에 기초한 접근을 규정한다. 상기 접근은 커스터머 프롬프트를 읽고 쓰기 위하여 NAS 546을 위한 네트워크에 기초한 중앙 오브젝트 기억 장치로서 directlinemci vfp 504를 사용하기로 결정되었다.
도 50은 바람직한 실시 예에 따른, 음성 분산 통화를 지원하기 위한 네트워크 구조를 보여준다. 도 52a는 본 발명의 데이터 관리 구역 5105를 보여 준다. 상기 데이터 관리 영역(DMZ)은 인터넷 다이얼-인 플랫폼(비록 실제 인터넷 자체는 아니지만) 및 ISN 프로덕션 네트워크 사이의 파이어 월(fire wall)이다. 상기 DMZ의 목적은 프로덕션 ISN 네트워크에서 커스터머 데이터의 프라이버시 및 보전 뿐 아니라 isn 네트워크를 위한 보안을 유지하는 동안 isn 커스터머에게 데이터로의 다이얼-인 액세스를 제공하는 것이다.
상기 DMZ는 커스터머가 메일프레임으로부터 공급된 dds데이터와 같은, 발생된 데이터를 주기적으로 수신하는 것을 허용한다. 상기와 같은 데이터는 데이터베이스로부터 추출되고 커스터머에 의한 후속 검색을 위하여 보안 파일 전송 프로토콜(ftp) 호스트 상에서 사용자 어카운트 디렉토리에 위치된다.
커스터머를 위한 데이터 액세스는 다이얼-인 게이트웨이에서 전용 포트를 통하여 이루어지는데, 상기 게이트웨이는 인터넷 프로바이더에 의하여 소유되고, 작동되고 유지된다. 다이얼-인 사용자 확인은 보안 식별 카드를 통하여 1회용 패스워드를 사용함으로써 이루어지는데 이에 대해서는 아래에서 좀 더 상술한다. 상기 카드는 인터넷 프로바이더 퍼스널에 의하여 배포되고 관리된다.
상기 DMZ는 외부의 미보안 네트워크 및 내부 전용 네트워크로부터 통화를 방호하기 위하여 팻킷 필터링 루터를 사용하는 방호 서브네트 파이어월을 제공한다. 오직 선택된 팻킷만이 루터를 통하여 허가되고, 다른 팻킷은 제거된다. 다중 파이어월링 기술의 사용은 DMZ 구성에서의 어떠한 실패 또는 에러점도 ISN 프로덕션 네트워크를 위험에 처하게 하지 못하게 하는 것을 보장한다.
상기 DMZ 5105는 몇 개의 보안 표준을 따르도록 되어 있다. 첫째는 허가된 피용자가 아닌 개인은 내부 프로덕션 네트워크에의 접근이 허용될 수 없다. 따라서 게이트웨이를 통한 IP 접속성은 허용되지 않는다. 두 번째는 DMZ 서비스의 액세스 및 사용은 특정 목적을 위하여 확인되고 허가된 사용자에게 제한된다. 따라서 일반용 장치에서 정상적으로 발견되는 모든 다른 설비 및 서비스는 사용 불가능하다. 세 번째는 DMZ 서비스 및 설비의 사용은 확인된 사용자에 의하여 마주치는 문제를 검출하고 잠재적 사기 행위를 검출하기 위하여 주의 깊게 검사되어야 한다.
상기 DMZ의 중앙부는 DMZ Bastion 호스트 5110이다. Bastion 호스트 5110은 아래에서 좀더 상술될 수정된 FTP 프로토콜을 실행하는 FTP 서버 대몬(daemon)을 작동시킨다. Bastion 호스트 5110은 외부로의 인터페이스로서 사용되는 고도로 보안된 장치이다. Bastion 5110은 외부로부터 오직 제한된 액세스만을 허용한다. 상기 Bastion 5110은 전형적으로 ISN 5115의 내부 호스트로의 application-level 게이트웨이로서 작용하는데 상기 Bastion host 5110은 대리 서비스를 통하여 상기 내부 호스트로의 액세스를 제공한다. 일반적으로 임계 정보는 Bastion host 5110 상에 배치되지 않고 따라서 비록 호스트가 절충되더라도 ISN 5115에서 추가적인 보전성 절충 없이는 임계 데이터에 대한 어떠한 액세스도 이루어지지 않는다.
Bastion host 5110은 도 52A에 나타난 바와 같이 내부 및 외부 사용자에 모두 접속된다. Bastion host 5115는 AIX 오퍼레이팅 시스템을 작동시키는 IBM RS/6000 모델 580과 같은 UNX에 기초한 컴퓨터일 수 있다.
내부 사용자는 ISN 프로덕션 토큰 링 5115로 접속된 사용자이다. 토큰 링 5115는 Cisco 모델 4500 모듈러 루터와 같은 내부 패킷 필터 5120에 접속되어 있다. 팻킷 필터 5120은 토큰 링 LAN 5125에 접속되어 있는데, 상기 토큰 링 LAN 5125는 차례로 bastion host 5110에 접속되어 있다. 토큰 링 LAN 5125는 bastion host 5110 및 내부 패킷 필터 5120 이외의 모든 구성 요소로부터 고립되어 있는 전용 토큰 링이며, 상기 토큰 링 LAN 5126에 의하여 패킷 필터 5120에 의하여 허용된 경우를 제외하고 토큰 링 LAN 5125를 통하여 bastion host 5110으로의 어떠한 액세스도 저지된다.
외부 사용자는 Cisco 모델 4500 모듈러 루터와 같은 외부 패킷 필터 5130을 통하여 접속된다. 패킷 필터 5130은 고립 Ethernet LAN 세그먼트 5135를 통하여 bastion host 5110에 접속된다. Ethernet LAN 세그먼트 5135는 bastion host 5110 및 외부 패킷 필터 5130 외의 모든 구성요소로부터 격리된 전용 세그먼트이다.상기 구성 배치에 기인하여, 어떠한 사용자도 내부 패킷 필터 5120 또는 외부 패킷 필터 5130을 통하는 것을 제외하고 bastion 호스트 5110에 액세스 할 수 없다.
도 52A는 dial-in 환경 5205와 관련하여 상기 DMZ 5105를 묘사하고 있다. dial-in 환경 5205에서는 커스터머 PC 5210 모뎀 5215의 사용을 통하여 공중 교환 전화네트워크(PSTN) 5220에 접속된다. 모뎀 뱅크 5230은 PSTN 5220으로부터의 입력 호출에 응답하는데 모뎀을 할당한다. 모뎀 뱅크 5230은 U.S Robotics V.34 Kbps 모뎀과 같은 고속 모뎀 세트로 이루어져 있다. 입중계 호출은 확인 서버 5235에 의하여 확인된다. 확인 서버 5235는 Sun Sparcstation 모델 20상에서 작동하는 Radius/Keystone 서버와 같은 서버를 사용하여 실행될 수 있다.
상기 Bastion host 5110은 파이어월 내에 위치하나 논리적으로 ISN 5115 및 게이트웨이 사이트 5205 양자의 바깥쪽에 위치한다.
확인에 후속 하여, 선택된 모뎀 5233은 포인트-투-포인트 프로토콜(PPP)을 사용하는 입중계 호출 루터 5240에 접속된다. PPP는 포인트-투-포인트 링크를 통하여 멀티-프로토콜 데이터그램을 이송하는 표준 방식을 제공하는 프로토콜이다. 상기 링크는 풀-듀플렉스(full-duplex) 동시 양-방향 오퍼레이션을 제공하고 팻킷을 순서대로 전달하도록 되어 있다. PPP는 매우 다양한 호스트, 브릿지 및 루터의 용이한 접속에 대한 일반적인 해결책을 제공한다. PPP는 RFC 1661에 상세히 기술되어 있다 : The Point-to-Point Protocol (PPP), W.Simpson, Ed.(1994)("RFC 1661"), 이로써 상기 PPP의 공개는 참조에 의하여 구체화된다.
입중계 호출 루터 5240은 TI 라인 5250과 같은 통신 링크를 통하여 DMZ 5105의 외부 패킷 필터 5130으로 입중계 요청을 선택적으로 경로 지정하는데, 상기 TI라인 5250은 채널 서비스 유닛(미 도시)을 통하여 외부 패킷 필터 5130에 접속된다. 입중계 호출 루터 5240은 예를 들면 Cisco 7000 시리즈 멀티프로토콜 루터를 사용하여 실행될 수 있다. 입중계 호출 루터 5240은 선택적으로 인터넷 5280에 접속된다. 그러나 루터 5240은 인터넷 5280으로부터 외부 패킷 필터 5130으로의 통화를 저지하고 외부 패킷 필터 5130으로부터 인터넷 5280으로의 통화를 저지하도록 구성되어 있고 따라서 인터넷 5280으로부터 DMZ로의 액세스를 허용하지 않는다.
Bastion host 5110은 wu-ftpd FTP 대몬, from Washington University에 근거한 수정된 FTP 프로토콜을 실행하는 File Transfer Protocol (FTP) 서버를 작동시킨다. 여기에 기재된 것 외에는 상기 FTP 프로토콜은 RFC 765에 따른다. File Transfer Protocol, by J. Postel (June 1980)("RFC 765"), 이로써, 상기 FTP 프로토콜의 공개는 레퍼런스에 의하여 구체화된다. RFC 765는 TCP/IP에 기초한 telnet 접속을 사용하는 파일 전송용 공지의 프로토콜을 기술하는데, 서버는 상기 접속에서 파일을 송신 또는 수신하는 또는 상태 정보를 공급하는 사용자-개시된 명령에 응답한다. 상기 DMZ FTP 실행은 송신 명령(원거리 사용자로부터 FTP 서버로 파일을 송신하는데 사용) 및 FTP 호스트로 파일을 전송하는 다른 어떤 FTP 명령을 배제한다. get(또는 recv) help, ls 및 quit 명령을 포함하는 명령의 제한된 서브 세트가 지원된다.
get 명령은 호스트 서버 5110으로부터 원거리 사용자 5210으로 파일을 전송하는데 사용된다. recv 명령은 get과 동의어이다. help 명령은 호스트 서버 5110에 의하여 지원되는 명령에 간결한 online 도큐먼트를 제공한다. ls 명령은 서버의 현 디렉토리의 파일 또는 사용자가 특정한 디렉토리의 리스트를 제공한다. quit 명령은 FTP 세션을 종료한다. 현 디렉토리로서 명명된 디렉토리를 특정하는 cd 명령 및 현 디렉토리의 이름을 디스플레이 하는 pwd 명령은 선택적으로 실행될 수 있다.
서버로 파일을 전송하는 send 또는 기타의 명령을 허용하지 않음으로써 잠재적인 침입자가 시스템 보안을 절충하는데 사용될 수 있는 "Trojan horse" 타입 컴퓨터 프로그램을 전송하는 것을 방지한다. 추가적인 잇점으로서 단방향 데이터 흐름은 사용자가 Bastion server상에 위치하는 파일을 부주의하게 삭제 또는 덮어쓰는 것을 방지한다.
FTP 대몬이 사용자 세션을 개시할 때, 상기 FTP 대몬은 사용자가 보는 파일 시스템의 외형 루트(root)로서 사용자의 디렉토리 트리의 루트를 상세히 설명하기 위하여 UNIX Chroot(2) 서비스를 사용한다. 이것은 사용자가 /etc 및 /bin과 같은 UNIX system 디렉토리를 보는 것 및 다른 사용자의 디렉토리를 보는 것을 제한하는데, 그럼에도 사용자 자신의 디렉토리 트리 내의 파일을 희망하는 바대로 보고 액세스하는 것을 허용한다. 더한층 보안 환경을 보장하기 위하여, FTP 대몬은 루트로서보다는 사용자 레벨의 사용자-id("uid)에 실행되고, 허가된 것으로 알려진 미리 결정된 IP 어드레스 세트로부터 통신하는 허가된 사용자로만의 액세스를 허용한다. 특히, 익명 및 게스트의 표준 미-확인 어카운트는 가능이 억제된다.
Bastion server 5110의 추가적인 보안을 위하여, UNIX 인터넷 서버 프로세스 inetd에 의하여 일반적으로 개시되는 다수의 대몬은 기능이 억제된다. 사용 억제된 대몬은 Bastion 서버 오퍼레이션에 필요치도 않거나 보안 노출을 가지는 것으로 알려진다. 상기 대몬은 rcp, rlogin, rlogind, rsh, rshd, tftp 및 tftpd를 포함한다. 상기 대몬은 AIX /etc /inetd.conf file에서 그들의 엔트리를 삭제 또는 논평함으로써 상기 대몬은 기능이 억제된다. 상기 /etc /inted.conf 파일은 소켓을 통하여 인터넷 요청을 수신할 때 inetd에 의하여 불려 내어지는 서버의 리스트를 제공한다. 대응 엔트리의 삭제 또는 논평에 의하여 상기 대몬이 수신된 요청에 대한 응답으로 실행되는 것이 방지된다.
보안의 추가적인 보장을 위하여, 다수의 대몬 및 설비를 실행될 수 없는 것으로 표시(예를 들면 파일 모드 000을 가지는)하기 위하여 그것들의 관련된 파일 면허를 변경함으로써 다수의 대몬 및 설비가 실행되는 것을 허용하지 않는다. 이는 부트(boot)시에 실행되는 DMZ Utility Disabler (DUD) 루틴에 의하여 달성된다. 상기 DUD 루틴은 inetd에 의하여 일반적으로 불려내어지지 않는 다수의 다른 대몬 및 설비 뿐 아니라 실행할 수 없는 상기의 파일 (rcp, rlogin, rlogin, rsh, rshd, tftp 및 tftpd)로 표시된다. 상기 대몬 및 설비 세트는 sendmail, gated, routed, fingerd, rexecd, uncpd, bootpd 및 talkd를 포함한다. 또한 DUD는 telnet 및 ftp 클라이언트가, 브레이크-인(break-in)의 이벤트에서 내부 호스트로 상기 클라이언트가 액세스하는 것을, 침입자가 실행하는 것을 방지하는 것을 불가능하게 한다. 상기 telnet 및 ftp 클라이언트는 일시적으로 시스템 유지 활동 중에는 실행될 수 있는 것으로 표시될 수 있다.
Bastion host 5110은 기능 억제된 IP 전달을 가진다. 이는 루터로서 Bastion host 5110을 사용함으로써 DMZ 격리 서브네트 5115를 통과할 수 없도록 보장한다.
Bastion 서버 5110에 의하여 제공된 ftp 서비스의 제한된 레벨은 보안 ftp 세션을 제공하나, 전형적인 시스템 유지의 실행을 어렵게 한다. 시스템 유지를 실행하기 위하여 유지 인원은 telnet 클라이언트를 사용하는 ISN 5115 내에서 내부 호스트로부터 Bastion host 5110으로 접속되어야 한다. 그리고 나서 Bastion의 FTP 클라이언트 프로그램은 AIX chmod 명령을 사용하여 실행될 수 없는 것으로부터 (예를 들면,000) 실행될 수 있는 것(예를 들면, 400)으로 변경된다. 그리고 나서 유지 인원은 ISN 5115 상에서 희망하는 호스트로 접속하는 ftp 클라이언트 프로그램을 실행할 수 있다. 그러므로 상기 절차동안, 전송제어는 호스트의 외부에서 클라이언트로부터 보다는 호스트의 내부에서 실행되는 FTP 클라이언트 프로그램을 통하여 Bastion 호스트 5110 내부로부터 이루어진다. 유지 세션의 마지막에 FTP 세션이 종료되고 chmod 명령이 실행 할 수 없는 상태(예를 들면 000)로 ftp 클라이언트 프로그램을 복귀하기 위하여 다시 한번 실행되고, 그 이후에 ISN-개시된 telnet 세션이 종료될 수 있다.
logging을 제공하기 위하여 Bastion 서버 5110은 Wieste Venema로부터의 TCP 래퍼(wrapper)와 같은 TCP 대몬 래퍼를 실행한다. 상기 TCP wapper는 inetd가 명명된 대몬보다는 작은 래퍼 프로그램을 실행하도록 지시한다. 상기 래퍼 프로그램은 클라이언트 host 이름 및 어드레스를 log하고 어떠한 추가적인 검사를 실행하며, 그리고 나서 inetd를 위하여 희망하는 서버 프로그램을 실행한다. 서버 프로그램의 종료 후에 상기 래퍼는 메모리로부터 삭제된다. 상기 래퍼 프로그램은 클라이언트 사용자 또는 클라이언트 프로세스와 아무런 상호작용을 하지 않고 서버 에플리케이션과 상호작용하지 않는다. 이는 두 가지 주요 잇점을 제공한다. 첫째는 상기 래퍼가 어플리케이션-독립적이며, 따라서 동일한 프로그램은 많은 종류의 네트워크 서비스를 보호한다. 둘째는 상호작용의 결핍은 상기 래퍼 외부로부터 볼 수 없음을 의미한다.
상기 래퍼 프로그램은 클라이언트와 서버간의 최초 접촉이 설정될 때만 실행한다. 그러므로, 래퍼가 그의 logging 기능을 실행한 후에는 클라이언트-서버 세션에 추가적인 오버헤드(overhead)가 없다. 상기 래퍼 프로그램은 그들의 logging 정보를 syslog 대몬 즉 syslogd로 송신한다. 래퍼 log의 배열은 syslog 구성 배치 파일, 즉 일반적으로 /etc /syslog. conf에 의하여 결정된다.
Dial-in 액세스는 dial-in 환경 5105를 통하여 제공된다. 확인 서버 5235의 사용은 DMZ에의 액세스를 허가 받지 못한 사용자로부터의 액세스를 방지하는 것을 사용자 확인에 제공한다. 상기 실행된 확인 방식은 1회용 패스워드 설계를 사용한다. 모든 내부 시스템 및 네트워크 요소는 keyston이라 불리는 내부적으로 개발된 확인 클라이언트/서버 기구를 사용하는 Security Dynamics에 의하여 생산된 SecurID 보안 식별 토큰 카드와 같은 1회용 패스워드 발생기 토큰 카드를 사용하여 보호된다. keystone 클라이언트는 사용자로부터 확인 요청을 수신하는 각 요소 상에 설치된다. 상기 요청은 그리고 나서 네트워크의 도처에 배치된 keystone 서버로 안전하게 제출된다.
각 사용자에게는 전면에 액정 디스플레이를 가진 크레디트 카드 사이즈의 보안 식별 카드가 배정된다. 상기 디스플레이는 매 60초마다 변경되는 의사-난(pseudo-randomly)수열 적으로 발생된 6-digit 번호를 디스플레이 한다. keystone 보호 시스템으로의 액세스를 획득한 피용자를 위하여 사용자는 보안 식별 카드 상에 현재 디스플레이된 번호에 앞서는 그들의 개인적으로 할당된 PIN 번호를 입력하여야 한다. 상기와 같은 확인은 "sniff" 또는 패스워드를 가로채는 것을 시도하는 프로그램 또는 사용자로부터 패스워드를 포획하도록 설계된 Trojan horse 프로그램의 사용을 채용하는 미허가 액세스를 방지한다.
Keystone 클라이언트에 의하여 수집된 확인 정보는 RSA 및 DES 암호 키이에 암호화되고, 다수의 Keystone 서버 중 하나에 발송된다. 상기 Keystone 서버는 그 당시에 사용자의 카드 상에 디스플레이 되어야 하는 사용자의 PIN 및 액세스 코드를 검증하기 위하여 정보를 평가한다. 정확하게 입력된 사용자에 대한 양 인자를 시스템이 검증한 후에, 허가된 사용자는 시스템 또는 요청된 리소오스로의 액세스가 제공된다.
외부 네트워크의 엔트리 포인트로부터 보안을 보장하기 위하여 어떠한 외부 게이트웨이 장치도 일반적인 액세스 어카운트를 가지지 못하며 모두 제어된 액세스를 제공한다. 각 게이트웨이 장치는 모든 게이트웨이 서비스가 logging 정보를 발생시키는 것을 보장하며, 각 게이트웨이 장치가 게이트웨이로의 접속의 audit trail을 유지한다. 모든 외부 게이트웨이 장치는 단절된 비필수적인 서비스 모두를 가진다.
확인 서버 5235는 모든 원거리 액세스 다이얼 업에 전위(front end)로서 서비스하고 pass-through를 불허용하도록 프로그램 되어 있다. 모든 네트워크 확인 기구는 실패한 액세스 시도의 logging에 대비한다. 바람직하게는 발생된 log가 선정된 인원에 의하여 매일 검토된다.
도 53은 fax tone 검출 방법론을 보여주는 흐름도를 묘사하고 있다. 단계 5305에서는 팩스톤 검출 시스템은 공(null)링크된-리스트를 할당한다; 즉 엔트리를 가지지 않는 링크된 리스트. 단계 5310에서는 팩스톤 검출 시스템은 비동기식 루틴 auCheckForFaxAsync 5315를 시작시킨다. 상기 auCheckForFaxAsync 루틴 5315는 호출 프로그램으로 제어를 동기에 되돌리기보다는 메인 라인 프로그램과 동시에 실행되는 비동기식 프로그램이다. 상기 auCheckForFax 루틴은 호출이 팩시밀리 장치에 의하여 발신되었는지 여부를 보기 위하여 입중계 호출의 톤을 평가하고, 팩시밀리 톤이 검출되는 경우 및 때에 auCheckForFax 응답 5318을 발생시킨다.
auCheckForFaxAsync 루틴 5315를 시작한 후, 제어는 단계 5320으로 진행된다. 단계 5320에서는 팩스톤 검출 시스템은 단계 5305에 할당된 링크된 리스트에 엔트리를 추가한다. 추가된 엔트리는 처리되고 있는 메시지와 관련된 고유 식별자를 나타낸다. 단계 5330에서, 팩스톤 검출 시스템은 비동기식 루틴 auPlayFileAsync 5335를 시작시킨다. 상기 auPlayFileAsync 루틴 5335는 호출 프로그램으로 제어를 동기에 복귀시키는 것보다는 메인 라인 프로그램과 동시에 실행되는 비동기식 프로그램이다. 상기 auPlayFileAsync 루틴 5335는 미리 저장되고 디지털 방식으로 기록된 사운드 파일에 액세스하고 발신 호출자에게로 상기 파일을 작동한다. 작동된 상기 사운드 파일은 예를 들면 기 기록된 메시지 등의 리스트를 검색하기 위하여 특정한 기능의 실행 예를 들면 메시지를 기록하는데 사용될 수 있는 Key presses의 순서에 관하여 발신 호출자를 명령하는데 사용될 수 있다.
단계 5340에서는 팩스톤 검출 시스템이 비동기식 루틴 auInputDataAsync 5340을 시작한다. 상기 auInputDataAsync 루틴 5340은 호출 프로그램으로 제어를 동기에 복귀하는 것보다는 메인 라인 프로그램과 동시에 실행되는 비동기식 프로그램이다. 상기 auInputDataAsync 루틴 5340은 사용자에 의한 key press를 검출하기 위하여 발신 호출을 감시하는데, 이는 특정한 key press 순서와 관련된 과업을 실행하는 루틴을 불러내는데 목적이 있다.
기재된 바와 같이 auCheckForFaxAsync 루틴 5315는 메인 프로그램과 동시에 실행되고, 팩시밀리톤이 검출되는 경우 및 그때에 auCheckForFax response 5318을 발생시킨다. 단계 5350에서는 팩스톤 검출 시스템은 auCheckForFax 응답 5318 응답이 수신되었는지 여부를 보기 위하여 검사한다. 응답이 수신된 경우 이는 발신 호출이 팩시밀리 전송임을 나타내고 상기 팩스톤 검출 시스템은 입중계 호출을 음성/팩스 프로세서(VFP)5380으로 확장한다. 아무런 auCheckForFax 응답 5318이 미리 결정된 시간(예를 들면 7초)내에 수신되지 않는 경우, 상기 팩스톤 검출 시스템을 상기 호출의 발신자는 팩시밀리 장치가 아닌 것으로 결론을 내고 auCheckForFaxAsync 루틴 5315를 종료한다. 어떠한 실행에 있어서는 비동기식 인터럽션 처리 프로세스를 통하여 검사를 실행하는 것이 바람직할 수 있다. 상기와 같은 실행에 있어서는, 실행-시간 루틴이 auCheckForFax 응답 5318 이벤트가 발생할 때 제어를 획득하도록 설정될 수 있다. 상기 실행-시간 루틴은 예를 들면 auCheckForFax 응답 5318 이벤트를 처리하기 위하여 예외 핸들러(exception handler)를 규정하는 C++catch 구조를 사용하여 실행될 수 있다.
단계 5350의 결정에 뒤이어, 단계 5360에서의 상기 팩스톤 검출 시스템은 후속 하는 입중계 호출을 기다린다.
도 54A부터 54E 까지는 팩스 및 음성 메일박스를 위한 VFP Completion 프로세스를 보여주는 흐름도를 묘사한다. 도 54A에 묘사된 바와 같이 상기 단계 5401에서의 VFP Completion 루틴은 번지 지정된 메일박스에 대응하는 기록에 대한 데이터베이스를 검색한다. 단계 5405에서는 상기 VFP 완료 루틴은 메일 박스 기록이 성공적으로 검색되었는지 여부를 보기 위하여 검색한다. 메일박스 기록이 발견되지 않는 경우, 단계 5407에서 상기 VFP 완료 루틴은 원하는 메일박스 기록이 발견되지 않음을 나타내는 VCS 경보를 발생한다. 메일박스 기록이 발견되지 않았기 때문에 상기 VFP 완료 프로세서는 메일박스 어드레스의 속성을 시험할 수 없을 것이다. 그러나 메일 박스 기록이 발견되었는지 여부에 불구하고 제어는 단계 5409로 진행된다. 단계 5409에서는 상기 VFP 완료 프로세서가 번지 지정된 메일박스가 가득 차있는지 여부를 결정하기 위하여, 존재한다면, 메일박스 기록의 컨텐트를 시험한다. 번지 지정된 메일박스가 가득 찬 경우, 단계 5410에서는 상기 VFP 완료 루틴은 번지 지정된 메일 박스가 가득 차 있고 추가적인 메시지 저장이 불가능함을 나타내는 에러 메시지를 나타내고 단계 5412로 빠져나간다.
단계 5414에서는 상기 VFP 완료 프로세서가 VFP 호출의 모드를 얻는다. 상기 모드는 발신 호출자에 의하여 공급된 dial string으로부터 파생되고 pstCallState 구조의 enCurrentNum field에 저장된다. 상기 dial 스트링은 다음과 같은 포맷을 가지고 있다:
{
char number[10]; /* 10-digit 8xx number by user*/
char asterik; /*constant '*' */
char mode; /*1-byte mode*/
char octothorp; /*constant '#' */
}
상기 모드는 다음의 값을 가진다:
1 게스트 음성 메일
2 음성 주해를 가진 게스트 팩스
3 음성 주해를 가지지 않는 게스트 팩스
4 사용자 음성/팩스 검색
5 사용자 리스트 유지
6 메일 상자의 사용자 기록
단계 5416에서는, 상기 VFP 완료 프로세서는 데이터 베이스로부터 경로 지정된 메일박스와 관련된 경로 번호를 검색한다. 단계 5418에서는 상기 경로번호가 SIS layer에 전달된다.
도 5413에 묘사된 바와 같이, 단계 5420과 함께 계속된다. 단계 5420에서는 상기 VFP 완료 프로세서가 상기 VFP가 호출 전송을 용인하는지 여부를 결정하는데 사용되는 응답 감독 플래그를 초기화한다. 단계 5422에서는 상기 VFP 완료 프로세서가 호출을 처리하기 위하여 SisCollectCall을 호출한다. 상기 호출이 성공적으로 이루어지면, 단계 5424는 단계 5422의 SisCollectCall 발동이 미리 결정된 재 시도 횟수까지 반복되게 한다.
단계 5426에서는 상기 VFP 완료 프로세서가 otto.cfg 파일로부터 미리 결정된 타이머 만료 값을 얻는다. 상기 타이머 만료 값은 시간 량으로 설정되어 있는데, 상기 시간동안 응답이 수신되지 않는 경우, VFP 완료 프로세서가 VFP가 현재 도달할 수 없음을 결론 내릴 수 있다.
단계 5428에서는 상기 VFP 완료 프로세서가 단계 5426으로부터의 값에 따라 타이머를 설정한다. 단계 5430에서 상기 VFP 완료 프로세서는 응답 감독이 단계 5424에서의 설정된 타이머의 만료보다 우선하여 발생하였는지 여부를 보기 위하여 검사한다. 만약 그렇다면 제어는 제어를 VFP로 전송하기 위하여 단계 5430으로 진행된다.
도 54C는 단계5430에서의 단정적인 결정에 대한 응답으로 제어를 VFP로 전송하는 오퍼레이션을 묘사하고 있다. 단계 5440에서는 단계 5428에서 설정된 어떠한 계류중의 타이머도 취소된다. 단계 5442에서는 상기 VFP 완료 프로세서는 상기 VFP를 보류상태에 두기 위하여 루틴 sisOnHoldTerm ()을 호출한다. 단계 5444에서는 상기 VFP 완료 프로세서 발신 호출을 보류 상태에서 벗어나게 하기 위하여 루틴 sisOffHoldOring()을 호출한다.
단계 5446에서는 상기 VFP 완료 프로세서는 미리 저장되고 디지털 방식 기록된 사운드 파일을 작동시키는데, 이는 VFP로 전송하는 프로세스 동안에 발신 호출자가 기다리도록 명령한다. 단계 5448에서는 상기 VFP 완료 프로세서가 발신 호출을 다시 보류상태에 두기 위하여 루틴 sisOnHoldOring()을 호출한다. 단계 5450에서는 상기 VFP 완료 프로세서가 VFP를 보류 상태에서 벗어나게 하기 위하여 루틴 sisOffHoldTerm을 호출한다. 단계 5452에서 상기 VFP 완료 프로세서는 auPlayDigits 루틴을 호출하는데 이는 파라미터로서 번지 지정된 메일박스 번호, 필드 분리를 나타내는 asterisk('*'), 모드 및 명령줄의 마지막을 나타내는 octothorp('#')로 이루어지는 스트링을 상기 VFP 완료 프로세서로 전달한다.
단계 5454에서는 상기 VFP 완료 프로세서 otto.cfg 파일로부터 타임아웃 값 Ack Timeout 및 interdigit delay value를 얻는다. 상기 Ack timeout 값은 VFP 완료 프로세서가 어떠한 응답도 VFP로부터 곧 다가오지 않을 것으로 결정하기 전에 시간 량을 결정하는데 사용된다. 상기 interdigit delay value는 전화 keypad press를 나타내는 송신된 음성 신호사이의 시간을 측정하는데 사용된다. 단계 5456에서는 상기 VFP 완료 프로세서는 VFP로부터 응답을 얻기 위하여 InputData 루틴을 호출한다.
단계 5440 내지 5456을 뒤이어서 또는 단계 5430에서의 부정적 결정에 뒤 이어서, 제어는 도 54D에 도시된 바와 같이 단계 5460으로 진행된다. 단계 5460에서는 상기 VFP 완료 프로세서는 VFP로부터 응답을 요청한다. 단계 5462에서는 상기 VFP 완료 프로세서는 만료된 5428 단계에서 설정된 타이머 또는 VFP 응답을 기다린다. 단계 5464에서 상기 VFP가 응답하면, 상기 VFP 완료 프로세서는 단계 5446으로 진행된다.
단계 5446에서는 상기 VFP 완료 시스템 VFP 응답을 검사하고 적절한 BDR term 상태 기록을 작성한다. 상기 응답은 TI 플랫포옴으로부터의 수신통지를 나타낸다. '00'의 응답은 성공을 나타내고, 상기 VFP 완료 프로세서는 BDR_STAT_NORMAL 인디케이터를 기입한다. '01' 응답은 상기 VFP가 번지 지정된 메일 상자에 대한 키이를 수신하지 못했음을 나타내고, 상기 VFP 완료 프로세서는 BDR_STAT_DLINE_TI_NO_DIGITS 인디케이터를 기입한다. '02' 응답은 상기 VFP가 상기 키이를 수집하는 동안 종료되었음을 나타내고, 상기 VFP 완료 프로세서는 BDR_STAT_DLINE_TI_FORMAT 인디케이터를 기입한다. '03' 응답은 상기 번지 지정된 메일박스가 발견되지 않음을 나타내고, 상기 VFP 완료 프로세서는 BDR_STAT_DLINE_TI_MAILBOX 인디케이터를 기입한다. 어떠한 응답도 수신되지 않는 경우, BDR_STAT_DLINE_TI_NO_RSP 인디케이터가 기입된다. BDR 표지에 뒤이어 제어는 도 54E에 도시된 바와 같이 단계 5480으로 진행된다.
어떠한 응답도 VFP로부터 수신되지 않는 경우, 단계 5428에서 설정된 타이머는 만료되고, 제어는 단계 5468로 전달된다. 단계 5468에서는 상기 VFP 완료 프로세서는 VFP가 응답하지 않았음을 나타내는 VCS 경보를 준다. 단계 5470에서는 상기 VFP 완료 프로세서가 VFP로의 호출을 단절하기 위하여 루틴 sisReleaseTerm()을 호출한다. 단계 5472에서는 VCS 완료 프로세서가 발신 호출을 보류상태에서 벗어나게 하기 위하여 루틴 sisOffHoldOrig를 호출한다. 단계 5474에서는 상기 VFP 완료 프로세서가 아직 취소되지 않은 미해결의 모든 타이머를 취소하기 위하여 tiCancel Timers를 호출한다. 단계 5476에서는 상기 VFP 완료 프로세서가 미리 저장되고 디지털 방식으로 기록된 사운드 파일을 작동시키는데, 상기 사운드 파일은 발신 호출자에게 VFP 완료 프로세서가 VFP로 접속할 수 없었음을 보고한다.
단계 5476 또는 단계 5466 중 어느 한 단계 후에(단계 5464의 결정에 의존됨)제어는 도 54E에 도시된 바와 같이 단계 5480으로 진행된다. 단계 5480에서는 상기 VFP 완료 프로세서가 발신 호출자가 가입 사용자인지를 보기 위하여 검사한다. 가입 사용자인 경우, 제어는 단계 5482로 전달된다. 단계 5484에서는 상기 VFP 완료 프로세서가 상기 발신 호출자가 게스트 사용자인지를 보기 위하여 검사한다. 게스트 사용자인 경우 제어는 단계 5482로 전달된다. 그리고 나서 단계 5482에서는 호출자가 VFP 요청을 시작하는 기점인 메뉴로 발신 호출자를 돌려보낸다. 발신 호출자가 가입 사용자도 게스트도 아닌 경우 제어는 단계 5486으로 전달된다. 단계 5486에서는 발신 호출자가 팩스 호출인 것으로 추정되고, 그리고 나서 상기 호출은 단절된다.
도 55A 및 55B는 페이저 종료 프로세서의 오퍼레이션을 묘사한다. 단계 5510에서 상기 페이저 종료 프로세서는 호출자를 식별하기 위하여 사용될 수 있고 페이저 가입자에 의하여 콜백되는 번호를 식별하기 위하여 페이징 장치 상에 디스플레이 될 수 있는 전화 번호를 얻기 위하여 GetCallback 루틴을 호출한다. 상기 GetCallback 루틴은 도 56과 관련하여 이하에서 상세히 기술된다.
단계 5515에서 상기 페이저 종료 프로세서는 전화번호가 GetCallback에 의하여 복귀하는 지를 보기 위하여 검사한다. 어떠한 번호도 복귀되지 않는 경우, 단계 5520에서는 상기 페이저 종료 프로세서가 상기 호출이 종료되어야 함을 지시하고 단계 5522에서는 또 다른 서비스를 선택하기 위하여 호출자에게 메뉴를 제공한다.
번호가 복귀되지 않는 경우 번지 지정된 페이저 PIN은 단계 5530에서 데이터 베이스로부터 얻어진다. 상기 페이저 종료 프로세서는 단계 5530에서 검색된 페이저 PIN 및 단계 5510에서 얻어진 콜백 번호로 이루어지는 페이저 다이얼 스트링을 구성한다. 단계 5532에서는 상기 페이저 종료 프로세서는 페이저의 타입을 얻고 경로지정 정보는 데이터 베이스로부터 얻어진다. 단계 5534에서는 상기 페이저 종료 프로세서가 번지 지정된 타입의 페이저에 더하여 파라미터를 규정하는 페이저 구문분석(parse) 스트링을 얻기 위하여 상기 구성 배치 파일을 검사한다. 단계 5536에서는 상기 페이저 종료 프로세서는 요청된 페이저 구문 분석 스트링이 성공적으로 검색되었는지를 보기 위하여 검사한다. 성공적으로 검색되지 않은 경우, 단계 5538에서 상기 페이저 종료 프로세서는 BDR term 상태를 BDR-STAT-PAGER-NOT-FOUND로 설정함으로써 실행될 수 없음을 나타내고, 그리고 단계 5540에서 또 다른 서비스를 선택하기 위하여 상기 호출자에게 메뉴를 제공한다.
상기 페이저 구문분석 스트링이 성공적으로 검색된 경우, 상기 페이저 종료 프로세서는 도 55B에 도시된 바와 같이 단계 5550으로 진행된다. 단계 5550에서 상기 페이저 종료 프로세서는 페이저 서브 시스템을 호출하는데, 상기 페이저 서브시스템은 루트 번호, 다이얼 스트링 및 페이저 구문분석 스트링을 상기 페이저 종료 프로세서로 전달한다. 단계 552에서 상기 페이저 종료 프로세서는 페이저 서브 시스템으로부터의 복귀 코드를 검사한다. 페이지가 성공적으로 완료되면, 단계 5554에서 상기 페이저 종료 프로세서는 디지털 방식으로 미리 기록된 메시지를 상기 호출자에게 들려주는데, 상기 메시지는 호출자에게 페이지가 성공적으로 송신되었음을 알려준다. 단계 5556에서는 enEndCallStatus 필드가 페이저 호출 완료를 표시하기 위하여 갱신된다. 단계 558에서는 전송 상태가 공백으로 표시되는데 이는 호출자를 전송할 필요가 없음을 나타내고, 단계 5560에서는 상기 페이저 종료 프로세서가 사용자에게 또 다른 서비스를 선택하는 것 또는 호출을 종료하는 것을 허용하는 메뉴를 제공한다.
페이지가 성공적으로 완료되지 않은 경우, 상기 페이저 종료 프로세서는 단계 5570에서 호출자가 페이지 시도동안 단절되었는지 여부를 검사한다. 상기 호출자가 단절된 경우 단계 5575에서 상기 페이저 종료 프로세서는 단절에 우선하여 페이지가 송신되었는지를 보기 위하여 검사한다. 상기 페이지가 단절에 불구하고 송신된 경우, 단계 5580에서의 상기 페이저 종료 프로세서는 단계 5580에서의 페이지 요청에 정상 종료를 나타내고 상태를 단계 5582에서 완료된 것으로 설정한다. 단계 5584에서는 상기 페이저 종료 프로세서가 상기 사용자에게 또 다른 서비스의 선택 또는 상기 호출의 종료를 허용하는 메뉴를 제공한다.
만약 페이지가 페이져 착신 프로세서로 전송되지 않았으면, 페이져 착신 프로세서는 스텝(5586)에서 페이지요구가 비정상적으로 종료되었음을 나타내고, 스텝(5588)에서 호출자가 단절되었음을 표시한다. 스텝(5590)에서 페이져 착신 프로세서는 사용자에게 메뉴를 제공하여 사용자가 다른 서비스를 선택하거나 또는 호출을 종료할 수 있도록 한다.
호출자가 단절되면, 스텝(5572)에서 페이져 착신 프로세서는 실패원인을 나타내는 코드를 설정한다. 이때, 실패타입은 BDR_STRT_PAGER_ROUTE_NUM(무효한 루트번호에 대한)와, BDR_STAT_PAGER_CRIT_ERROR(발신콜에서의 실패에 대한)와, BDR_STAT_PAGER_TIMEOUT(소정 타임아웃 시간간격에서 콜을 확인응답하기 위한 페이져의 실패에 대한), BDR_STAT_PAGER_DIGITS_HOLD(페이져 어드레스에 해당되는 디지트를 방송하기 위한 페이져 서브시스템의 실패에 대한)와, BDR_STST_PAGER_DISC(페이징시스템의 조기 절단을 위한) 및 BDR_STAT_PAGER_NOT_FOUND(무효한 문자열(parse string)에 대한)로 구성된다.
그리고, 과정(5592)에서, 페이져 착신 프로세서는 상기 스텝(5572)에서 선택된 에러코드를 BDR로 통지한다. 스텝(5582)에서 페이져 착신 프로세서는 페이지가 전송될 수 없음을 나타내는 기 녹음된 디지털 사운드파일을 방송하며, 스텝(5595)에서 콜 상태 종료(EndCallStatus)필드는 페이져 콜완료를 표시하기 위해 갱신된다. 또한, 스텝(5597)에서 전송상태는 블랭크로 표시하여, 페이지가 호출자에게 전송될 필요가 없다는 것을 나타내며, 과정(5599)에서 페이져 착신 프로세서는 사용자에게 메뉴를 제공하여 사용자가 다른 서비스를 선택하거나 또는 콜을 종료할 수 있도록 한다.
도 56에는 스텝(5510)에서, 페이져 착신 프로세서로부터 호출된 콜백 읽기(GetCallback)루틴이 도시되어 있다. 스텝(5610)에서 상기 콜백 읽기루틴은 적절한 시작(start) 및 디지트간 지연들을 정의한 상수들을 otto.cfg파일로부터 얻는다. 또한, 스텝(5615)에서 상기 콜백 읽기루틴은 호출자가 적절한 키패드(keypad) 키들을 누른 후 우물정자("#")를 눌러 콜백 전화번호를 입력하도록 촉구하는 기 녹음된 디지털사운드 파일을 호출자에게 방송한다. 스텝(5620)에서 콜백 읽기루틴은 호출자가 입력한 전화번호를 읽으며, 수신된 데이터는 스텝(5625)에서 BDR에 위치한다. 스텝(5630)에서 상기 콜백 읽기루틴은 입력된 전화번호가 문자("#")에 의해 종료되었는지 체크한다. 이때, 전화번호 입력이 종료되었으면 콜백 읽기루틴은 스텝(5635)에서 성공(success)를 반환하고, 전화번호 입력이 종료되지 않았으면 콜백 읽기루틴은 스텝(5640)에서 재시도 카운트가 초과되었는지 체크한다. 만약 재시도 카운트가 초과되지 않았으면 스텝(5615)부터 실행을 반복하고, 재시도 카운트가 초과되었으면 스텝(5650)에서 상기 콜백 읽기루틴은 전화번호가 성공적으로 수신되지 않았음을 나타내는 기 녹음된 디지털 메시지를 방송하고, 스텝(5660)에서 호출프로그램에 대한 에러조건을 반환한다. 다음의 내용은 ARU(DTMF)와 고객서비스를 경유하여 억세스된 다이렉트라인(MCI) 프로파일 항목들의 사용자관리용 사용자 인터페이스를 나타내고 있다.
(비활성)활성 계정((De)Activate Account)
파인드-미 루팅(Find-Me Routing)
스케쥴(Schedules)
3-세자리 시퀀스(3-Number Sequence)
제1,제2,제3전화번호 및 호출-무응답 타임아웃(First, Second and Third Numbers and Ring-No-Answer Timeouts
페이져 온/오프(Pager On/Off)
오버라이드 루팅(Override Routing)
최종(대체)루팅(Final (Alternate) Routing)
호출자 스크리닝(Caller Screening)
음성메일 메시지의 페이져 통지(Pager Notification of Voicemail Messages)
팩스메일 메시지의 페이져 통지(Pager Notification of Faxmail Messages)
스피드 다이얼 번호(Speed Dial Numbers)
다음의 테이블은 전용선(directline)(MCI) 고객이 DTMF를 통하여 갱신가능한 필드의 리스트로서, 상기 리스트는 서비스하고 하는 모든 필드들을 포함하는 것이 아니라 단지 전용선(MCI) 어플리케이션에 의해 사용되는 필드들만을 포함한다.
| 필드명 |
| 800# + PIN제1착신(Primary Termination)제2착신(Secondary Termination)제2착신-아웃 값(Secondary Time-out Value)제3착신(Tertiary Termination)제3타임-아웃 값(Tertiary Time-out Value)오버라이드 루팅오버라이드 타임-아웃 값대체 루팅(Alternate Routing)대체 타임-아웃 값PIN_플래그(Flags),비트 10 스케쥴(Schedule) 1비트 11 스케쥴 2비트 15 페이지 온(Page on)Vmail비트 16 페이지 온 팩스(Page on Fax)상태_플래그(State_Flags), 즉비트 3 계정(Account)가용성(Available)비트 13 페이져 온/오프비트 14 파인드-미온/오프(On/Off)비트 15 음성메일온/오프비트 16 팩스 온/오프콜 스크리닝 상태디폴트 팩스번호(Default Fax Number)스피드 다이얼 #1(Speed Dial #1)스피드 다이얼 #2스피드 다이얼 #3스피드 다이얼 #4스피드 다이얼 #5스피드 다이얼 #6스피드 다이얼 #7스피드 다이얼 #8스피드 다이얼 #9 |
사용자는 http:/www.mci.services.com/directline을 통하여 그의 전용선(MCI)을 억세스할 것이다. 유효 계정(Account) ID와 패스코드(Passcode)를 입력하면 사용자의 루팅 스크린이 제공될 것이다. 사용자는 탭(Tab)을 클릭하여 한 스크린에서 다른 스크린으로 이동할 수 있다. 만약, 사용자가 세션(session)동안 갱신된 스크린으로 복귀하면, 스크린은 그가 마지막으로 떠났을 때처럼 즉, 그가 제공한 어떤 갱신들이 데이터에서 반영될 때처럼 디스플레이될 것이다. 만약, 다음으로 사용자가 그의 프로파일 관리스크린을 개시할 때 시스템사용을 종료(로그오프)하거나 또는 타임아웃하면, 디스플레이되는 데이터는 새로운 질의(Query)로부터 800PIN 1Call 데이터베이스까지가 될 것이다. 마지막 15분내에 이루어진 갱신들은 웹서버를 지원하는 NIDS데이타베이스들로 도달되지 않았을 지도 모르게 되어, 데이터는 최근의 어떤 갱신들을 반영하지 않을지도 모른다.
다음의 항목들은 인덱스 프레임에서 나타나며, 관련된 웹서버들에 대한 링크로서 작용한다. 사용자가 항목들중 하나를 클릭하면 관련 스크린이 텍스트 프레임에서 디스플레이될 것이다.
콜 루팅(Call Routing)
게스트 메뉴(Guest Menu)
오버라이드 루팅(Override Routing)
스피드 다이얼 번호(Speed Dial Numbers)
음성메일(Voicemail)
팩스메일(Faxmail)
콜 스크리닝(Call Screening)
또한, 로그오프(LOGOFF)버튼은 인덱스 프레임의 하단부에 나타나며, 사용자가 상기 버튼을 클릭하면 바로 토근(프레임)이 종료되며, 사용자는 로그인 스크린(Login Screen)으로 복귀되어질 것이다.
F. 로그인 스크린
도 57에는 온라인 프로파일관리로 억세스하기 위한 사용자 로그인 스크린(700)이 도시되어 있다.
전용선(MCI) 번호(702)
계정 ID는 전용선(MCI) 고객의 10-디지트 억세스번호, 즉 포맷 8xx xxx xxxx가 될 것이다. "000"의 PIN과 연쇄적으로 접속된 이 번호는 고객 프로파일 데이터를 포함하고 있는 1Call 데이타베이스의 억세스키가 될 것이다. 만약, 프로그램 플래그(PIN 플래그 4)가 "N"으로 세팅되어 있으면 사용자는 성공적인 로그인을 할 수 없을 것이며, 해당 로그인 시도가 계정상에서 이루어졌다면 로그인 에러(Login Error)스크린이 디스플레이될 것이다.
패스코드(704)
패스코드는 ARU 인터페이스를 경유하여 사용자 옵션들을 억세스하기 위하여 사용되던 것과 동일하며, 6-문자 숫자열이다. 이 필드에서는 사용자 입력은 나타나지 않으며, 입력된 각 문자는 별표("*")로 디스플레이될 것이다.
상태 메시지(Status message)
directline(MCI) Number: "당신의 전용선(MCI) 번호를 입력하시오"
Passcode: "당신의 패스코드를 입력하시오"
G. 콜 루팅 스크린(Call Routing Screen)
도 58에는 사용자의 콜 루팅 명령을 설정 또는 변경하기 위해 사용되는 콜 루팅 스크린(710)이 도시되어 있다.
"콜 수용(Accept Calls)"구역(712)
사용자는 적절한 무선버튼(174 또는 716)을 선택하여, 그의 계정상의 구역(712)에서 콜이 수신되었는지를 지정할 수 있으며, 그 버튼은 바로 고객의 전용선 기록에 있는 계정 유효 플래그(Account Available flag)(상태플래그, 비트3)에 대응된다.
| 무선 버튼 | 계정 유효 플래그 |
| 콜 수신콜 비수신 | YN |
"아래 구역에서 선택하시오"구역(718)
사용자는 게스트 호출자가 게스트 메뉴 또는 오바라이드 루팅처리를 수신해야 할 것인지를 설정한다. 이 선택은 게스트 메뉴 또는 오버라이드 루팅 스크린에 있는 데이터가 적절한지를 나타낸다. 고객의 오버라이드 착신은 사용자의 선택에 따라 다음과 같이 나타날 것이다.
| "무선 버튼들을 ..."게스트들에게 제공" | 오버라이드 착신 |
| 게스트 메뉴메뉴 없음-오버라이드 루팅 | 0008*(디폴트 음성메일) |
"내가 받을 수 없을 때"구역(720)
사용자는 그 가 받을 수 없었던 콜들의 콜처리를 지정하며, 고객 기록에 있는 대체 착신은 다음과 같이 갱신된다.
| 무선 버튼 | 대체 착신 |
| 음성메일페이져(무선호출기)음성메일 또는 페이져-호출자 선택최종 메세지 | 08070905 |
상태 메시지
사용자의 선택에 따라 다음의 상태 메시지들이 각 선택의 확인을 위해 사용자에게 제공된다.
Do not Accept Calls: "콜은 당신의 전용선(MCI)번호로 수신되지 않을 것입니다.
Accepts Calls: "콜은 당신의 전용선(MCI) 번호로 수신될 것입니다."
Guest Menu: 호출자가 당신과 어떻게 접촉하고자 하는지 선택하도록 해주십시요."
No Menu-Override Routing: "당신이 선택한 특정 장소로 호출자를 루트하십시요"
Voicemail: "호출자는 음성메일을 남기도록 요청될 것입니다."
Pager: "호출자는 당신에게 페이지를 남기도록 촉구될 것입니다."
Voicemail or Pager: "호출자는 당신에게 음성메일을 남기거나 또는 페이지를 보내는 것을 선택할 수 있습니다."
Closing Message: "호출자는 차후 다시 호출해달라는 메시지를 들을 것입니다."
H. 게스트 메뉴 구성스크린(Guest Menu Configuration Screen)
오버라이드 루팅이 디스에이블되면, 즉 게스트메뉴가 선택되면, 게스트 메뉴가 게스트 호출자에게 제공된다. 사용자는 다음 내용으로 게스트 메뉴 구성스크린(730)(도 59)을 사용하여 자신의 게스트 메뉴를 구성할 수 있다.
"파인드-미(Find-Me) 루팅" 체크박스(732)
이 단계에서 파인드-미 루팅은 해제할 수 없다. 상기 체크박스는 파인드-미 플래그(9비트의 PIN플래그와 퇴색된 옵션)에 근거하여 체크될 것이다. 만약, 가입자가 국내 전화번호를 위해 "리딩(leading) 1"을 입력하면 상기 리딩 1은 전화번호로부터 분리되며, 단지 NPA-Nxx-xxxx만이 데이터베이스에 저장될 것이다. 자신의 3자리 시퀀스 번호들을 프로그래밍할 때 가입자는, 시스템이 링-무응답(Ring-no-Answer)결정이 이루어지기전에 허용해야만 하는, 1에서 6까지의 링의 수를 선택할 수 있다. 상기 링의 수는 초단위로 데이터베이스에 저장되며, 상기 초 계산을 위한 공식은 6*Ring_Limit가 될 것이다. 만약, 아무 값도 입력되지 않으면 디폴트(초기설정)는 3 링 또는 18초이다. 데이터베이스로부터 독출할 때 0에서 8초까지는 1링으로 번역될 것이다. 8이상 최대 16까지의 초들은 6에 의해 나누어져 링의 수를 결정하기 위하여 라운드된 결과로 분배될 것이다.
고객의 기록에 대한 갱신은 다음과 같다.
| 무선버튼 | 스케쥴1/2플래그 | 제1착신 및 타임아웃 | 제2착신 및 타임아웃 | 제3착신 및 타임아웃 |
| 스케쥴3-자리시퀀스 | Both YBoth N | 변경없음첫번째 입력된번호** 및 타임아웃 | 변경없음두번째 입력된번호** 및 타임아웃 | 변경없음세번째 입력된번호** 및 타임아웃 |
**국내/국제 단말은 부록A에서 기술된 것처럼 확인될 것이다.
"음성메일을 남기십시요(Leave a Voicemail)"체크박스(734)
이 단계에서, 음성메일은 삭제될 수 없으며, 상기 체크박스는 Vmail플래그(3비트의 PIN플래그)와 "grayed out"옵션에 근거하여 체크될 것이다.
"팩스를 전송하십시요(Send a Fax)"체크박스(736)
이 단계에서 팩스는 삭제될 수 없으며, 상기 체크박스는 팩스단말 플래그(13비트의 PIN플래그)와 퇴색된 옵션에 근거하여 체크될 것이다.
"페이지를 전송하십시요(Send a Page)"체크박스(738)
사용자는 Send me a page라고 명명된 박스를 토글하여, 호출자가 페이징 옵션을 제공받게 될 것인지를 지정할 수 있다. 상기 박스는 고객의 전용선기록에 있는 페이져 온/오프 플래그(13비트의 상태플래그)에 직접 대응된다.
| 페이지 체크박스 | 페이지 온/오프 플래그 |
| 체크됨체크되지 않음 | YN |
상태 메시지
Find Me Routing: "당신이 어디에 있든 호출자가 '당신을 찾도록(find you)' 해줍니다."
Schedule Routing: "당신의 스케쥴에 따라 호출자를 루트하십시요."
Three Number: "호출자는 3개의 번호를 통하여 당신을 찾을 수 있습니다."
1st#, 2nd#, 3rd#: "전화번호를 입력하십시요."
1st, 2nd, 3rdRing Limit: "이 번호로 호출할 횟수를 입력해 주십시요."
Leave a Voicemail: 호출자는 당신에게 음성메일을 남길 수 있습니다."
Send a Fax: "호출자는 당신에게 팩스를 전송할 수 있습니다."
Send a Page: "호출자는 당신에게 페이지를 남길 수 있습니다."
I. 오버라이딩 루팅 스크린(Override Routing Screen)
도 60에는 사용자가 모든 콜을 선택된 목적지로 루트할 수 있도록 해주는 오버라이드 루팅 스크린(740)이 도시되어 있다. 사용자가 도 59의 게스트 메뉴(730)의 표시를 가결하여, 모든 그의 콜들을 특정 목적지로 루트하기를 선택했을 때, 고객 기록에 있는 오버라이드 단말을 다음과 같이 갱신될 것이다.
| 오버라이드 루팅 무선버튼 | 오버라이드 단말 |
| 선택된 게스트 메뉴음성메일페이져파인드-미전화번호 | 00080706입력된 번호** |
이 옵션이 프로파일 스크린으로부터 초기에 선택되었을 때, 사용자의 고객기록에는 오버라이드 루팅 설정은 없을 것이다. 이 스크린이 제공되었을 때 디폴트 설정은 이용가능한 경우 음성메일이 될 것이며, 음성메일이 이용가능하지 않다면 파인드-미가 될 것이다.
상태 메시지
Find Me Routing: "당신이 어디에 있든 호출자가 '당신을 찾도록 해줍니다."
Schedule Routing: "당신의 스케쥴에 따라 호출자를 루트하십시요."
Three Number: "호출자는 3개의 번호를 통하여 당신을 찾을 수 있습니다."
1st#, 2nd#, 3rd#: "전화번호를 입력하십시요."
1st, 2nd, 3rdRing Limit: "해당 번호의 호출 횟수를 입력하십시요."
Voicemail: 호출자는 당신에게 단지 음성메일을 남기도록 촉구될 것입니다."
Send a Page: 호출자는 당신에게 단지 페이지를 남기도록 촉구될 것입니다."
Temporary Override Number: "호출자는 당신이 선택한 번호로 단지 루트될 것입니다."
Telephone Number Ring Limit: "해당 번호의 호출 횟수를 입력하십시요."
J. 스피드 다이얼 스크린
도 61에는 속도 다이얼 번호 스크린(744)이 도시되어 있다. 사용자는 웹 인터페이스를 통하여 9개의 스피드 다이얼 번호를 갱신할 수 있다. 웹 페이지상의 1에서 9까지의 스피드 다이얼번호는 가입자의 기록상에 있는 동일한 스피드 다이얼 번호들에 대응된다. 국내 및 국제 착신은 하기의 기술된 바와같이 확인될 것이다.
상태 메시지
1-9: "스피드 다이얼번호 〈1-9〉를 입력하십시오"
도 62에는 음선메일 스크린(750)이 도시되어 있다.
"Receive Voicemail Messages"체크박스(752)
"Page me when I receive"체크박스
"내가 새로운 음성메일 메시지를 받을 때 나에게 페이지해 주십시요"체크박스(754)는 바로 고객의 전용선 기록에 있는 페이지 온 음성메일 플래그(Page on Vmail flag)에 대응된다.
| 페이져 통지 체크박스 | 페이지 온 팩스플래그 |
| 체크안됨체크됨 | NY |
상태 메시지
Receive fax: "호출자들은 당신에게 음성메일을 남길 수 있을 것이다."
Page me each time: "당신이 음성메일 메시지을 받을 때 당신은 페이지될 것이다."
도 63에는 팩스메일 스크린(760)이 도시되어 있다.
"My primary Fax numbers is" 필드(762)
"Receive Faxmail Messages" 체크박스(764)
이 항목의 프로파일 관리는 팩스메일 스크린상에 도시되는 것처럼 나타난다.
"Page me when I receive" 체크박스(766)
이 항목은 "내가 새로운 음성메일 메시지를 수신할 때 나에게 페이지해 주십시요"체크박스(766)처럼 나타난다. 이 박스는 바로 고객의 전용선 기록에 있는 페이지 온 팩스 플래그(Page on Fax flag)에 대응된다.
| 페이저 통지 체크박스 | 페이지 온 Vmail 플래그 |
| 체크안됨체크됨 | NY |
상태 메시지
Receive Fax...: "호출자들은 당신에게 팩스를 보낼 수 있을 것이다."
Page me each time...: "당신이 팩스를 받을 때 당신에게 페이지될 것이다."
도 64에는 콜 스크리닝 스크린(770)이 도시되어 있다. 사용자는 호출자 이름, 발신 번호 또는 호출자의 이름과 번호를 모두 이용하여 콜들의 스크린을 선택할 수 있으며, 콜 스크리닝 상태는 고객의 기록에서 다음과 같이 갱신된다.
| 콜 스크리닝 체그박스 | 무선 버튼 | 콜 스크리닝 상태 |
| 체크안됨체크됨 | n/a번호만이름만이름과 번호모두 | 00020103 |
상태 메시지
Allow me to screen...: "이 기능이 활성화되면 당신은 당신의 콜을 스크린할 수 있습니다."
Name only: "호출자의 이름이 착신측으로 제공될 것입니다."
Telephone number: "호출자의 전화번호가 착신측으로 제공될 것입니다."
Name and Telephone: "호출자의 이름과 전화번호가 착신측으로 제공될 것입니다."
도 65-67에는 사용자 프로파일 관리와 함께 사용되는 추가(Supplemental) 스크린(780),(782),(784)이 도시되어 있다.
로그인 에러 스크린(780)
이 에러 스크린은 무효한 계정번호, 패스코드 또는 맞지 않는 IP어드레스에 의해 로그인 시도가 실패하였을 때 제공되며, 또한, 사용자의 토큰이 종료되어 사용자가 다시 로그인을 요구할 때 디스플레이되는 스크린이다.
갱신 성공 스크린(782)
이 스크린은 갱신이 성공적으로 종료되었을 때 제공된다. "공란(blank)"은 '콜 루팅 옵션들은...갖는다 ', '게스트 메뉴 옵션들은...갖는다", '오버라이드 루팅은...갖는다', '스피드 다이얼 번호들은...갖는다', '음성메일 옵션들은...갖는다', '팩스메일 옵션들은..갖는다' 및 '콜 스크리닝 옵션들은...갖는다' 등으로 채워진다.
| 스크린 | 옵션 | 종속물 |
| 로그인 스크린 | 로그인(Login) | 프로그램(Follow-Me) 플래그 |
| 프로파일 스크린 | 콜 수용(Accept Calls) | 유효(Avail) 프로그래밍 플래그 |
| 음성메일로 최종 루팅 | 파인드-미 플래그와 음성메일 플래그 | |
| 페이져로 최종 루팅 | 파이드-미 플래그와 페이져 착신 플 래그 | |
| 음성메일 또는 페이져로 최종 루팅 | 파인드-미 플래그, 음성메일 플래그 및 페이져 착신 플래그 | |
| 게스트 메뉴 | 스케쥴(Schedules) | 파인드-미 플래그, 내장된 스케쥴 1 전환 및 내장된 스케쥴 2전환 |
| 3자리 (Three-Number) 시퀀스 | 파인드-미 플래그 및 국내착신 플래 그 또는 국제착신 | |
| 번호(1st, 2nd, 3rd) | 파인드-미 플래그 및 국내착신 플래 그 또는 국제 착신 플래그 | |
| 페이지 전송(Send | ||
| 오버라이드 루팅 | 스케쥴(Schedules) | 파인드-미 플래그, 내장된 스케쥴 1 전환 및 내장된 스케쥴 2전환 |
| 3자리 (Three-Number) 시퀀스 | 파인드-미 플래그 및 국내 착신 플래 그 또는 국제착신 | |
| 번호(1st, 2nd, 3rd) | 파인드-미 플래그 및 국내착신 플래 그 또는 국제 착신 플래그 | |
| 페이져 | 페이져 착신 플래그 | |
| 전화번호 | 파인드-미 플래그 및 국내착신 플래 그 또는 국제 착신 | |
| 스피드 다이얼 번호 | 1-9 | 스피드 다이얼 프로그래밍, 국내 종 료 플래그 또는 국제 종료 플래그 |
| 음성메일 스크린 | 내가...를 수신할 때 나에게 페이지 하시오 | 음성메일 플래그 및 페이져 착신 플래그 |
| 팩스메일 스크린 | 내가...를 수신할 때 나에게 페이지 하시오 | 팩스 착신 플래그 및 페이져 착신 플래그 |
| 콜 스크리닝 | 내가 ...를 스크린하도록 허용한다 | 콜 스크리닝 프로그래밍 |
갱신 실패 스크린(784)
이 스크린은 사용자가 하나 또는 그이상의 무효한 착신번호(들)을 입력하거나 또는 블랭크 제1번호로 그의 계정을 갱신했을 때 나타나며, 이때 계정은 정정이 수행되거나 또는 모든 번호가 성공적으로 확인될 때 까지 갱신되지 않을 것이다.
사용자 인터페이스의 다양한 스크린들중에서, 프로파일 옵션들은 다음의 플래그 설정에 근거하여, 옵션이 스크린으로부터 사용할 수 없음을 나타내는, "그레이드 아웃(grayed out)된다.
상술한 프로파일 옵션들의 일부를 위해, 확인체크는 다음과 같이 수행된다.
북미 다이얼링 플랜(NADP:North American Dialing Plan)번호들을 제외한 국제 번호들은, "011"로 시작되어야하며, 또는 프로그래밍을 위해서 수신되지 않을 것이다.
976 블로킹(blocking)은 다음과 같이 구현될 것이다.
국제 블로킹 데이터베이스는 프로그램된 번호가 차단된 정보/성인 서비스번호(Information/Adult Services number)가 아니라는 것을 보증하기 위하여, 패턴일치(Pattern match)를 찾는 카테고리 000, 타입 002와 프로그램된 NPA를 이용할 때 질의될 것이다. 만약, 일치가 발견되면 그 번호에 대한 프로그래밍은 허용되지 않을 것이다.
국가 설정(Country Set)블로킹은 다음과 같이 구현될 것이다.
전용선(MCI) 특성 기록의 국가설정은 프로그램된 번호의 국가코드에 대하여 확인될 것이다. 만약 착신국가가 상기 전용선(MCI) 국가설정에서 차단되어 있으면 그 번호에 대한 프로그래밍은 허용되지 않을 것이다.
프로그래밍 루팅(Programming Routing)
| 프로그램된 번호가...이면 | 다음의 확인체크를 수행 |
| 국내 | 국내 플래그976블로킹 |
| NADP | 국내 플래그976블로킹Term PCC, Auth Cset을 사용하는 Cset블로킹 |
| 국제 | 국제 플래그Term PCC, Auth Cset을 사용하는 Cset블로킹 |
프로그래밍 스피드 다이얼 번호(Programming Speed Dial Numbers)
| 프로그램된 번호가 ...이면 | 다음의 확인체크를 수행 |
| 국내 | 국내 Comp 플래그976블로킹 |
| NADP | 국내 Comp 플래그976블로킹Term PCC, Auth Cset을 이용하는 Cset블로킹 |
| 국제 | 국제 Comp 플래그Term PCC, Auth Cset을 이용하는 Cset블로킹 |
도 68은 사용자가 입력한 스피드 다이얼번호가 어떻게 확인되는가를 나타낸 플로우차트이며, 비가입자가 사용자를 호출할 때 게스트스크린상의 게스트에 의한 입력을 확인할 때에도 동일한 플로우차트가 적용될 수 있다.
본 발명인 집적화된 스위칭시스템 및 패킷전송 네트워크는 사용자들을 위한 개선된 부가기능들을 제공한다. 전용선(MCI)은 파인드-미 기능, 음성메일, 페이징, 팩스저장 및 착신서비스를 포함하는 부가서비스를 갖는 단일번호 억세스의 개인번호이다. 가입자 또는 사용자에게는 ISN 메인프레임상의 전용선(MCI) 데이타베이스에 있는 고객기록으로 입력되는 프로파일 정보가 요구된다. 제품의 부가기능은 다음과 같다.
개인 인사말(Personal Greeting): 사용자는 그의 게스트 호출자에게 재생될 개인 인사말을 녹음하는 옵션을 갖는다. 사용자가 개인 인사말을 녹음하면 "Welcome to 전용선(MCI)"라는 디폴트 인사말이 상기 녹음된 인사말로 대체된다.
게스트 메뉴: 게스트메뉴는 사용자가 어떤 부가기능을 예약했는가에 의해 정의된다. "완전히 로드된" 계정에 대하여 케스트호출자에게 통화를 하거나, 사용자를 페이지하거나, 팩스를 보내거나, 음성메일 메시지를 남기는 옵션들이 제공될 것이다.
파인드-미 기능을 위한 3-자리 시퀀스: 시스템은 3개의 번호로, 즉 제1번호, 제2번호 및 제3번호를 차례로 시험하여 사용자에게 도달하려고 한다. 만약, 이 번호들중의 어떤 번호에서 응답이 수신되지 않으면 콜은 대체루팅에서 규정된 것으로취급된다.
파인드-미 기능을 위한 2-레벨 스케쥴: 시스템은 사용자의 스케쥴을 질의하기 위해 현재의 요일/날짜/시간정보를 이용하는 2개의 번호로 사용자에게 도달하려고 시도한다. 그 시도는 사용자의 스케쥴1에서 스케쥴2순으로 수차례 수행된다. 만약, 응답이 수신되지 않으면 대체 루팅이 취급을 정의한다.
대체루팅은 사용자가 그에게 도달하여고 했던 게스트 호출자의 취급을 규정할 수 있도록 해주지만, 무응답이 시도된 번호들중의 어느 하나에서 수신된다. 대체 루팅을 위한 옵션은 음성메일, 페이져, 게스트가 선택한 음성메일 또는 페이저 또는 나중에 다시 호출할 것인지 호출자에게 묻는 종료 메시지들을 포함한다.
오버라이드 루팅은 사용자가 게스트 메뉴의 제공을 디스에이블시킬 수 있도록 해주며, 모든 게스트 호출자들을 위한 단일 취급을 규정한다. 옵션들은 전화번호에 대한 종료, 사용자가 정의한 파인드-미 시퀀스, 음성메일 또는 무선호출기를 포함한다.
디폴트 루팅(Default Routing)은, 게스트 메뉴가 제공되었을 때, 3번 시도후에 응답하지 않는 게스트 호출자에 대한 처리이다. 디폴트 루팅 옵션은 오퍼레이터로의 전환, 전화번호에 대한 종료, 파인드-미 시퀀스 또는 음성메일을 포함한다.
콜 스크리닝(Call Screening)은 접속되기전에 고지되어질 호출자를 사용자가 원하는아닌지를 사용자가 정의할 수 있도록 해준다. 옵션들은 콜 스크리닝을 포함하지 않고, 또는 이름으로 확인된 호출자, 발신 전화번호 또는 이름과 번호 모두를 갖는다.
사용자의 메뉴에서 "Place a Call"옵션은 사용자가 사용자가 호출할 수 있도록 해주며, 요금은 전용선(MCI) 계정으로 부과되도록 한다.
음성/팩스메일(Voice/Faxmail): 음성과 팩스 메시지는 사용자의 차후 검색을 위해 저장될 수 있으며, 사용자는 새로운 음성 및(또는) 팩스 메시지가 그의 메일박스에 쌓일 때 통지되도록 선택할 수 있다.
ISN(Intelligent Service Network)에 집적된 음성/팩스 플랫홈(VFP)은 ISN어플리케이션으로하여금 자신의 데이터베이스를 조회할 수 있도록 해주며, 요금부과기록이 VFP로부터 직접 제외될 수 있도록 해준다. 초기 전용선(MCI) 제품에 대한 변화들중에는 다음과 같은 항목들이 있다.
파인드-미 루팅
파인드-미 루팅은 가입자가 선택가능한 2가지 옵션, 즉 현재 구현된 3-자리 시퀀스 또는 2-레벨 스케쥴 옵션을 가는다. 스케쥴 옵션은 가입자의 스케쥴 1번역이 제1착신으로 취급되고, 가입자의 스케쥴 2번역이 제2착신으로 취급될 수 있도록 구현된다. 파인드-미 루팅은 콜 흐름도(Call Flow diagram)와 ARU 임팩트 구절(impact section)에 보다 상세히 기술되어 있다.
디폴트(Default) 루팅
디폴트 루팅은 호출자가 게스트메뉴의 촉구에 응답하지 않을 때 어플리케이션이 갖는 사전의 규정조치이다. 디폴트 루팅을 위한 옵션들은 전화번호, 음성메일, 파인드-미 루팅 및 오퍼레이터 전환을 포함한다.
음성/팩스 메시지 정보
가입자가 사용자 메뉴를 억세스할 때 그리고 메일박스가 다 차면, 어플리케이션은 새로운 음성 또는 팩스메시지의 수를 나타내는 메일박스 상태정보를 제공한다. 어플리케이션은 이 정보를 얻기 위하여 VFP 데이타베이스로 질의(query)를 보낸다
스피드 다이얼
가입자는 실시간으로 입력된 전화번호뿐만아니라 이제 프로그램된 스피드 다이얼번호로 호출할 수 있다. 이들 9개의 스피드 다이얼 번호들은 DTMF를 통하여 사용자가 프로그램할 수 있다.
K. ARU-콜 흐름
도 69A∼도 69I에는 상술한 전용선(MCI)제품의 소프트웨어적 구현을 나타내고, 발명의 보다 나은 이해에 도움이 되는 자동응답 유닛(ARU)의 콜 흐름도가 도시되어 있다.
도 269A에는 ARU콜를 처리하기 위한 시작점이 도시되어 있다. 콜이 개시되면 그 콜은 게스트 콜로 간주된다. 만약 호가 도달될 계정이 현재 온라인이 아니면, 스텝(69010)에서 ARU는 콜이 계정에서 수용될 수 없음을 나타내는 메시지를 방송한 다음 스텝(69012)에서 콜을 차단한다. 만약, ARU가 착신콜에서 팩스 톤(tone)을 감지하면, 스텝(69014)에서 ARU는 어노테이션 루틴(Annotation routine)을 수행하지 않고 ARU Xfer to Voice/Fax Geust Fax 루틴을 수행한다. 만약, 팩스톤이 감지되지 않으면 ARU는 스텝(69018)에서 도 69L에서 기술될 ARU 인사말 방송 루틴(ARU Play Greeting routine)을 수행한다. 이어서, ARU는 가입자가 착신콜들에 대하여 오버라이드를 지정하였는지 체크하여, 만약 지정하였으면 스텝(69020)에서 "오버라이드"의 파라미터를 지정하는 ARU 파인드 미 루틴을 수행한다. 이때, 상기 ARU 파인드 미 루틴은 나중에 도 69E∼69F에서 기술된다. 만약 오버라이드가 지정되지 않았으면 ARU는 스텝(69022)에서 도 69D에 기술된 ARU 게스트 메뉴 루틴을 수행한다.
도 69B에는 ARU 인사말 방송루틴이 도시되어 있다. 만약 고객 인사말이 녹음되어 있으면 ARU는 스텝(69030)에서 고객 인사말을 방송하고, 녹음되어 있지 않으면 스텝(69032)에서 미리 녹음된 일반 인사말을 재생한다.
도 69C에는 ARU 임시 인사말 방송루틴(ARU Play Temp Greeting routine)이 도시되어 있다. 만약, 임시 인사말이 녹음되어 있으면, ARU는 스텝(69034)에서 임시 인사말을 방송하고, 고객 인사말이 녹음되어 있으면 스텝(69036)에서 고객 인사말을 방송한다. 만약 그렇지 않으면 ARU는 스텝(69038)에서 미리 녹음된 일반 인사말을 방송한다.
도 69D에는 ARU 게스트 메뉴 루틴(ARU Guest Menu routine)이 도시되어 있다. 스텝(69040)에서 ARU는 호출자에게 가청 메뉴를 제공한다. 일예로서, 항목 "1"은 가입자에게로의 통화요구에 해당되고, 항목 "2"는 가입자를 위하여 음성메일 메시지를 남기도록 하는 요구에 해당된다. 그리고, 항목 "3"은 가입자에게 팩스를 보내도록 하는 요구에 해당되고, 항목 "4"는 가입자에게 페이지를 보내도록 하는 요구에 해당된다. 또한, 가입자는 자신 또는 호출자의 패스코드를 입력하여 ARU를 억세스할 수 있다.
만약 호출자가 가입자와의 통화를 요구하면, ARU는 호출자의 프로파일과 연관된 스케쥴 플래그들을 체크한다. 체크결과 만약, 가입자의 프로파일이 스케쥴에 의한 루팅을 나타내면, ARU는 스텝(69042)에서 파라미터로서 "Sched1"를 사용하는 도 69E∼69F의 파인드 미 루틴을 수행한다. 만약, 사용자의 프로파일이 스케쥴에 의한 루팅을 나타내지 않으면 ARU는 스텝(69044)에서 파라미터로서 "First"를 사용하는 ARU 파인드 미 루팅을 수행한다. 상기 ARU 파인드 미 루팅은 도 69E와 도 69F에서 상세히 기술될 것이다.
만약, 호출자가 음성 메일메시지를 남기기를 요구하면, ARU는 가입자의 메일박스가 찼는지 체크한다. 만약, 메일박스가 다 찼으면 녹음된 메시지가 방송되며 호출자는 게스트메뉴로 복귀된다. 그런데, 메일박스가 다 차지 않았으면 스텝(69046)에 있는 ARU 음성메일 루틴으로 전환하는 동안 기다려 달라는 녹음 메시지가 호출자에게 방송된다.
만약, 호출자가 팩스전송을 요구하면, ARU는 가입자의 메일박스가 다 찼는지 체크한다. 체크결과 메일박스가 다 찼으면 녹음된 메시지가 방송되며 호출자는 게스트메뉴로 복귀된다. 만약 메일박스가 다 차지 않았으면 스텝(69048)에 있는 음성/팩스 루틴으로 전환할 동안 기다려 달라는 녹음 메시지가 호출자에게 방송된다. 만약, 호출자가 가입자에게 페이지 전송을 요구하면 스텝(69050)에서 ARU는 도 69M에 기술된 ARU 페이지 전송 루틴(ARU Send Page routine)을 수행한다. 또한, 호출자가 유효한 패스코드를 입력하면 ARU는 스텝(69052)에서 도 69P에 기술된 ARU 사용자 콜 루틴(ARU User Call routine)을 수행한다.
도 69E와 도 69F에는 ARU 파인드 미 루틴의 동작이 도시되어 있다. 스텝(69060)에 도시된 바와같이, ARU 파인드 미 루틴은 호출자에 의해 설정되며, ARU가 대체조치들중의 하나를 선택하기 위해 ARU 파인드 미 루틴을 수행할 때 사용되는 단일 파라미터(Term_Slot)를 사용한다. 만약 Term_Slot이 "Find Me"로 설정되어 있으면, 이것은 ARU가 가입자의 현재 번호를 결정하는 디폴트 방법을 사용하려 한다는 것을 나타낸다. 이 값은 예를들면, 오버라이드 또는 디폴트 프로세싱을 위하여 설정될 수 있다. 만약 가입자의 프로파일이 스케줄 플래그들을 포함하고 있으면 ARU는 스텝(69062)에 도시된 바와같이 파라미터("Sched1")를 사용하는 ARU 파인드 미 루틴을 수행하고, 가입자의 프로파일이 스케줄 플래그들을 포함하고 있지 않다면, 스텝(69061)에 도시된 바와같이 가입자의 전화번호 리스트에서 첫 번째 전화번호를 사용하는 ARU 파인드 미 루틴을 수행한다.
만약, Term_Slot이 "음성메일"로 설정되어 있으면, ARU는 호출자에게 가입자가 음성 메일 메시지를 남기도록 요청했음을 알리는 메시지를 내보낸다. 만약, 가입자의 메일박스가 다 차지 않았으면 스텝(69064에)서 ARU는 도 69K에 도시된 ARU Xfer to Voice/Fax Geust Voice루틴을 수행한다. 만약, 루틴수행이 실패하면 상기 루틴은 복귀되며, 이 경우 ARU는 호출자에게 나중에 다시 호출해 달라는 메시지를 방송한 후 호출자와의 접속을 차단한다. 반면에, 가입자의 메일박스가 다 찼으면 ARU는 메일박스가 다 찼으니 나중에 나시 호출해달라는 메시지를 내보내며 호출자와의 접속을 차단한다.
만약, Term_Slot이 "페이져"로 설정되어 있으면, ARU는 호출자에게 가입자가 페이지를 남기도록 요청했음을 알리는 메시지를 내보낸 다음 도 69M에 기술된 ARU 페이지 전송루틴(Send Page routine)을 수행한다. 만약, 루틴수행이 실패하면 상기 루틴은 복귀되며, 이 경우 ARU는 호출자에게 나중에 다시 호출해달라는 메시지를 방송한 후 호출자와의 접속을 차단한다.
만약, Term_Slot이 어떤 POTS("Plain Old Telephone Service)값(Sched 1, Sched 2, 제1,제2,제3과 같은)으로 설정되어 있으면, 상기 POTS값은 입중계콜이 표준 전화 시스템을 사용하여 전송된다는 것을 가입자가 지정했음을 나타내며, ARU는 계획된 상세 내용(Particular)과 선택된 전화번호를 사용하게 된다. 스텝(69070)에서 ARU는 디지털적으로 기록된 호출자 ID를 얻기위하여 ARU 이름 기록 루틴(ARU Record Name routine)을 수행하며, 상기 ARU 이름 기록 루틴은 도 69H에 상세히 기술되어 있다. ARU는 호출자에게 적당한 메시지(예를들면, 첫 번째 시도에서 "당신측으로 접속할 동안 기다려주십시오", 다음의 시도에서는 "아직도 당신측으로 접속중이니 계속 기다려 주십시요")를 내보낸다.
스텝(69071)에서 ARU는 호출자를 기다리게 하고, 선택된 전화번호로 호출한다. 만약 상기 호출이 개인에 의해 응답이 있으면, ARU는 도 69I에서 도시된 ARU 호 접속루틴(ARU Connect Call reutine)을 수행한다. 만약, 통화중이면 스텝 (69074)에서 ARU는 도 69N의 ARU 대체루팅 루틴(ARU Alternate Routing reutine)을 수행한다. 만약, ARU가 응답장치를 감지하면, 응답장치감지시 ARU는 사용자가 다음 대체번호로 이어지도록 요구했는지 체크한다. 만약, 요구되지 않았다면 ARU는 콜을 접속하고, 요구되었으면 호출순으로 다음 번호를 선택하여, 새롭게 선택된 번호를 사용하는 ARU 파인드 미 루틴을 재차 수행한다.
그런데, 사람에 의한 응답(live answer), 통화중신호, 응답장치 응답이 없고, 그리고 Term_Slot이 "오퍼레이터로"로 설정되어 있으면, ARU는 오퍼레이터로 호출을 전환하기 위하여 도 69M에 기술된 ARU는 ARU Guest Xfer to MOTC루틴을 수행한다. 그렇지 않다면 ARU는 전화번호가 있는 경우 다음 전화번호를 선택하며, 새 번호로 ARU 파인드 미 루틴을 재차 수행한다. 만약, 체크할 번호가 더 이상 없으면, 스텝(69084)에서 ARU는 도 69N의 ARU 대체루팅 루틴을 수행한다.
도 69G에는 ARU 이름기록 루틴(ARU Record Name routine)이 도시되어 있다. 이 루틴은 가입자가 이름 또는 이름과 ANI로 콜 스크리닝(Call screening)을 지정하면 호출자의 이름을 녹음하기 위하여 사용된다. 가입자가 콜 스크리닝을 지정하면, ARU는 호출자의 이름이 이전 패스(pass)에서 녹음되었는지 체크한다. 이때, 호출자의 이름이 녹음되어 있지 않으면, ARU는 호출자에게 이름제공을 촉구하고 스텝(69090)에서 호출자로부터의 가청응답을 녹음된다. 그런데, 가입자가 콜 스크리닝의 형식(form)을 지정하지 않았다면 ARU 이름기록 루틴은 호출자의 이름을 기록하지 않고 복귀한다.
도 69H에는 ARU Guest Xfer to MOTC루틴이 도시되어 있다. 이 루틴은 호출자에게 기다려달라는 미리 녹음된 메시지를 방송한 다음 스텝(69092)에서 오퍼레이터에게 콜을 전환한다. 도 69I에는 ARU 콜 접속루틴이 도시되어 있다. 만약 호출하기 위하여 오퍼레이터의 도움이 필요하면, ARU는 도 83H의 ARU Xfer to MOTC루틴을 수행한다. 만약 가입자가 콜 스크리닝을 요청하지 않았다면 콜은 가입자에게 접속되며, 가입자가 콜 스크리닝을 선택하였다면 ARU는 호출자에게 일련의 정보메시지를 방송한다.
상기 ARU는 "전화가 왔습니다."를 내보낸 다음 가입자에 의해 선택된 옵션과 호출자의 이름이 기록되었는가에 따라 호출자 확인 메시지를 내보낸다. 만약, 이름이 기록되어 있지 않으면, 확인 메시지(69106)는 호출된 곳의 ANI만 제공한다. 만약 이름이 녹음되어 있다면, 확인 메세지는 가입자가 이름으로 스크리닝을 요구한 경우에는 스텝(69107)에서처럼 이름을 포함하고, 가입자가 이름과 ANI에 의해 스크리닝을 선택한 경우에는 스텝(69108)에서처럼 이름과 ANI를 모두 포함한다. 가입자에게 확인정보를 내보낸 후 ARU는 스텝(69110)에서 도 69J에 도시된 ARU 게인 수용(ARU Gain Acceptance)루틴을 수행한다.
도 69J에는 스텝(69110)에서 호출된 ARU 게인 수용루틴이 도시되어 있다. ARU는 가입자가 다 차지않은 사용가능한 메일박스를 가지고 있는지 체크한다. 만약, 사용가능한 메일박스를 가지고 있다면 ARU는 가입자에게 콜을 받을 것인지 또는 음성메일로 콜을 받을 것인지를 나타내도록 촉구하며, 메일박스가 다 차거나 또는 이용할 수 없으면, ARU는 가입자에게 콜을 받을 것인지 또는 호출자에게 나중에 다시 호출하도록 할 것인지를 가입자에게 촉구한다. 이때, 만약 가입자가 콜을 받을 것임을 (예를들어 "1"을 눌러) 나타내면, ARU는 스텝(69124)에서 콜을 접속하고, 그렇지 않으면 ARU는 적당한 정보메시지로 거절을 확인 응답한다(예를들면 스텝(69120)에서 결정된 메일박스의 조건에 따라, "호출자에게 음성 메일메시지를 남기도록 요청될 것입니다" 또는 "호출자에게 나중에 다시 호출하도록 요청될 것입니다"). 그리고, ARU는 가입자를 차단하고, 호출측의 보류상태를 해제한다. ARU는 가입자를 접속할수 없음을 나타내는 그리고 호출자에게 음성 메일메시지를 남기도록 촉구하는 녹음을 호출측으로 내보낸다. 만약, 메일박스가 이용될 수 없다면 호출자와의 접속은 차단되며, 메일박스가 이용될 수 있다면 스텝(69128)에서 ARU는 도 69K의 ARU Xfer to Voice/Fax Guest Voice 루틴을 수행한다. 이 루틴 다음으로 ARU는 호출자에게 나중에 다시 호출하도록 요청하는 메시지를 내보내고 접속을 차단한다.
도 69K에는 음성메일 메시지를 남기기 위해 호출자를 VFP에 접속시키는 ARU Xfer to Voice/Fax Guest Voice 루틴이 도시되어 있다. ARU는 VFP와의 핸드쉐이크(Handshake)를 시도하여, 핸드쉐이크가 성공적으로 이루어지면 스텝(69130)에서 콜을 접속한다. 만약, 핸드쉐이크가 실패하면, ARU는 스텝(69132)에서 에러메시지를 방송하고 이 루틴에서 빠져나온다. 도 69L에는 팩스를 전송하기 위하여 호출자를 VFP에 접속시키는 ARU Xfer to Voice/Fax Guest Fax w/ or w/out Annotation루틴이 도시되어 있다. ARU는 VFP와의 핸드쉐이크(Handshake)를 시도하여, 핸드쉐이크가 성공적으로 이루어지면 스텝(69140)에서 콜을 접속하고, 핸드쉐이크가 실패하면 스텝(69142)에서 에러메시지를 방송한 후 그 루틴에서 빠져나온다. 도 68K와 도 69L의 루틴들은 VFP의 요구 서비스와 호출자에게 방송될 에러메시지의 내용을 제외하고는 동일하다.
도 69M에는 가입자의 페이징 서비스로 호출을 개시하는 ARU 페이지 전송 루틴(ARU Send Page routine)이 도시되어 있다. 스텝(69150)에서 ARU는 호출자에게 지정된 페이져로 제공되어야 할 전화번호를 입력하도록 촉구한다. 이러한 시도는 콜백 번호가 수신될 때까지 3번 반복된다. 만약, 3번의 시도후에 콜백번호가 수신되지 않으면, ARU는 호출자를 오페레이터에게 이송하는 ARU Guest Xfer to MOTC루틴을 수행한다. 이것은 콜백을 입력하기 위한 DTMF-enabled 장비가 없는 호출자가, 대신 번호를 입력해 줄 수 있는 조작원에게 번호를 제공해줄 수 있도록 헤준다. 스텝(69158)에서, ARU는 호출자가 잘못 입력된 번호를 보정하거나 또는 정확한 번호가 입력되었다는 것을 확인할 수 있는 녹음을 호출자에게 방송한다. 스텝(69160)에서, ARU는 페이져에 디스플레이될 번호를 페이징 서비스로 나타내기 위하여, 호출자에 의해 재공된 데이터를 사용하는 가입자의 페이징 서비스로 호출한다. 만약 페이징서비스로의 호출이 성공적으로 이루어지면 ARU는 스텝(69164)에서 성공을 알리는 메시지를 내보내고 스텝(69166)에서 접속을 차단한다. 만약 페이징서비스로의 호출이 실패하면 스텝(69162)에서 ARU는 실패를 나타내는 메시지를 방송한 후 복귀하며, 부가적으로 ARU는 호출자에게 부가옵션들을 선택적으로 제공할 수 있다.
도 69N에는 ARU 대체 루팅(ARU Alternate Routing)루틴이 도시되어 있다. ARU는 이 루틴을 수행하여 가입자에게 루트될 수 없는 콜들을 루트한다. 만약 가입자가 그러한 루트되지 않은 콜들이 자신의 또는 호출자의 페이징 서비스로 루트될 것이라는 것을 나타내면, 스텝(69170)에서 ARU는 호출자가 페이지를 전송할 수 있다는 요지의 녹음을 방송한다. 그리고, 스텝(69172)에서 ARU는 도 69M에 기술된 페이지 전송루틴을 실행한다. 만약 페이지 전송이 실패하면 ARU는 실패를 나타내는 메시지를 방송하고, 스텝(69174)에서 호출자와의 접속을 차단한다. 만약, 가입자가 상기 루트되지 않은 콜들이 음성메일로 루트될 것이라는 것을 나타내면, 스텝(69173)에서 ARU는 호출자가 음성메일 메시지를 남길 수 있다는 요지의 녹음을 방송한다. 만약 가입자의 메일박스가 다 차지 않았다면 ARU는 ARU Xfer to Voice/Fax Guest Voice루틴을 수행한다. 이때, 만약 이 루틴이 복귀하면 음성메일을 남기기 위한 시도가 실패한 것을 의미하기 때문에, ARU는 실패를 나타내는 메시지를 방송하고 스텝(69184)에서 호출자를 차단한다. 그런데, 메일박스가 다 찼다면 ARU는 그 조건을 호출자에게 알리는 녹음을 방송하고 스텝(69184)에서 호출자를 차단한다. 만약, 가입자가 "게스트 옵션(guest option)"을 표시했다면, 스텝(69180)에서 ARU는 도 69O의 ARU 대체 루팅 게스트 옵션(Alternate Routing Guest Option)루틴을 수행하고, 그렇지 않다면 ARU는 스텝(69182)에서 호출자를 차단한다.
도 69O에는 ARU 대체 루팅 게스트 옵션(Alternate Routing Guest Option)루틴이 도시되어 있다. 이 루틴은 음성메일을 남기는 것 또는 페이지를 전송하는 것이 가입자인지 그리고 도달할 수 없는지를 게스트가 선택할 수 있도록 해준다. 스텝(69190)에서 ARU는 사용가능한 루팅 옵션들의 메뉴를 호출자에게 제공한다. 이때, 음성메일을 남기는 것은 "1", 페이지를 보내는 것은 "2"이다.
만약, 호출자가 페이지전송을 요구하면, ARU는 스텝(69200)에서 도 69M의 ARU페이지 전송(Send Page)루틴을 실행한다. 이때, 페이지전송이 실패하면 ARU는 호출자에게 진단(diagnostic)녹음을 방송하고 스텝(69202)에서 호출자를 차단한다.
그리고, 호출자가 음성메일을 남기고자 하면 ARU는 가입자의 메일박스가 다 찼는지 체크하여, 다 차지 않았으면 도 69K의 ARU Xfer to Voice/Fax Guest Voice루틴을 실행한다. 만약, 그 루틴이 복귀하면 음성메일을 남기기 위한 시도가 실패했음을 의미하기 때문에, 그 경우 또는 메일박스가 다 찬 경우 ARU는 음성메일이 전송될 수 없음을 나타내는 미리 녹음된 메시지를 방송하고, 스텝(69195)에서 호출자에게 대신 페이지를 보낼것인지를 표시하도록 촉구한다. 이때, 호출자가 페이지 전송 옵션을 선택하면, ARU는 호출자가 최초로 그 옵션을 선택했던 것처럼 스텝(69200)에서 ARU 페이지 전송루틴을 실행한다. 그리고, ARU 페이지 전송 루틴이 실패하면 ARU는 진단 메시지를 방송하고 스텝(69202)에서 호출자를 차단한다.
도 69P에는 가입자로부터의 콜을 처리하기 위한 ARU 사용자 콜(User Call)루틴의 메인 메뉴가 도시되어 있다. 이 루틴은 호출자가 유효한 패스코드를 입력하면 도 69D에 도시된 것처럼, ARU 게스트 메뉴루틴에 있는 스텝(69052)처럼 실행된다. 도입 환영 인사말이 방송한 후 ARU는 가입자의 메일박스가 다 찼는지 체크하여, 메일박스가 다 찼으면 스텝(69300)에서 가입자에게 그 조건을 통지하는 메시지를 방송한다. 이 경고를 방송한 후 또는 메일박스가 다 차지 않았으면, ARU는 스텝(69302)에서 가입자를 위해 저장된 새로운 음성메일 메시지 및 팩스 메시지의 번호를 가입자에게 통지하는 상태 녹음을 방송한다. 스텝(69304)에서, ARU는 가입자를 위하여 메뉴를 방송한다. 도시된 예에서, 항목 "1"은 콜 루팅변경 요구에 해당하고, 항목 "2"는 메일전송 또는 검색요구에 해당하고, 항목"3"은 호출요구에 해당하며, 항목 "4"는 관리(Administration)메뉴의 요구에 해당하며, 항목 "0"은 고객서비스로 전환될 요구에 해당된다.
가입자가 콜 루팅변경 옵션을 선택하면, 스텝(69310)에서 ARU는 도 69T에 기술된 ARU 루팅변경(Change Routing)루틴을 수행하고, 가입자가 메일 전송 또는 검색옵션을 선택하면 ARU는 가입자에게 대기해 달라는 미리 녹음 된 메시지를 방송한 다음 스텝(69312)에서 도 69Q에 기술된 ARU Xfer to Voice/Fax Subscriber Send/Retrieve루틴을 수행한다. 또한, 가입자가 호출 옵션을 선택하면 스텝(69314)에서 ARU는 호출하기 원하는 콜 타입을 질의하는 메뉴를 가입자에게 제공한다. 만약, 가입자가 국제 또는 국내 전화번호로 응답하거나 또는 국제 또는 국내 전화번호에 해당하는 미리 설정된 스피드 다이얼번호로 응답하면, 스텝(69316)에서 ARU는 콜을 접속한다. 만약 가입자가 오퍼레이터의 도움을 요구하면 스텝(69318)에서 ARU는 가입자를 오퍼레이터에게 전환시키기 위하여 ARU User Xfer to MOTC 루틴을 수행한다. 만약 가입자가 콜 요구를 취소하면 ARU는 스텝(69304)로 복귀한다. 스텝(69304)에서 메인 메뉴가 제공되면 ARU는 도 69P에 도시된 관리(Administration)루틴을 수행한다. 그리고, 가입자가 고객서비스를 요구하면 ARU는 도 69H에 기술된 ARU User Xfer to Customer Service루틴을 수행한다.
도 69Q에는 음성메일 메시지를 전송 및 검색을 위해 가입자를 VFP에 접속시키는 ARU Xfer to Voice/Fax Subscriber Send/Receive루틴이 도시되어 있다. 상기 ARU는 VFP와 핸드쉐이크를 시도한다. 만약 핸드쉐이크가 성공하면 ARU는 스텝(69330)에서 콜을 접속하고, 실패하면 스텝(69332)에서 에러메시지를 방송한 다음 상기 루틴에서 빠져나온다. 도 69R에는 가입자의 분류 리스트를 관리하기 위해 가입자를 VFP에 접속시키는, ARU Xfer to Voice/Fax Subscriber Send/Receive루틴이 도시되어 있다. 상기 ARU는 VFP의 핸드쉐이크를 얻으려고 한다. 만약 핸드쉐이크가 성공하면 ARU는 스텝(69340)에서 콜을 접속하고, 그렇지 않으면 스텝(69342)에서 에러메시지를 방송한 다음 상기 루틴에서 빠져나온다.
도 69S에는 VFP에서 발생된 가입자 인식 메시지에서 사용될 이름을 기록하기 위하여 가입자를 VFP에 접속시키는, ARU Xfer to Voice/Fax Subscriber Record Name루틴이 도시되어 있다. ARU는 VFP와 핸드쉐이크를 시도하여, 만약 핸드쉐이크가 성공하면 스텝(69350)에서 콜을 접속한다. 만약 핸드쉐이크가 실패하면 ARU는 스텝(69352)에서 에러메시지를 방송한 다음 상기 루틴에서 빠져나온다. 도 69Q, 도 69R 및 도 69S의 루틴들은 VFP의 요구된 서비스와 가입자에게 방송될 에러메시지의 내용을 제외하면 유사하다.
도 69T에는 가입자가 자신 또는 호출자와 관련된 루팅옵션을 수정하는 ARU 루팅변경(Change Routing) 루틴이 도시되어 있다. 스텝(69390)에서 ARU는 가입자에게 옵션의 메뉴를 제공한다. 만약, 가입자가 파인드-미 루팅을 위한 옵션을 선택하면, ARU는 도 69U에 기술된 ARU 파인드-미 루팅 변경(Change Find-Me Routing)루틴을 수행한다. 그리고, 가입자가 오버라이드 루팅(Override Routing)을 위한 옵션을 선택하면, 스텝(694400)에서 ARU는 가입자가 오버라이드 루팅을 설정했음을 나타내는 메시지를 방송하고, 스텝(69404)에서 새로운 메뉴를 선택할 수 있도록 가입자에게 메뉴를 제공한다. 만약, 가입자가 변경옵션을 선택하면, ARU는 "오버라이드"의 파라미터들과 선택된 옵션을 제공함으로써, 지정된 대로 오버라이드 옵션을 설정하기 위해 스텝(69408)처럼 ARU 프로그램 루틴을 수행한다. 만약, 가입자가 옵션 "취소(Cancel)"를 선택하면 ARU는 스텝(69390)으로 복귀한다. 만약, 스텝(69390)의 ARU 루팅 변경(Change Routing)메뉴로부터 가입자가 "대체 루팅"을 선택하면, ARU는 스텝(69409)에서 가입자가 대체루팅을 설정했음을 나타내는 메시지를 방송하고, 스텝(69410)에서 가입자에게 메뉴를 제공하여 새로운 메뉴를 선택할 수 있도록 한다, 만약, 가입자가 변경옵션을 선택하면, ARU는 "대체"의 파라미터들과 선택된 옵션을 제공함으로써, 지정된 대로 대체옵션을 설정하기 위해 스텝(69414)처럼 ARU 프로그램 루틴을 수행한다. 만약, 가입자가 옵션 "취소(Cancel)"를 선택하면 ARU는 스텝(69390)으로 복귀한다. 만약, 스텝(69390)의 루팅변경메뉴로부터 가입자가 "취소 및 복귀"를 선택하면,스텝(69412)에서 ARU는 도 69P의 사용자 메뉴로 복귀한다.
도 69U에는 ARU 파인드-미 루팅 변경(Change Find-Me Routing)루틴이 도시되어 있다. 스텝(69420)에서, ARU는 가입자의 파인드-미 루팅이 스케쥴에 의한 것인지를 체크한다. 만약, 스케줄에 의한 것이 아니면 스텝(69422)에서 ARU는 상기 루팅이 3개의 연속적인 전화번호를 시도하기 위하여 설정되었음을 알리는 메시지를 방송하고, 스텝(69424)에서 도 69V에 기술된 ARU 3-Number 시퀀스 변경(Change 3-Number Sequence)루틴을 수행한다. 만약, 가입자의 파인드-미 루팅이 스케줄에 의한 것이라면 스텝(69424)에서 ARU는 가입자의 파인드-미 루팅이 현재 스케쥴로 설정되었다는 메시지를 방송하고, 스텝(69428)에서 가입자에게 스케쥴루팅 메뉴 변경(Change Schedule Routing menu)을 제공한다. 만약 가입자가 3-Number시퀀스로 변경하기 위한 옵션을 선택하면, 스텝(69430)에서 ARU는 루팅이 3-Number 시퀀스로 설정되었다는 메시지를 방송하고, 스텝(69432)에서 도 69V의 ARU Cahnge 3-number Sequence 루틴을 수행한다. 만약 가입자가 저장 및 계속(Save and Continue)옵션을 선택하면, 스텝(69434)에서 ARU는 가입자의 파인드-미 루팅이 스케쥴에 의한 루팅으로 설정되었다는 메시지를 방송하고, 스텝(69436)에서 ARU 루팅변경(Change Routing)루틴을 수행한다. 또한, 상기 스텝(69436)과 ARU 루팅변경 루틴은 가입자가 "취소 및 복귀" 옵션을 선택한 경우에도 수행된다.
도 69V에는 도 69E 및 도69F의 ARU 파인드-미 루틴에서 사용된 세 개의 대체번호의 순서와 내용을 가입자가 바꿀 수 있도록 해주는 ARU 3-Number 시퀀스 변경(Change 3-Number Sequence)루틴이 도시되어 있다. 스텝(69440)에서, ARU는 가입자에게 옵션들의 메뉴를 제공한다. 만약 가입자가 3개의 전화번호중의 하나를 변경하기 위한 옵션을 선택하면, 스텝(69442)에서 ARU는 번호에 대한 현 세팅을 알리는 녹음된 메시지를 방송한 다음, 스텝(69444)에서 변경될 번호 및 변경될 POTS번호를 나타내는 파라미터를 상기 루틴으로 제공하여, 프로그램루틴을 실행한 다음 스텝(69440)으로 복귀한다. 만약, 가입자가 현 세팅을 리뷰(review)하기 위한 옵션을 선택하면, 스텝(69446)에서 ARU는 3개의 번호 각각에 대한 세팅을 나타내는 일련의 메시지를 방송한 다음 스텝(69440)으로 복귀한다.
만약, 가입자가 스케쥴 루팅을 변경하기 위한 옵션을 선택하면, ARU는 스텝(69450)에서 가입자가 스케쥴 루팅에 대하여 적합한지 체크하여, 적합하면 스텝(69454)에서 파이드-미 루팅이 가입자의 스케쥴에 설정되었음을 알리는 메시지를 방송하고, 스텝(69456)에서 스케쥴 루팅을 인에이블시키기 위해 스케쥴 루팅을 토글한다. 세팅을 토그한 후 스텝(69450)에서 ARU는 도 69T의 ARU 루팅변경(Change Routing)루틴으로 복귀한다. 만약 스케쥴루팅이 이 가입자를 위한 옵션이 아니면, ARU는 스케쥴루팅이 사용가능하지 않으며, 가입자는 옵션을 얻기위하여 고객서비스(Customer Service)를 접촉할 수 있음을 알리는 진단 메시지를 방송한 다음 스텝(69440)으로 복귀한다. 만약, 가입자가 취소 및 복귀옵션을 선택하면, ARU는 도 79T의 ARU 루팅변경 루틴으로 복귀한다.
도 69W에는 ARU 관리(Administration)루틴이 도시되어 있다. 스텝69460)에서, ARU는 가입자에게 옵션들의 메뉴를 제공한다. 예를들어, 항목 "1"은 가입자의 방송 또는 스피드 다이얼 리스트를 유지하기 위한 요구에 해당하고, 항목 "2"는 인사말 녹음요구에 해당하며, 항목 "3"은 부가기능을 활성 또는 비활성하기 위한 요구에 해당된다. 만약 가입자가 리스트 유지보수를 요구하면 ARU는 스텝(69462)에서 가입자에게 옵션메뉴를 제공한다. 만약 가입자가 그의 또는 호출자의 방송 리스트를 유지하기 위한 옵션을 선택하면, 스텝(69464)에서 ARU는 도 69R의 ARU Xfer to Voice/Fax Subscriber Distribution Lists루틴을 수행한다. 그 루틴을 수행한 후, 스텝(694680에서 ARU는 도 69W의 ARU 리스트(Lists) 루틴을 수행한다. 만약 가입자가 스피드 다이얼 리스트를 유지하기 위한 옵션을 선택하면 스텝(69470)에서 ARU는 도 69X의 ARU 스피드 다이얼 번호 변경(Change Speed-Dial Number)루틴을 수행한다. 만약 가입자가 취소 및 복귀를 위한 옵션을 선택하면 ARU는 스텝(69460)으로 복귀한다.
상기 스텝(69460)에서 제공된 메뉴에 응답하여, 가입자가 인사말 녹음 옵션을 선택하면, 스텝(69474)에서 ARU는 가입자에게 옵션들의 메뉴를 제공한다. 예를들어, 항목 "1"은 가입자의 환영메시지를 수정하기 위한 요구에 해당되고, 항목 "2"는 가입자의 메일박스와 관련된 이름을 수정하기 위한 요구에 해당된다. 만약 가입자가 환영 메시지 수정 옵션을 선택하면, 스텝(69476)에서 ARU는 현재의 환영 메시지를 방송하기 위하여, 도 69B의 ARU 인사말 방송(Play Greeting)루틴을 수행하며, 스텝(69478)에서 도 69Y의 ARU 인사말 변경(Change Greeting)루틴을 수행한다.
만약, 가입자가 메일박스 이름을 변경하기 위한 옵션을 선택하면, ARU는 가입자에게 대기요청 메시지를 방송하고, 스텝(69480)에서 이미 도 69S에서 기술된 ARU Xfer to Voice/Fax Subscriber Mailbox Name루틴을 수행한 후 스텝(69474)으로 복귀한다. 만약, 스텝(69474)에서 제공된 메뉴에 응답하여, 가입자가 인사말 수정요구를 취소하면(예를들어, 별표버튼을 눌러), ARU는 스텝(69460)으로 복귀한다.
만약, 가입자가 스텝(69460)에서 제공된 메뉴에 응답하여 기능 활성 또는 비활성 옵션을 선택하면, 스텝(69484)에서 ARU는 도 69Z에 기술된 ARU 부가기능 활성(Feature Activation)루틴을 수행한다. 만약, 가입자가 인사말 수정요구를 취소하면(예를들어, 별표버튼을 눌러), ARU는 도 69P의 스텝(69304)에서 기술된 ARU 사용자 메뉴(ARU User Menu)루틴으로 복귀한다.
도 69X에는 ARU 스피드 다이얼번호 변경(ARU Change Speed Dial Numbers)루틴이 도시되어 있다. 스텝(69490)에서 ARU는 가입자에게 특정한 스피드 다이얼번호에 대응되는 옵션들의 메뉴를 제공하는데, 예를들어, 항목 "1"은 제1스피드 다이얼 번호에 해당되고, 항목 "2"는 제2스피드 다이얼 번호에 해당되며, 기타 항목 "9"는 제9다이얼 스피드번호에 해당된다. 따라서, 가입자가 이들 항목들중의 하나를 선택하면, 스텝(69492)에서 ARU는 그 선택된 스피드 다이얼의 설정을 나타내는 메시지를 방송한다. 스텝(69494)에서 ARU는 프로그램될 스피드 다이얼번호를 나타내기 위하여 "Spd_Dial_n" 파라미터들을 지정하고(이때, n은 지정된 스피드 다이얼 버튼의 번호에 대응되는 디지트로 대체된다.), 지정된 스피드 다이얼 번호가 설정될 POTS번호를 구체화하는, 도 69AA에 기술된 ARU 프로그램(Program) 루틴을 수행한다. 이어서 ARU는 스텝(69490)으로 복귀한다. 만약, 가입자가 스피드 다이얼번호 변경요구를 취소하기 위한 옵션(별표로 표시된)을 선택하면, ARU는 도 69W에 기술된 스텝(69492)으로 복귀한다.
도 69Y에는 ARU 인사말 변경루틴이 도시되어 있다. 스텝(69500)에서 ARU는 가입자에게 사용가능한 옵션들에 대응하는 메뉴를 제공한다. 예를들면, 항목 "1"은 고객 인사말 녹음 요구에 해당하고, 항목 "2"는 표준 시스템 인사말의 사용요구에 해당된다. 만약, 가입자가 고객 인사말을 녹음하기 위한 옵션을 선택하면, 스텝(69502)에서 ARU는 원하는 인사말과 관련된 옵션들의 메뉴를 제공한다. 예를들어, 항목 "1"은 가입자가 입력한 고객 인사말의 현 내용을 검토하기 위한 요구에 해당되고, 항목 "2"는 현재 녹음된 고객 인사말을 녹음된 새로운 고객 인사말로 교체하기 위한 요구에 해당된다. 우물정자("#")는 인사말의 내용을 저장하기 위한 요구에 해당하고, 별표("*")는 취소 및 복귀요구에 해당된다.
만약 가입자가 자신이 입력한 고객 인사말의 내용을 검토하기 위한 옵션을 선택하면, 스텝(69504)에서 ARU는 도 69C에서 이미 기술된 ARU 임시 인사말 재생루틴(ARU Play Temp Greeting routine)을 수행하고, 스텝(69502)로 복귀한다. 만약, 가입자가 현재 녹음된 고객 인사말을 새로 기록된 고객 인사말로 대체하기 위한 옵션을 선택하면, 스텝(69504)에서 ARU는 가입자에게 새로운 인사말 녹음을 시작하도록 촉구하며, 스텝(69506)에서 새로운 인사말을 녹음한다. 인사말을 녹음한 후 ARU는 스텝(69502)로 복귀하며, 가입자는 새로 녹음된 인사말의 저장을 요구할 수 있다. 만약, 가입자가 인사말 저장을 선택하면 스텝(69510)에서 ARU는 기록된 인사말을 인사말 파일의 이전 내용에 겹쳐 기록하여 디스크에 저장하며, 스텝(69514)에서 새로운 인사말이 저장되었음을 알리는 메시지를 방송한다. 인사말 저장후 ARU는 도 69W에서 이미 기술된 ARU관리 루틴을 수행한다. 만약, 스텝(69502)에서 ARU에 의해 제공된 메뉴에 응답하여, 가입자가 인사말 수정요구를 취소하면, 스텝(69518)에서 ARU는 도 69W에서 기술된 ARU 인사말 루틴을 수행한다.
만약, 스텝(69500)에서 제공된 메뉴에 응답하여, 가입자가 시스템 인사말(예를들면 가입자를 확인할 수 없는 디폴트 인사말) 사용옵션을 선택하면, 스텝(69520)에서 ARU는 이미 기록된 인사말을 지운 후 스텝(69522)에서 호출자는 이제 개인 인사말 대신에 시스템 인사말을 듣게 될 것이라는 사전에 기록된 메시지를 방송한다. 그리고, ARU는 도 69에서 기술된 ARU 관리루틴을 수행하기 위하여 스텝(69522)으로 복귀한다. 또한, ARU는 만약 가입자가 취소 및 복귀옵션을 선택하면 스텝(69525)으로 복귀한다.
도 69Z에는 ARU 부가기능 활성(Feature Activation)루틴이 도시되어 있다. 스텝(69530)에서 ARU는 가입자에게 사용가능한 옵션들에 상당하는 메뉴를 제공한다. 예를들면, 항목 "1"은 콜 스크리닝 옵션의 설정요구에 해당하고, 항목 "2"는 페이져 수신자를 활성 또는 비활성하기 위한 요구에 해당되면, 항목 "3"은 페이져 통지를 설정하기 위한 요구에 해당하며, 옵션 "4"는 계정을 활성 또는 비활성시키기 위한 요구에 해당한다. 만약, 가입자가 콜 스크니닝을 선택하면, 스텝(69532)에서 ARU는 현재 콜 스크리닝옵션이 설정되었음을 알리는 녹음을 방송한다. 스텝(69532)에서 ARU는 가입자에게 콜 스크리닝과 관련된 옵션 리스트를 제공한다. 이 경우, 항목 "1"은 ANI(전화번호)로 스크리닝을 선택하기 위한 요구에 해당되고, 항목 "2"는 단지 이름으로 콜 스크리닝을 선택하기 위한 요구에 해당되며, 항목 "3"은 ANI와 이름으로 스크리닝을 선택하기 위한 요구에 해당하며, 항목 "4"는 콜 스크리닝 오프로 복귀하기 위한 요구에 해당된다. 만약 가입자가 상기 옵션들중의 하나를 선택하면, 스텝(69536)에서 ARU는 스크리닝 옵션의 변경을 나타내는 제1파라미터 및 설정되어야 할 옵션값을 나타내는 제2파라미터를 제공하여, 도 69AA에서 기술될 ARU프로그램 루틴을 수행한다. 다음으로 스텝(69536)에서 ARU는 스텝(69530)으로 복귀한다. 그렇지 않고, 가입자가 스텝(69534)에서 취소 및 복귀옵션을 선택하면, ARU는 스텝(69530)으로 복귀한다.
만약 가입자가 페이져를 활성 또는 비활성시키기 위한 옵션을 선택하면, 스텝(69538)에서 ARU는 페이져 통지 옵션의 새로운 상태를 나타내는 기록 메시지를 방송한다. 스텝(69540)에서, ARU는 페이져 옵션의 현재 상태를 토글한다(예를들면, 현재 옵션이 디스에이블되어 있으면 인에이블시키고, 현재 옵션이 인에이블되어 있으면 디스에이블시킨다.). 그리고, 토글 후 ARU는 스텝(69530)으로 복귀한다.
만약, 가입자가 페이져 통지 옵션을 선택하면, 스텝(69542)에서 ARU는 콜 스크리닝 옵션의 현 설정을 알리는 녹음을 방송하고, 스텝(69544)에서 페이져 통지와 관련된 옵션들의 리스트를 가입자에게 제공한다. 예를들면, 항목 "1"은 페이저로 단지 착신 음성메일의 통지를 선택하기 위한 요구에 해당되고, 항목 "2"는 페이저로 단지 착신 팩스의 통지를 선택하기 위한 요구에 해당되고, 항목 "3"은 페이저로 착신 음성메일과 착신 팩스의 통지를 선택하기 위한 요구에 해당되며, 항목 "4"는 완전히 콜 페이져 통지를 전환하기 위한 요구에 해당된다. 만약, 가입자가 이 옵션들중의 하나를 선택하면, 스텝(69546)에서 ARU는 페이져 통지옵션이 변경됨을 나타내는 제1파라미터와 설정되어야 할 옵션값을 나타내는 제2파라미터를 제공하여, 도 69AA에서 기술될 ARU프로그램 루틴을 수행한다. 다음으로 스텝(69546)에서 ARU는 스텝(69530)으로 복귀한다. 그렇지 않고, 가입자가 스텝(69544)에서 취소 및 복귀옵션을 선택하면, ARU는 스텝(69530)으로 복귀한다.
만약, 가입자가 스텝(69530)에서 자신 또는 호출자의 계정을 활성화 또는 비활성화시키기 위한 옵션을 선택하면, 스텝(69550)에서 ARU는 새로운 계정상태를 나타내는 녹음 메시지를 방송한다. 스텝(6952)에서, ARU는 계정 옵션의 현 상태를 토글한 후(현재 비활성화되어 있으면 옵션을 활성화시키고, 활성화 상태이면 비활성화시킨다) 스텝(69530)으로 복귀한다. 만약, 스텝(69530)에서 가입자가 취소 및 복귀옵션을 선택하면 ARU는 도 69W에 기술된 ARU관리 루틴으로 복귀한다.
도 69AA에는 가입자에 의해 선택된 옵션들을 설정하고 ARU에 의해 수행되는 ARU 프로그램 루틴이 도시되어 있다.
스텝(69560)에 도시된 바와같이, 상기 프로그램 루틴은 입력으로 두 개의 파라미터, 즉 값이 변경될 옵션을 지정하는 Term_Slot와, 상기 Term_Slot에 의해 지정된 옵션들의 설정값을 나타내는 Term을 갖는다. 스텝(69562)에서 ARU는 Trem에서 설정된 값의 타입을 체크하여, 만약 상기 파라미터(Term)값이 POTS 식별자(예를들어, 도 69X에 있는 스텝(69494)에서 처럼 스피드 다이얼 번호로 프로그램되어질 전화번호와 같은 전화번호)이면, 스텝(69564)에서 가입자에게 POTS번호를 입력하도록 촉구한다. 이때, 가입자가 국내 또는 국제전화번호, 또는 기 저장된 POTS값을 소거하기 위한 옵션(예를들어 "1")을 입력하면, 스텝(69566)에서 ARU는 지정된 슬롯(slot)이 변경되어질 새로운 설정을 나타내는 메시지를 방송한다. 스텝(69568)에서 ARU는 요구를 확인 또는 취소하기 위하여, 가입자에게 새로운 번호를 재입력하여 번호를 수정하도록 촉구한다. 이때, 가입자가 번호를 수정하기 위한 옵션을 선택하면 ARU는 스텝(69564)으로 복귀하고, 가입자가 요구를 확인하면, 스텝(69570)에서 ARU는 파라미터(Term_Slot)에 의해 지정된 변수로서 상기 파라미터(Term)값을 저장한다. 그리고, 가입자가 요구를 취소하면, ARU는 스텝(69572)에 있는 호출 루틴으로 복귀한다. 또한, 스텝(69564)에서 POTS번호가 촉구될 때 가입자가 취소 옵션을 선택하면 ARU는 텝(69572)에 있는 호출루틴으로 복귀한다.
만약 상기 파라미터(Term)값이 POTS식별자가 아니면, 스텝(69580)에서 ARU는 지정된 옵션이 변경될 것이라는 것을 가입자에게 알리는 메시지를 방송한다. 스텝(69582)에서 ARU는 가입자에게 요구를 확인 또는 취소하도록 촉구한다. 이때, 가입자가 요구의 확인을 선택하면 스텝(69584)에서 ARU는 파라미터(Term_Slot)에 의해 지정된 변수로서 상기 파라미터(Term)값을 저장하고, 스텝(69572)에 있는 호출 루틴으로 복귀한다. 그리고, 가입자가 요구를 취소하면, ARU는 상기 값을 저장하지 않고 스텝(69572)에 있는 호출 루틴으로 복귀한다.
도 69AI에는 ARU User Xfer to Customer Service루틴이 도시되어 있다. 스텝(69592)에서, ARU는 가입자에게 대기를 요청하는 기 녹음 된 메시지를 방송한 다음 스텝(69594)에서 가입자를 고객 소비스로 전환시킨다.
도 69AB에는 ARU 게스트 입력 확인(Validate Guest Entry)루틴이 도시되어 있다. 이 루틴은 ARU에 의해 사용되며, 게스트에 의한 VFP게스트 설비의 사용시도가 유효한지 결정하기 위한 루틴이다. ARU는 3번까지 게스트가 자신의 또는 상대편의 식별정보를 입력하도록 허용한다. 처음 두 번의 무효한 시도에 대하여, ARU는 스텝(69610)에서 게스트 입력이 무효했음을 나타내는 상태를 리턴시킨다. 세 번째 시도에 대하여, ARU는 스텝(69615)에서 도 69E와 도 69F의 ARU 파인드-미 루틴을 수행한다. 만약, 게스트입력이 수신되면, 스텝(69617)에서 ARU는 그 게스트입력이 적용가능한 메뉴에서 선택된 유효한 것중의 하나인지를 체크한다. 만약, 그렇지 않다면 스텝(69620)에서 ARU는 게스트 입력옵션이 사용될 수 없음을 나타내는 녹음 메시지를 방송한다. 만약 상기 게스트입력이 세 번째 무효한 입력이면 스텝(69624)에서 ARU는 도 69H의 ARU Guest Xfer to MTOC루틴을 수행하고, 첫 번째 또는 두 번째 무효한 입력이면 스텝(69622)에 있는 루틴으로 게스트입력이 무효했음을 나타낸 후 복귀한다. 만약, ARU가 스텝(69617)에서 게스트 입력이 적절한 메뉴 옵션이었다고 결정하면, 스텝(69626)에서 유효상태로 복귀한다.
도 69AC에는 ARU에 의해 사용되며, 가입자에 의한 VFP의 가입자 서비스의 사용시도가 유효한지 결정하기 위한 ARU 사용자 입력 확인(Validate User Entry)루틴이다. 만약, 사용자 입력이 수신되지 않으면, 스텝(69630)에서 ARU는 입력이 수신되지 않았다는 진단 메시지를 방송하고, 입력이 수신되면 ARU는 스텝(69634)에서 가입자가 응답할 메뉴가 사용자 입력에 대한 옵션을 포함하고 있는지 체크한다. 만약, 그렇다면 ARU는 스텝(69636)에 있는 유효상태로 복귀하고, 그렇지 않다면 스텝(69638)에서 ARU는 옵션이 사용될 수 없음을 나타내는 진단 메시지를 방송한다. 만약, 입력이 수신되지 않거나 또는 입력이 메뉴에 유효하지 않으면, ARU는 스텝(69632)에서 이것이 가입자 정보를 지정하기 위한 세 번째 실패인지 체크한다. 만약, 세 번째 실패이면, ARU는 스텝(69640)에서 도 89AI의 ARU User Xfer to Customer Service루틴을 수행하고, 첫 번째 또는 두 번째 실패한 입력이면 스텝(69642)에 있는 무효상태로 복귀한다.
도 69AD에는 ARU에 의해 사용되며, 가입자에 의해 입력된 패스코드를 입증하기 위한 ARU 패스코드 입력 확인(Validate Passcode Entry)루틴이 도시되어 있다. 스텝(69650)에서, ARU는 입력된 패스코드가 특정 가입자의 패스코드와 일치하는지 체크하여, 일치하면 스텝(69652)에서 ARU는 유효상태로 복귀한다. 그런데, 입력이 유효하지 않으면, 스텝(69654)에서 ARU는 입력이 유효하지 않다는 녹음 메시지를 방송한다. ARU는 2번의 시도로 유효한 패스코드를 나타낸다. 스텝(69656)에서, ARU는 그 시도가 패스코드를 입력하기 위한 두 번째 시도인지 체크한다. 이때, 만약 두 번째 시도이면, 스텝(69660)에서 ARU는 도 69AI에서 기술된 ARU User Xfer to Customer Service루틴을 수행하고, 두 번째 시도가 이니면 스텝(69658)에서 가입자에게 유효한 패스코드를 입력하도록 촉구한 후 스텝(69650)으로 복귀한다.
도 69AE에는 ARU에 의해 사용되며, 유효한 전화번호 입력을 확인하기 위한 ARU 완료 확인(Validate Completion) 루틴이 도시되어 있다. 스텝(69670)에서 ARU는 유효한 사용자 입력이 수신되었는지 체크하여, 유효한 사용자 입력이 수신되지 않았으면 이것이 시도된 세 번째 무효입력인지 체크한다. 이때, 만약, 세 번째 무효입력이 아니면, 스텝(69672)에서 ARU는 유효한 입력이 수신되지 않았음을 표시기에 보낸다. 그런데, 세 번째 무효입력이면 스텝(69674)에서 ARU는 메시지를 방송하고 스텝(69676)에서 도 69H에서 기술된 ARU Xfer User to MTOC루틴을 수행한다.
만약, 유효한 사용자 입력이 수신되면, ARU는 입력된 전화번호가 "011"로 시작되는지 체크한다. 만약, 그렇다면, 스텝(69680)에서 ARU는 도 69AF의 국제 전화번호 완료확인(Validate International Completion) 루틴을 수행한다. 스텝(69682)에서 ARU는 국내 term플래그가 가입자에 의해 설정되어 있는지 체크하여, 설정되지 않았으면 스텝(69684)에서 ARU는 국내 콜은 사용될 수 없음을 나타내는 메시지를 방송하고 스텝(69671)으로 진행한다. 스텝(69686)에서, ARU는 10-디지트번호가 입력되었는지 체크하고, 스텝(69688)에서 유효한 MPA-Nxx번호가 입력되었는지 체크한다. 만약, 입력된 번호가 10-디지트 유효 MPA-Nxx번호가 아니면, 스텝(69690)에서 ARU는 진단 메시지를 방송하고 스텝(69671)로 진행한다. 스텝(69690)에서 ARU는 NADP블로킹이 이 가입자에게 유효한지 체크하고, 스텝(69692)에서 976블로킹이 이 가입자에게 유효한지 체크한다. 만약 모든 브로킹이 유효하다면, 스텝(69694)에서 ARU는 지정된 번호에 대한 콜들이 차단되었음을 나타내는 진단메시지를 방송하고 스텝(69671)로 진행하고, 모든 블로킹이 유효하지 않으면 스텝(69696)에서 ARU는 입력된 번호가 유효하다는 상태를 보낸다.
도 69AF는 상기 ARU의 국제 완료 확인 절차(ARU Validate International Completion routine)를 도시한 것이다. 스텝 69700에서, ARU는 가입자가 국제 통화 배치가 형성되어 있는지 그렇지 않은지를 판단하여, 만약 그렇지 않다면 이를 나타내는 메시지를 발생시킨다(스텝 69702). 그리고, 상기 ARU는 입력된 번호가 국제 다이얼링 번호로서 유효한지를 확인한다(스텝 69704). 스텝 69708에서, ARU는 씨셋 블로킹(Cset Blocking)이 특정 번호를 차단할 것인지 판단하여, 만약 그렇다면 이를 나타내는 메시지를 발생시킨다(스텝 69710). 만약 아무런 에러 조건이 발견되지 않았다면, 상기 ARU는 유효 상태로 돌아간다(스텝 69712). 만약 에러가 발견되었을 경우 상기 ARU는 무효 상태로 전환된다(스텝 69713). 만약 번호를 입력하기 위한 세 번째의 시도가 실패하였다면, ARU는 상태 메시지를 발생시키고(스텝 69714), 상기 가입자를 오페레이터에게 전송한다(스텝 69716).
도 69AG는 ARU의 POTS 프로그래밍 확인 절차(ARU Validate POTS Programming routine)를 도시한 것으로, 이는 유일한 하나의 유효 전화번호가 호 경로지정(call routing)에 의한 사용을 위해 저장되었는지를 확인하는 ARU에 의해 사용된다. 스텝 69720에서, ARU는 유효 사용자 엔트리가 수신되었는지를 체크하여, 만약 그렇지 않았다면 상기 ARU는 이것이 세 번째의 무효 엔트리 입력이었는지를 판단한다. 만약, 세 번째가 아니라면, 상기 ARU는 유효 엔트리를 수신 받지 못했음을 지시하고(스텝 69722), 한편 이것이 세 번째 시도였다면, 상술한 도 69AI와 같은 ARU의 사용자 고객서비스 전환 절차(ARU User Xfer to customer Service routine)를 수행한다(스텝 69676).
만일 유효 가입자 엔트리를 수신받았다면, ARU는 입력된 전화번호가 "011"로 시작되었는지를 판단하여, 만약 그렇다면 상기 도 69AF의 ARU의 국제 완료 확인 절차(Validate International Completion routine)를 수행한다(스텝 69730). 스텝 69732에서, 상기 ARU는 가입자에 의해 국내 텀 플래그(domestic terms flag)가 설정되었는지를 확인하여, 만약 그렇지 않다면 국내 통화를 이용할 수 없음을 나타내는 메시지를 발생하고(스텝 69734), 스텝 69721로 진행한다. 스텝 69736에서, ARU는 10자리수의 번호가 입력되었는지를 확인하고, 스텝 69738에서 유효한 MPA-Nxx 번호가 입력되었는지를 확인하여, 만일 둘 다 입력되지 않은 경우 상기 ARU는 이를 나타내는 메시지를 발생시키고(스텝 69740), 스텝 69721로 진행한다. 스텝 69750에서, ARU는 976 블로킹이 상기 가입자에게 효과가 있는지를 판단하여, 만약 그렇다면 상기 지정된 번호에 대한 통화가 차단되었음을 나타내는 메시지를 발생시키고(스텝 69754), 스텝 69721로 진행한다. 그렇지 않다면, 상기 ARU는 입력된 번호가 유효한 상태로 돌아간다(스텝 69756).
도 69AH는 ARU의 국제 프로그래밍 확인 절차(ARU Validate International Programming routine)를 도시한 것으로, 이는 호 경로지정에 의한 사용을 위해 하나의 유효 전화번호가 저장되었는지를 확인하는 ARU에 의해 사용된다. 스텝 69760에서, ARU는 가입자가 국제 통화 배치가 형성되어 있는지를 판단하여, 만약 그렇지 않다면 이를 나타내는 메시지를 발생시킨다(스텝 69762). 스텝 69764에서, ARU는 입력된 번호가 국제 다이얼링 번호로서 유효한 것인지를 판단하여, 만약 그렇지 않다면 상기 ARU는 스텝 69766에서 이를 나타내는 메시지를 발생시킨다. 스텝 69768에서, 상기 ARU는 씨셋 블로킹(Cset blocking)이 특정 번호를 차단할 것인지를 판단하여, 만약 그렇다면 상기 ARU는 스텝 69770에서 이를 나타내는 메시지를 발생시킨다. 만약 아무런 에러 조건이 발견되지 않았다면 상기 ARU는 유효 상태로 돌아가고(스텝 69772), 에러가 발견되었다면 무효 상태로 돌아간다(스텝 69773). 만약 번호를 입력하기 위한 세 번의 시도가 실패하였다면, 상기 ARU는 상태 메시지를 발생시키고(스텝 69774), 상기 가입자를 오페레이터에게 전송한다(스텝 69776).
도면 70A 내지 70S는 상술한 직통선 MCI 제품을 구현한 소프트웨어를 보여주는 자동 콘솔 통화의 흐름도를 도시한 것으로, 본 발명을 보다 더 잘 이해하는데 유용하다. 콘솔 통화 순서는 ARU 통화 순서와는 다르다. 즉, 상기 콘솔 통화는, 자동화에 반하여, 호출자에 의한 요청에 대하여 응답할 한 개인에 의하여 작동된다. 이는 상기 제품을 이용하기 위한 DTMF 가용 장비없이 발신자를 허가한다. 상기 발신자에 의해 제공된 DTMF 데이터는 처리되어질 것이고, 교환원(human operator)의 유용성은 DTMF 입력의 사용없이 수행되어지는 많은 유용한 동작을 허가한다. 데이터는 발신자가 키패드에 직접 입력하거나, 또는 상기 발신자에 의해 제공된 음성 응답에 대응하여 교환원에 의해 입력되어질 수도 있다.
도 70A는 자동 콘솔 통화가 요금 계산(account)으로 진행되기 위한 시작점을 도시한 것이다. 통화가 시작되면서 이것은 게스트 통화로 간주된다. 만약 요금 계산이 현재 온라인이 아닌 경우, 자동 콘솔은 상기 통화가 요금 계산으로 받아들여질 수 없음을 나타내는 메시지를 발생시킨다(스텝 70010). 만약, 발신자가 오페레이터에게 그가 패스코드를 가지고 있음을 나타내지 않는다면, 상기 콘솔은 통화를 끊는다(스텝 70012). 만약 상기 발신자가 오퍼레이터에게 패스코드를 제공한다면, 상기 오퍼레이터는 콘솔의 패스코드 확인 절차(Console Validate Passcode routine) 절차를 시작하는데,(스텝 70014) 이것은 도 70K와 관련하여 아래에서 설명된다.
만약 요금계산이 현재 온라인 상태라면, 콘솔은 상기 가입자가 착신 통화(incoming call)에 대하여 오버라이드(override)를 지시하였는지는지 확인하여, 만약 그렇다면 상기 콘솔은 통화를 오퍼레이터로 전송한다(스텝 70018). 만약 발신자가 팩스 톤을 발생시키고 있다면, 상기 콘솔은 콘솔의 팩스 톤 탐지 절차(Console Fax Tone Detected routine)를 수행하는데(스텝 70024), 이는 도 70S와 관련하여 아래에서 설명되어진다. 만약 발신자가 오퍼레이터에게 패스코드를 제공하였다면, 상기 오퍼레이터는 콘솔의 패스코드 확인 절차(Console Validate Passcode routine)를 시작하는데(스텝 70026), 이는 도 70K와 관련하여 아래에서 설명되어질 것이다. 그렇지 않다면, 상기 통화는 가입자에 대해 착신 통화로서 처리되고, 콘솔은 가입자 찾기 절차(Console Find Me routine)를 수행하는데(스텝 70020), 이것은 도 70BC와 관련하여 아래에서 설명된다. 상기 콘솔은 가입자 찾기 절차(Console Find Me routine)에 대해 "오버라이드" 변수를 제공한다.
만약 특정 오버라이드가 설정되지 않았다면, 콘솔은 발신자가 들을 수 있는 메뉴를 제공한다(스텝 70030). 예를 들어, 항목 '1'은 가입자에게 말하기를 요청하는 것과 관련된 것이고, 항목 '2'는 가입자에게 음성 메일 메시지를 남기기를 요청하는 것과 관련되며, 항목 '3'은 가입자에게 팩스 보내기를 요청하는 것과 관련된 것이고, 항목 '4'는 가입자 호출 요청과 관련된 것이다. 추가로, 가입자는 가입자로서 콘솔에 액세스 하기 위한 자신의 패스코드를 제공할 것이다.
만약, 발신자가 가입자에게 말하기를 요청하면, 콘솔은 상기 발신자의 프로파일(profile)과 관련된 스케쥴 플래그(schedule flags)를 확인한다(스텝 70032). 만약 상기 가입자의 프로파일 스케쥴을 지시하면, 상기 콘솔은 "Sched1"을 변수로 사용하는, 도 70B 및 도 70C의 콘솔의 가입자 찾기 절차(Console Find Me routine)를 수행한다(스텝 69034). 만약, 가입자의 프로파일이 스케쥴을 지시하지 않는다면, 상기 콘솔은 "First"를 변수로 사용하는 콘솔의 가입자 찾기 절차(Console Find Me routine)를 수행한다(스텝 69036). 상기 콘솔의 가입자 찾기 절차(Console Find Me routine)는 도 70B 및 도 70C와 관련하여 아래에서 보다 상세히 설명될 것이다.
만약, 상기 발신자가 음성 메일 메시지 남기기를 요구하면, 상기 콘솔은 콘솔의 음성/팩스 게스트 전환 절차(Console Xfer to Voice/Fax Guest routine)를 수행하는데(스텝 70040), 이것은 도 70E와 관련하여 아래에서 설명되어진다. 만약 발신자가 팩스 전송을 요구하면, 콘솔은 주석 유/무 음성/팩스 게스트 전환 절차(Console Xfer to Voice/Fax Guest w/ or w/out Annotation routine)를 수행하는데(스텝 70042), 이것은 도 70F와 관련하여 아래에서 설명된다. 상기 절차를 수행한 후, 상기 콘솔은 게스트 메뉴로 돌아간다(스텝 70030). 만약 발신자가 음성 메일 메시지를 남기기를 요구하면, 상기 콘솔은 페이지 전송 절차(Console Send Page routine)를 수행하는데(스텝 70040), 이것은 도 70G와 관련하여 아래에서 설명할 것이다. 상기의 스텝 70040, 70042 또는 70044 절차 중 어느 하나라도 수행한 후, 상기 콘솔은 게스트 메뉴로 돌아간다(스텝 70030).
만약 발신자가 패스코드를 제공하면, 상기 콘솔은 패스코드 확인 절차(Console Validate Passcode routine)를 수행하는데(스텝 70046), 이것은 도 70K와 관련하여 아래에서 설명된다. 만약 콘솔이 착신 통화에서 팩스 톤을 탐지하면, 상기 콘솔은 팩스 톤 탐지 절차(Console Fax Tone Detected routine)를 수행하는데(스텝 70048), 이것은 도 70S와 관련하여 아래에서 설명되어진다.
도 70B 및 도 70C는 상기 콘솔의 가입자 찾기 절차(Console Find Me routine)의 동작을 나타낸다. 스텝 70060에서 보여지는 바와 같이, 상기 콘솔의 가입자 찾기 절차(Console Find Me routine)는 하나의 변수 Term_Slot을 가지는데, 이것은 발신자에 의해 설정되고 여러 대안적인 동작 과정 중 하나를 선택하는 콘솔에 의해 사용된다. 만약, Term_Slot이 "Find Me"로 설정되면, 이것은 상기 콘솔이 가입자의 현재 번호를 결정하는 데 기본적으로 설정된 방법을(default method) 사용하는 것을 나타낸다. 이 값은, 예를 들어, 오버라이드 또는 기본 설정 과정(default processing)으로 설정될 것이다. 만약, 상기 가입자 프로파일이 스케쥴 플래그를 포함한다면, 상기 콘솔은, 스텝 70062과 같이 'Sched1'을 변수를 사용하는 콘솔의 가입자 찾기 절차(Console Find Me routine)를 수행하고, 만약 그렇지 않다면, 상기 콘솔은, 스텝 70061에서 보여지는 바와 같이, 가입자에 대한 번호 리스트에서 첫 번째 전화번호를 사용하여 가입자 찾기 절차(Find Me routine)를 수행한다.
만약 Term_Slot이 "음성메일"로 설정되면, 상기 콘솔은 발신자가 음성 메일 메시지를 남기도록 가입자가 요청하였음을 알리는 메시지를 상기 발신자에게 보내고, 도 70E에 도시된 바와 같이, 콘솔의 음성/팩스 게스트 전환 절차(Console Xfer to Voice/Fax Guest routine)를 수행한다(스텝 70074). 만약 상기 절차가 실패하면, 발신자에게 나중에 통화를 시도하도록 하는 메시지를 발생시키는 과정으로 돌아가고, 상기 발신자와의 연결을 끊는다(스텝 70075).
만약, Term_Slot이 "호출기"로 설정되면, 콘솔은 발신자가 호출 요청을 남기기를 요청하였음을 가입자가 요구하였음을 나타내는 메시지를 상기 발신자에게 보낸다. 그리고 나서, 상기 콘솔은 페이지 전송 절차(Console Send Page routine)를 수행하는데, 이것은 도 70G와 관련하여 아래에서 설명된다. 만약 실패하면, 상기 절차는 발신자에게 나중에 통화를 시도하도록 하는 메시지를 발생시키는 과정으로 돌아가고, 상기 발신자와의 연결을 끊는다(스텝 70066).
만약 Term_Slot이 가입자가 착신 통화들을 표준 전화 시스템을 이용하여 전송하도록 설정하였음을 나타내는 어떤 POTS 값(Sched1, Sched2, First, Second, 또는 Third 등과 같은)으로 설정되면, 콘솔은 특별히 계획되었거나 선택된 전화번호를 사용하도록 명령할 것이다. 스텝 70070에서, 콘솔은 발신자의 신원을 나타내는 디지털 기록을 얻기 위한 이름 기록 절차(Console Record Name routine)를 수행한다. 상기 이름 기록 절차(Console Record Name routine)는 도 70H와 관련하여 아래에 보다 상세히 설명된다. 상기 콘솔은 스텝 70073 및 70075에서 발신자를 위해 적절한 메시지(즉, 첫 번째 시도때 "내가 당신쪽으로 도달할 때까지 기다려라" 그리고 다음 시도에 대해 "나는 여전히 당신쪽에 도달하기 위해 시도중이다; 계속 기다려 달라")를 발생시킨다.
만약 발신자가 개인으로부터 응답을 받는다면, 콘솔은 상기 발신자를 연결하기 위한 통화 연결 절차(Console Connect Call routine)를 수행하는데(스텝 70072), 이는 도 70D와 관련하여 아래에서 설명된다. 만약 상기 발신자가 자동응답기로부터 응답을 받는다면, 상기 콘솔은 자동응답기에 연결되면 그 다음의 다른 번호로 넘어가도록 가입자가 요청했었는지를 확인하여(스텝 70090), 만약 그렇지 않다면 상기 콘솔은 통화를 연결한다(스텝 70094). 만약 가입자가 다른 전화 번호로 넘어가도록 선택하였다면, 상기 콘솔은 교대로 그 다음의 번호로 통화하도록 선택하고, 스텝 70081, 70082 및 70083에 보여지는 바와 같이, 최근 선택된 번호를 사용하여 콘솔의 가입자 찾기 절차(Console Find Me routine)를 다시 수행한다.
만약, 통화 회선이 통화중이거나, 확인한 번호가 더 이상 존재하지 않으면, 콘솔은 도 70I에 도시된 콘솔의 대안 경로 지정 절차(Console Alternate Routing routine)를 수행한다(스텝 70074).
도 70D는 콘솔의 통화 연결 절차(Console Connect Call routine)를 나타낸다. 만약 가입자가 통화 차단을 요청하지 않았다면, 콘솔은 상기 가입자에게 통화를 연결한다(스텝 70100). 만약, 가입자가 통화 차단을 요청하였다면, 콘솔은 필요하다면 이름 또는 ANI에 의해 발신자를 확인할 수 있는 정보 메시지를 가입자에게 보낸다(스텝 70104). 만약, 상기 가입자가 전화 받는 것을 선택한다면, 콘솔은 발신자의 대기를 해제하고(스텝 70106), 통화가 연결되었음을 알리는 메시지를 발생시키고(스텝 70108), 통화 연결을 수행한다(스텝 70110). 만약, 가입자가 전화 받기를 거절하면, 콘솔은 발신자의 대기를 해제하고(스텝 70114), 발신측으로 상기 가입자에게 도달하지 못했음을 알리고, 발신자가 선택적으로 음성 메일 메시지를 남길 것인지를 묻는 메시지를 발생시킨다(스텝 70118서). 만약, 사용할 수 있는 메일박스가 없으면, 상기 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70119), 발신자와의 연결을 끊는다(스텝 70120). 만약, 유효한 메일박스가 있고 메시지를 수신할 수 있으면, 상기 콘솔은 도 70E에 도시된 콘솔의 음성/팩스 게스트 음성 전환 절차(Console Xfer to Voice/Fax Guest Voice routine)를 수행한다(스텝 70128). 상기 절차가 수행된 후, 콘솔은 발신자에게 나중에 다시 통화하기를 요청하는 메시지를 발생시키고(스텝 70119) 연결을 끊는다(스텝 70120).
도 70S 콘솔의 팩스 톤 탐지 절차(Console Fax Tone Detected routine)를 나타낸 것이다. 스텝 70130에서, 콘솔은 VFP와 핸드셰이킹 하기 위해 시도한다. 만약 상기 핸드셰이킹이 성공하면, 콘솔은 스텝 70132에서 통화를 연결하고, 만약 성공하지 못한다면, 스텝 69132에서 상기 발신자의 연결을 끊고 나간다.
도 70E는 콘솔의 음성/팩스 게스트 음성 전환 절차(Console Xfer to Voice/Fax Guest Voice routine)를 도시한 것으로, 이는 발신자를 음성 메일 메시지를 남기도록 하는 VFP로 연결한다. 상기 콘솔은 스텝 70140에서 상태 메시지를 발생시키고, 스텝 70142에서 가입자의 메일박스가 가득 찼는지를 점검한다. 만약 상기 메일박스가 가득 찬 경우, 콘솔은 이를 나타내는 메시지를 발생시킨 후(스텝 70144) 리턴하고, 만약 메일박스가 가득 차지 않았다면, 콘솔은 VFP와 핸드셰이킹 하도록 시도한다. 만약 상기 핸드셰이킹이 성공하면, 콘솔은 상기 통화를 연결하고(스텝 70146), 성공하지 못하면, 에러 메시지를 발생시키고(스텝 70148) 리턴한다.
도 70F는 콘솔의 주석 유/무 음성/팩스 게스트 팩스 전환 절차(Console Xfer to Voice/Fax Guest Fax w/ or w/out Annotation routine)를 도시한 것으로, 이는 발신자를 팩스를 전송하기 위한 VFP로 연결하는 것이다. 상기 콘솔은 스텝 70150에서 상태 메시지를 발생시키고, 스텝 70152에서 가입자의 메일박스가 가득 찼는지를 점검한다. 만약 상기 메일박스가 가득 찼다면, 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70154), 만약 메일박스가 차지 않았다면, VFP와 핸드셰이킹을 시도한다. 만일 상기 핸드셰이킹이 성공하면, 콘솔은 통화를 연결하고(스텝 70156), 만약 상기 핸드셰이킹이 성공하지 못하면, 에러 메시지를 발생시키고(스텝 70148) 리턴한다. 도 70E와 70F에 도시된 절차는 VFP에게 요구되는 서비스와 발신자에게 전송되는 에러 메시지의 내용을 제외하면 거의 유사하다.
도 70G는 콘솔의 페이지 전송 절차(Console Send Page routine)를 도시한 것으로, 이는 가입자의 호출 서비스로 통화를 시작한다. 스텝 70160에서, 콘솔은 발신자에게 지정한 호출기로 전송할 전화번호를 남기도록 한다. 스텝 70162에서, 콘솔은 호출이 전송될 동안 기다려 달라고 요구하는 상태 기록을 발신자에게 전송한다. 만약 호출이 성공적으로 전송되면, 콘솔은 상기 호출이 전송되었음을 나타내는 상태 메시지를 발생하고, 스텝 70165에서 통화를 끊는다. 만약 호출 서비스에 대한 통화가 성공하지 못하면, 콘솔은 스텝 70166에서 실패했음을 알리고, 발신자에게 부가 선택을 제공하도록 하고 리턴한다.
도 70H는 콘솔의 이름 기록 절차(Console Record Name routine)를 도시한 것이다. 상기 절차는 가입자가 이름 또는 이름 및 ANI에 의해 특정 통화의 차단을 설정해 놓았을 경우, 상기 발신자의 이름을 기록하는 것에 사용된다. 만약 가입자가 이름 또는 이름 및 ANI에 의한 특정 통화 차단을 설정하였다면, 콘솔은 스텝 70170에서 발신자에게 이름을 입력하도록 하고, 청취할 수 있는 응답을 기록한다. 만약, 팩스 톤이 상기 기록 과정 중에 탐지되면, 콘솔은 스텝 70172에서 팩스 톤 탐지 절차(Console Fax Tone Detected routine)를 수행하고, 그렇지 않으면 상기의 절차는 리턴한다.
도 70I는 콘솔의 대안 경로지정 절차(Console Alternate Routing routine)를 도시한 것이다. 콘솔은 가입자 경로를 찾을 수 없는 호들의 경로지정을 위하여 상기 절차를 수행한다. 만약, 가입자가 경로를 찾지 못한 호들에 대해 호출 서비스로 경로를 지정하도록 설정하였다면, 콘솔은 발신자가 호출(page)을 전송할 것임을 나타내는 메시지를 발생시킨다(스텝 70180). 만약, 발신자가 페이지를 전송하기로 결정하면, 콘솔은, 상기 70G와 관련하여 설명된, 페이지 전송 절차(Console Send Page routine)를 수행한다(스텝 70182). 만약, 호출이 성공하지 못했다면, 콘솔은 이를 나타내는 메시지는 발생시키고(스텝 70185), 상기 발신자와의 연결을 끊는다(스텝 70184). 만약, 가입자가 상기 경로를 찾지 못한 호들에 대해 음성메일로 경로 지정을 하도록 하였다면, 콘솔은 상기 발신자가 음성 메일 메시지를 남길 것임을 알리는 메시지를 발생시킨다(스텝 70183). 만약, 상기 발신자가 음성메일을 남기기로 결정하면, 콘솔은, 상기 도 70E와 관련하여 설명된, 콘솔의 음성/팩tm 게스트 음성 전환 절차(Console Xfer to Voice/Fax Guest Voice routine)를 수행한다(스텝 70186). 만약, 상기 음성메일이 실패하였다면, 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70185), 상기 발신자와의 연결을 끊는다(스텝 70184).
만약, 가입자가 "게스트 선택(guest option)"을 지시하였다면, 콘솔은 도 70J의 대게스트 선택 대안 경로지정 절차(Console Alternate Routing Guest Option)를 수행한다(스텝 69190). 그렇지 않으면, 상기 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 69192), 상기 발신자와의 연결을 끊는다(스텝 69194).
도 70J는 콘솔의 게스트 선택 대안 경로지정 절차(Console Alternate Routing Guest Option routine)를 도시한 것이다. 이 절차는 게스트가 가입자에게 도달할 수 없는 경우에, 음성 메시지를 남길 것인지, 또는 호출을 보낼 것인지를 선택하도록 허가한다. 콘솔은 발신자에게 유효한 경로지정 선택사항을 제공하는데(스텝 70200), 이는 음성 메시지를 남기거나 또는 호출을 보내는 것 중의 하나이다. 만약, 상기 발신자가 음성메일을 보내기를 요청한다면, 콘솔은 도 70E에 도시된 음성/팩스 게스트 음성 전환 절차(Console Xfer to Voice/Fax Guest Voice routine)를 수행한다(스텝 70202). 만약, 상기 절차가 실패하였음을 나타내는 리턴 코드로 돌아가면, 콘솔은 상기 음성메일을 전송하지 못했음을 나타내는 미리 녹음된 메시지를 보내고, 상기 발신자에게 대신에 호출을 전송할 것인지를 묻는다(스텝 70204). 만약, 상기 발신자가 스텝 70200 또는 스텝 70204에 대한 응답으로 호출 전송을 요구한다면, 콘솔은 도 70G에 도시된 콘솔의 페이지 전송 절차(Console Send Page routine)를 수행한다(스텝 70206). 만약, 상기 페이지 전송 절차(Console Send Page routine)가 리턴하거나(호출이 전송되지 못 했음을 나타냄) 또는 발신자가 상기 스텝 70204에 대한 응답으로 호출 전송을 거절한다면, 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70208), 상기 발신자와의 연결을 끊는다(스텝 70209).
도 70K는 콘솔의 패스코드 엔트리 확인 절차(Console Validate Passcode Entry) 절차를 도시한 것으로서, 이는 콘솔이 가입자에 의해 제공된 패스코드를 확인하는데 이용된다. 스텝 70220에서, 상기 발신자는 패스코드를 묻는다. 그리고 스텝 70224에서, 콘솔은 입력된 패스코드가 특정 가입자에 대한 패스코드와 일치하는지를 확인하여, 만일 그렇다면 콘솔은 사용자 통화 절차(Console User Call routine)를 수행하는데(스텝 70226), 이것은 도 70L과 관련하여 아래에서 설명된다. 콘솔은 유효 패스코드를 설정하기 위한 두 번의 시도를 허가한다. 그리고, 콘솔은 패스코드를 제공하는 두 번째 시도가 실패하는지를 확인하여, 만약 두 번째 시도까지 실패한다면, 상기 콘솔은 발신자에게 상기 패스코드가 유효하지 않음을 알려주고(스텝 70232), 상기 발신자가 고객 서비스(customer sevice)로 연결되도록 제안한다. 만약, 상기 발신자가 고객 서비스에 연결되는 것을 선택하지 않는다면, 상기 발신자와의 연결을 끊는다(스텝 70234). 만약, 이것이 첫 번째 시도였다면, 콘솔은 가입자에게 유효 패스코드를 입력하도록 하고(스텝 70230), 스텝 70224로 리턴한다.
도 70L은 콘솔의 가입자 통화 절차(Console user Call routine)를 도시한 것이다. 스텝 70240에서, 콘솔은 가입자의 메일박스가 가득 찼는지를 점검하여, 만약 가득 찼다면 가입자에게 경고 메시지를 발생시킨다(스텝 70242). 상기 메일박스가 가득 찼는지의 여부에 관계없이, 콘솔은 메일박스에 있는 음성메일 메시지와 팩스의 수를 가입자에게 알리는 상태 메시지를 상기 가입자에게 보낸다(스텝 70244). 스텝 70246에서, 콘솔은 가입자에게 선택 항목들을 제공한다. 예를 들어, 항목 '1'은 메일을 전송하거나 검색하기를 요구하는 것과 관련된 것이고, '2'는 통화를 배치하도록 요구하는 것과 관련된 것이며, '3'은 퇴장을 요구하는 것과 관련된 것이다. 만약, 가입자가 메일을 전송하거나 검색하는 항목을 선택한 경우, 콘솔은 대기 메시지를 발생시키고(스텝 70248), 도 70M의 음성/팩스 가입자 전송/검색 전환 절차(Console Xfer to Voice/Fax Subscriber Send/Retrieve routine)를 수행한다. 상기 절차가 완료된 후, 콘솔은 스텝 70246으로 리턴한다. 만약 가입자가 통화 배치 항목을 선택하면, 콘솔은 외부 통화 절차(Console Outbound Calling routine)를 수행하는데, 이는 도 70N과 관련하여 아래에서 설명된다. 만약 가입자가 퇴장 프로그래밍(Exit Programming) 항목을 선택한다면, 콘솔은 상기 통화를 끊는다.
도 70M은 콘솔의 음성/팩스 가입자 전송/검색 전환 절차(Console Xfer to Voice/Fax Subscriber Send/Receive routine)를 도시한 것으로, 이는 가입자를 음성메일 메시지를 보내거나 검색하는 VFP로 연결한다. 콘솔은 VFP와의 핸드셰이킹을 시도하여, 만약 상기 핸드셰이킹이 성공적으로 이루어지면, 콘솔은 상기 통화를 연결한다(스텝 70250). 만약 성공하지 못한다면, 콘솔은 에러 메시지를 발생시키고(70252), 퇴장한다.
도 70N은 콘솔의 외부 통화 절차(Console Outbound Calling routine)를 도시한 것으로, 이는 가입자가 출중계 통화(outgoing call)를 배치하는 것에 의한 절차이다. 스텝 70260에서, 콘솔은 가입자가 국제 통화를 배치하는 것이 설정되었는지를 확인하여, 만약 그렇다면 콘솔은 비국내 통화를 가능하게 하는 국제 통화 키를 가능하게 한다(스텝 70262). 스텝 70264에서, 가입자에게 전화번호를 입력하도록 한다. 그리고, 콘솔은 상기 가입자를 상기 출중계 통화와 연결한다(스텝 70268).
도 70O는 콘솔의 게스트 엔트리 확인 절차(Console Valodate Guest Entry routine)를 도시한 것이다. 상기 절차는 VFP 게스트 시설을 이용하는 게스트에 의한 시도가 가능한지를 콘솔이 판단하는 것에 의한 절차이다. 콘솔은 게스트 엔트리가 적용 가능한 메뉴에서 가능한 선택 중 하나였는지를 판단하여(스텝 70270), 만약 그렇지 않다면, 스텝 70272에 도시된 바와 같이, 상기 엔트리는 받아들여지지 않고, 콘솔은 상기 동일한 메뉴를 유지한다. 만약 게스트 엔트리가 적절한 메뉴 선택이라면, 상기 콘솔은 유효 상태로 리턴한다(스텝 70274).
도 70P는 콘솔의 사용자 엔트리 확인 절차(Console Validate User Entry routine)를 도시한 것으로, 이는 VFP의 가입자 서비스를 이용하는 가입자에 의한 시도를 콘솔이 확인하는 것에 의해 사용된다. 콘솔은 사용자 엔트리가 적용 가능한 메뉴에서의 유효한 선택 중 하나인지를 판단하여(스텝 70280), 만약 그렇지 않다면, 스텝 70282에 도시된 바와 같이, 상기 엔트리는 받아들여지지 않고, 콘솔은 상기 동일한 메뉴를 유지한다. 만약 사용자 엔트리가 적절한 메뉴 선택이라면, 상기 콘솔은 유효 상태로 리턴한다(스텝 70284).
도 70Q는 콘솔의 완료 확인 절차(Console Validate Completion routine)를 도시한 것으로, 이는 콘솔이 유효 전화 번호의 엔트리를 확인하는 것에 의해 사용된다. 스텝 70292에서, 콘솔은 가입자에 의해 국내 텀 플래그(domestc terms flag)가 설정되어 있는지를 판단하여, 만약 그렇지 않다면, 상기 콘솔은 국내 전화를 사용할 수 없음을 나타내는 메시지를 발생시키고(스텝 70294), 상기 입력된 번호가 유효하지 않음을 나타내는 지시로 리턴한다(스텝 70310). 스텝 70296에서, 콘솔은 10자리수의 번호가 입력되었는지를 판단하고, 스텝 70298에서, 유효한 MPA-Nxx 번호가 입력되었는지를 확인한다. 만약, 입력된 번호가 10자리의 유효한 MPA-Nxx 번호가 아니었다면, 상기 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70302), 입력된 번호가 유효하지 않음을 나타내는 표시로 리턴한다(스텝 70310). 스텝 70304에서, 상기 콘솔은 NADP 블로킹이 가입자에 대해 유효한지를 판단하고, 스텝 70306에서, 976 블로킹이 가입자에 대해 효과가 있는지를 확인한다. 만약, 상기 두 블로킹 중 하나라도 유효하다면, 상기 콘솔은 지정한 번호에 대한 통화가 차단되었음을 나타내는 메시지를 발생시키고(스텝 70308), 입력된 번호가 유효하지 않음을 나타내는 표시로 리턴한다(스텝 70310).
도 70R은 콘솔의 국제 완료 확인 절차(Console Validate International Completion routine)를 도시한 것이다. 스텝 70322에서, 콘솔은 가입자가 국제 통화 배치가 설정되었는지를 확인하여, 만약 그렇지 않다면, 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70324), 입력된 번호가 유효하지 않음을 나타내는 지시로 리턴한다(스텝 70340). 스텝 70326에서, 콘솔은 상기 번호가 국제 번호임을 나타내도록 설정된 "011"로 시작되는지를 확인하고, 스텝 70327에서, 콘솔은 입력된 번호가 국제 전화번호로서 유효한 것인지를 판단한다. 만약 상기 번호가 "011"로 시작되지 않거나 또는 유효하지 않다면, 상기 콘솔은 이를 나타내는 메시지를 발생시키고(스텝 70328), 상기 번호가 유효하지 않음을 나타내는 표시로 리턴한다(스텝 70340).
스텝 70330에서, 콘솔은 씨셋 블로킹(Cset blocking)이 특정 번호를 차단할 것인지를 확인하여, 만약 그렇다면, 콘솔은 이를 나타내는 메시지를 발생시킨다(스텝 70332). 만일, 어떤 에러 조건이 발견되지 않았다면, 콘솔은 유효상태로 리턴한다(스텝 70334).
상술한 진보된 직통선 MCI 제품의 구현은 요금 청구 절차에서 다음과 같은 효과가 있다.
직통선 MCI 국내 요금 청구 타입 : 15
직통선 MCI 국제 요금 청구 타입 : 115
직통선 MCI 통화 타입
요금 청구 세부 기록과 요금 청구를 위한 OSR, 그리고 재시작을 위한 SCAI 메시지 작업은 다양한 직통선 MCI 통화 타입을 위해 다음과 같이 있다:
요금 청구 타입 115는 VFP(통화 타입 144)에 의해 생성되는 BDR에는 적용할 수 없다. 왜냐하면 이러한 모든 통화들은 VFP에서 비롯되므로, 이들은 요금 청구 타입 15를 사용하여 국내에서 발생되는 것으로 모두 청구된다.
* 계좌번호는 사용자의 800/8xx 엑세스 번호를 참조한다.
** 종료 상태는 제안된다; 다른 값들이 보다 적합할 수도 있다.
Guest 연결종료 BDR은 연결종료가 상기 통화 순서의 어느 시점에서 왔는지에 따라 다른 통화 타입을 갖는다.
다음은 자동 응답 장치(ARU)에 대한 새 직통선 MCI 스크립트로서, 그것들이 나타나는 관련 통화 순서 다이어그램을 참조한 것이다. diagram
다음은 콘솔 적용을 위한 새로운 직통선 MCI 스크립터들이다.
ARU 영향은 아래에 상세히 기술되어 있으며, 또한 그 통화 흐름 도표도 나와 있다.
사용자 입력
일반적으로, 통화 흐름을 통틀어, 사용자/발신자 입력에 대한 모든 기회마다, 응답 지연의 가능성은 가능한 한 최소화 되었다. 다음에 몇 가지 예가 있다:
통화의 '게스트' 부분 동안, 가입자는 '*'를 입력할 것이다. 그 때 NIDS 오디오 서버(NAS)가 6 자리의 패스코드를 합하기 시작하는데, 이때 상호-자리수 타임아웃(inter-digit timeout)이 적용된다. 게스트 메뉴의 진행동안, '*'를 제외한 어떠한 단일 키가 입력되면 즉시 응답이 오게 된다. '*'가 필요한 곳에서는 6자리수의 패스코드가 입력되어야 한다. 사용자 메뉴 진행 중에는 어떠한 단일 키가 눌러지면 즉시 응답이 오게 되는데, 외부 통화(Outbound Call) 메뉴인 경우만 예외이다. 그 이유는 국내 전화 번호, 국제 전화 번호, 또는 단축 다이얼 번호가 이 메뉴에서 입력되도록 되어 있기 때문이며, 시스템은 사용자에게 다이얼한 자리수의 끝임을 의미하는 '#'을 누르도록 허용한다. '#은 단일 자리수 입력 후 또는 여러 자리수의 전화번호 다음에도 올 수 있다.
사용자가 국내 또는 국제 번호를 입력할 수 있는 곳에서는 통화 순서의 어느 곳에서든지 '#' 키가 다이얼 자리수의 끝을 표시하도록 되어 있다. 이것은 첫 번째, 두 번째, 또는 세 번째 가입자 찾기 번호들과 단축 다이얼 번호들 및 POTS로의 오버라이드 경로 지정의 프로그래밍도 포함한다.
여기서 가능하면, 사용자에 대한 '파워 다이얼' 능력은 상기 통화 순서 안에 내장된다. 이것은 다수의 키들이 입력되는 경우에는 스크립트가 바이패스되고 적절한 메뉴에 도달하였음을 의미한다.
이러한 실시예에서 하나의 액세스 방법은 직통선 MCI에 대해 유지된다; PIN 없어 800/8xx 번호를 액세스 하는 방법. 데이터 베이스에서 상기 PIN 부분은 0000으로 기본 설정된다.
요금 청구된 번호 차단(부정행위) 확인
수신된 모든 직통선 MCI 통화는 요금 청구된 번호 차단 확인을 요하는데, 이는 상기 번호가 부정행위 위험으로서 식별되지 않았다는 것을 증명하는 것이다. 상기 룩업(lookup)은 카테고리 5, 타입 0 안에 있다; 확인된 플래그는 신용카드(Hot) 플래그이다. 상기 번호가 '폐쇄(shut down)'되었을 경우, 즉 상기 핫(Hot) 플래그가 'Y'로 설정되는 경우에, 어플리케이션은 상기 통화를 오프라인 거래로서 취급하지만, 가입자가 프로그래밍 선택에 액세스하는 것은 허가하지 않는다.
세계전화(WorldPhone)
발신자들은 세계전화(WorldPhone)을 통해 직통선 MCI 플랫폼에 액세스가 가능하다. 바람직한 실시예에서, 이 통화들은 SCAI 메시지의 발신 번호 부분에서 의사 ANI(pseudo-ANI)로 직통선 플랫폼에 도달한다. 상기 의사 ANI는 세계전화 통화의 확장이 시작되었던 특정한 특징 그룹 A(Feature Group A : FGA) 회로와 연관된다. 다른 실시예에서는, 상기 실제 발신 국가 정보는 상기 직통선 플랫폼에 전송된다; 상기 발신 번호 부분은 세 자리수의 국가 코드가 차지한다.
바람직한 실시예에서, 세계전화로 발신된(WorldPhone-originated) 직통선 통화는 다음과 같이 요금 청구된다:
세계전화를 통해 발신되고 그 발신으로서 의사 ANI로 직통선 플랫폼에 도달하는 통화들은 요금 청구 타입 15를 이용하는 국내용으로서 청구된다. BDR에서 상기 발신 번호 부분은 FGA 의사 ANI 이다.
다른 실시예에서, 통화는 다음과 같이 요금 청구된다:
ARU 및 콘솔은 발신 번호 부분이 의사 ANI 또는 실제 발신 정보를 포함하는지를 확인하기 위한 코드를 구현한다. 만약 실제 국가 코드 발신 정보가 제공되면, 애플리케이션은 그것의 구성 파일을 참조하는데, 여기서 세계전화 의사 ANI는 선택적 엔트리이다. 상기 구성 파일에서 이 아이템의 존재는 애플리케이션이 어떻게 통화의 요금청구를 해야 하는지를 나타낸다.
만약 애플리케이션이 그것의 구성 파일에서 세계전화 의사 ANI를 발견하면, 상기 통화는 요금 청구 타입 15를 사용하는 국내용으로서 청구된다. BDR에서 통화하는 번호가 그것의 세계전화 의사 ANI로 설정되고, 애플리케이션은 브릿지 스위치가 그것의 발신번호를 동일한 의사 ANI로 변경하도록 지시한다.
만약 애플리케이션이 구성 파일에서 세계전화 의사 ANI를 찾지 않는다면, 상기 통화는 요금 청구 타입 115를 사용하는 국제용으로서 청구되고, 스위치 기록에서 발신 번호 정보는 계속 유지된다. 상기 BDR은 10자리수의 문자열이 차지한다; '191' + 3자리수 국가 코드 + '0000' .
게스트 통화 경로 지정은 몇 가지 방법에서 직통선 MCI 가입자에 의해 규정되는데, 이는 다음의 단락에서 설명된다:
블로킹은 발신지를 근거로 하여 게스트 착신에 대해 확인하는데, 이것은 아래에 포함된다.
통화 경로 지정(Call Routing)
통화 경로 지정 정의에서 사용자에게 두 개의 선택사항이 주어진다; 가입자 찾기(Find-Me) 절차와 스케쥴 시퀀스. 스케쥴 정의의 예외로, 사용자는 DTMF를 통해 통화 경로 지정을 정의할 수 있다.
3-번호 가입자 찾기 절차(Find-Me Sequence)
만약 사용자가 통화 경로 지정으로 Find-Me 절차를 선택하였다면, 애플리케이션은 사용자의 첫 번째 프로그램된 번호로 통화를 개시한다. 만약 실제 응답을 받았다면, 상기 게스트 발신자는 상기 응답한 측에 연결된다. 아래에 설명된 통화 차단은, 통화가 연결되기 전에 응답측에서 상기 통화를 능동적으로 받아들여야 하는 경우에 활성화 될 것이다. 만약 상기 첫 번째 번호의 회선이 통화중이면, 상기 통화는 아래에 설명된 사용자에 의해 프로그램된 대안 경로 지정으로 경로가 지정된다. 만약 설정된 시간 후에도 어떤 응답도 감지되지 않으면, 애플리케이션은 사용자의 두 번째 프로그램된 번호로 통화를 개시한다.
두 번째 번호의 응답 처리는 사용자의 세 번째 번호에 대한 통화 시도에서 아무런 응답이 없는 결과에 대한 첫 번째 번호에 대한 통화 시도와 동일하다. 세 번째 번호에서의 응답 처리는 대안 경로 지정에서 아무런 응답이 없는 결과에 대하여 동일하다. 만약, 상기 통화 절차의 어느 시점에서라도 착신 슬롯이 프로그램되지 않는다면, 애플리케이션은 이 절차에서 그 번호를 스킵하고, 다음 번호 또는 대안 경로 지정을 진행한다.
임의의 프로그램된 국제 종료에 대하여, 어플리케이션은 착신 지역 코드를 국가 코드 테이블에서 찾는다. 만약, 그 지역에 대하여 Direct Dial Country 플래그가 'Y'로 세트되어 있으면, ARU는 그 콜을 처리하기 위하여 매뉴얼 콘솔(TTC=le)를 전송한다.
2 레벨 스케쥴 시퀀스
만약 사용자가 콜 루팅을 위하여 스케쥴 시퀀스를 선택했다면, 어플리케이션은 스케쥴 1 트랜스 및 스케쥴 2 트랜스 필드를 키로서 사용하기 위하여 800 변환(translation) 데이터 베이스로 가담시켜, 스캐쥴 정보를 검색한다. 사용자의 두 개의 스캐쥴 변환으로부터, 그리고 현재의 날짜와 시간을 사용하는 것으로부터, 제1 및 제2 스케쥴 번호들이 결정된다.
콜이 제1 스케쥴 번호로 들어가고, Find-Me 시퀀스 부분에서 설명된 바와같이 응답 처리는 제2 스케쥴 번호로의 콜 시도를 일으키는 응답을 갖지는 않는다. 제2 스케쥴 번호에서의 응답처리는 우회 루팅을 일으키는 응답과는 같지 않다.
만약, 스케쥴 콜 스퀀스의 임의의 포인트에서, 다시 착신번호를 찾을 수 없다면, 어플리케이션이 시퀀스에서 그 슬롯을 건너뛰어, 다음 번호 또는 우회 루팅으로 진행할 것이다.
사용자의 스케쥴은 오더 엔트리(Order Entry) 동안 설정되고, DTMF를 통하여 사용자가 업데이트할 수는 없다. 오더 엔트리에서, 사용자는 자신의 스케쥴을 주간, 날짜, 시간(20분 단위로 증가), 시간영역(Time Zone)으로 정하도록 요청받는다.
오버라이드(override) 루팅
사용자가 모든 게스트 요청자들에 대한 특별한 루팅을 처리함으로써 게스트 메뉴의 프리젼테이션을 디스에이블하도록 하는 옵션이 DTMF를 경유하여 가능하다. 오버라이드 루팅을 통하여, 사용자는 요청자들을 단일 전화번호에 연결하거나, 요청자가 보이스메일 메시지를 남기도록 하거나, 요청자가 그에게 페이지(page)하도록 하거나, 또는 프로그램된 콜 루팅(Find-Me 또는 스케쥴)을 통해 요청자를 연결할 수 있다.
만약, 사용자가 전화번호에 루팅하기 위하여 오버라이드 루팅을 했다면, 그 번호에서 우회 루팅 처리를 일어나게 하는 응답은 일어나지 않는다.
우회 루팅(Alternate Routing)
우회 루팅은, 가입자에 접근하려는 시도를 했지만 응답이 없는 요청자의 처리를 사용자가 DTMF를 통해 정의하도록 해준다. 우회 루팅 옵션은 보이스메일, 페이저, 종료 메시지, 보이스메일의 게스트 옵션, 또는 페이져의 게스트 옵션을 포함한다. 우회 루팅을 위한 디폴트는, 프로그램되어 있지 않을때, 종료 메시지를 플레이한다.
디폴트 루팅
사용자는 게스트 메뉴가 나타날때 두 번의 시도에도 응답을 하지 않는 요청자를 위하여 오더 엔트리 취급을 지정할 수 있다. 디폴트 루팅 옵션은, 게스트 메뉴가 다시 나타나는 오퍼레이터(TTC=67)로의 변환, 우회 루팅을 일으키는 응답이 없는 전화번호, 보이스 메일, 또는 콜 루팅(Find-Me 또는 스케쥴)이다. 디콜트 루팅을 위한 디폴트는 만약 프로그램되지 않으면 오퍼레이터를 전송한다.
콜 스크리닝
사용자는 콜 스크리닝(Call Screening)을 불러내기 위하여 모든 게스트 요청자를 나타낼 수 있다. 콜 스크리링 옵션들은 콜 스크리닝 없음, 이름 및 ANI, 단지 ANI(ANI only), 단지 이름, 등의 예비 프로그래밍을 포함한다. 사용자는 DTMF를 경유하여 콜 스크리닝을 프로그램할 수 있게 된다.
단지 이름 또는 이름 및 ANI 스크리닝이 프로그램될 때, 요청자의 이름이 기록된다. 만약 사용자가 프롬프트에 응답하지 않는다면 아무것도 기록되지 않으며, 시스템은 단지 ANI 스크리닝으로 디폴트될 것이다. 착신 전화번호로 응답이 도착할 때, 요청자의 이름 또는/그리고 ANI는 플레이되고 응답측에서는 그 요청을 받아들이거나 거절할 것이 요구된다. 만약, 그 콜이 받아들여지면, 요청자는 연결될 것이다. 만약 콜 스크리닝이 ANI 스크리닝을 포함하고 발신번호가 지역 코드이면, "...국제 로케이션"라는 글자가 ANI 대신에 표시될 것이다. 만약, 그 콜이 거절되거나 응답측으로부터 아무런 응답이 수신되지 않으면 요청자는 음성 메시지를 남길 것을 요청받거나, 만약 사용자가 보이스메일에 가입하지 않았으면 종료 메시지가 플레이될 것이다.
타임아웃 파라미터
타임아웃 값은 다음과 같은 종료를 위하여 다이렉트라인 MCI 데이터 베이스에서 몇초 이내에 설정된다.
| 착신에 대하여 | 사용되는 타임아웃 값 |
| 제1 Find-Me | 제1 타임아웃 |
| 제2 Find-Me | 제2 타임아웃 |
| 제3 Find-Me | 제3 타임아웃 |
| 스케쥴 1 | 제1 타임아웃 |
| 스케쥴 2 | 제2 타임아웃 |
| 전화번호 일때, 오버라이딩 루팅 | 오버라이드 타임아웃 |
| 전화번호 일때, 디폴트 루팅 | 디폴트 타임아웃 |
이들 타임아웃 값들은 25초로 디콜트되지만, 사용자는 그것들을 고객 서비스를 통하여 변경할 수 있다.
콜 연결 시간
콜 연결 지연은, 프로그램된 착신의 게스트 콜이 완료될 때 가장 최소화된다.
응답 검출
전화번호의 모든 콜 시도에 대하여, 응답기를 검출하는 것에 대한 처리는 Machine Detect 플래그의 롤(Roll)에 의해 정의된다(State 플래그, 9비트). 만약 이 플래그가 'N'으로 설정되어 있다면 요청자는 응답기에 연결되며, 'Y'로 설정되어 있다면 어플리케이션은 우회 루팅 또는 요청(calling) 시퀀스에서 다음번호로 루트된다.
ISN에 대한 현재의 응답검출 수행은 다음과 같다. NAS는 99%의 신뢰성으로 정상적으로 응답을 검출하며, 응답기는 67%의 신뢰성으로 정상적으로 검출될 것이다.
이러한 필요에 따라 특별히 지정되지 않은 임의의 응답(Answer) 검출 반응에 대하여, 예를들어 고속-최번(Fast-Busy) 같은 처리는 응답 없음(No Answer) 조건에 대하여 설명한 바와 같다.
프로그램된 번호의 타당성 검사
사용자는 제1, 제2, 제3 Find-Me 번호 및 오버라이드 루팅으로 전화번호를 프로그램할 수 있다. 프로그램밍에서 번호가 받아들여지기 전에, 어플리케이션은 다음의 타당성 검사를 한다.
국내 번호
사용자가 국내 번호를 프로그램할 수 있는지를 확인하기 위하여 Domestic Terms 플래그(핀(PIN) 비트 1)를 시험한다.
패턴 매치를 찾는 카테고리 000, 타입 002, 및 프로그램된 NPA를 사용하여, 국제 블로킹 데이터베이스는 쿼리됨으로써, 프로그램된 번호가 정보/성인 서비스 번호가 아니라는 것을 보증한다.
교환 마스터(Exchange Master)는 착신이 NADP 번호인지를 결정하기 위하여 시험된다. 만약, 그렇다면, 국가 세트(Country Set) 블로킹이 허용된다. 국가 세트가 다이렉트라인 MCI 특성 레코드에서 발견되는 것과는 반대로, 프로그램된 번호와 연관있는 유사-지역 코드(PCC)는 유효하게 된다. 만약 그 PCC가 블록된다면, 그 번호로의 프로그래밍은 허용되지 않는다.
국제 번호
사용자가 국제 번호를 프로그램할 수 있는지를 확인하기 위하여, International Terms 플래그(핀 비트 2)를 시험한다.
다이렉트라인 MCI 특성 레코드로부터의 국가 세트(Country Set)가 검색되며, 어플리케이션은 프로그램된 국가 코드가 국가 세트에 대하여 블로킹되는지를 검증한다.
블로킹은 프로그래밍 게스트 착신이 하부에 포함되는지를 체크한다.
콜 흐름(Call Flow) 다이아그램은 보이스/팩스 플랫폼(VFP)으로의 전송이 필요한 여러 가지 상황을 나타낸다. 거래처 기록의 보이스메일 루트 번호 필드에서 루팅 번호를 사용함으로써 전송이 수행된다.
VFP로의 콜 확장에서 지연의 일부를 "마스크"하기 위하여, 그 콜은 "기다리시오"라는 문자가 요청자에게 보여지기 전에, 확장된다. 덧붙여, 콜 확장 지연은 인터-디지트 타임아웃을 제거함으로써 줄어든다. 콜을 보내고 문자를 보여준 후, 그 어플리케이션은 '*'에 뒤따르는 응답 검출을 기다리며, 그때, 사용자의 다이렉트라인 MCI 억세스 번호(800/8xx 번호)는 펄스로서 VFP로 전해지며, '#'에 따르는 단일모드 디지트는 처리하고자 하는 변환 타입을 VFP로 지시한다. 모드 인디케이터는 그 값중에 하나이며, 아래의 표와 같이 나타난다. 정보가 수신되었고 VFP에 의해 확인되었다는 것을 입증하기 위하여, 어플리케이션은 VFP로 부터 두 개의 DTMF '00' 톤이 표시되는 것을 기다린 다음에, 요청자가 연결된다.
| 모드 인디케이터 | 변환 타입 |
| 1 | 게스트 보이스메일 |
| 2 | 보이스 주석 있는 게스트 팩스 |
| 3 | 주석 없는 게스트 팩스 |
| 4 | 사용자 보이스/팩스 검색 |
| 5 | 사용자 리스트 유지 |
| 6 | 메일박스 이름의 사용자 기록 |
만약 두 개의 신호변경(handshake) 시도가 실패하였다면, VFP 변환시도는 실패한 것으로 인정된다. 만약 오퍼라이드, 디폴트, 또는 우회 루팅에서 보이스 또는 팩스메일로의 게스트 변환이 실패한다면, 게스트 요청자는 나중에 다시 콜을 하도록 요청받는다. 만약, 게스트 메뉴 선택에 대한 게스트 변환이 실패한다면, 메뉴는 다시 나타날 것이며, 보이스 또는 팩스메일로의 사용자 변환이 실패한다면, 사용자가 실패했음을 알리는 문자가 다시 나타나며, 사용자는 이전의 메뉴로 돌아간다.
요청 초기에 팩스 톤이 검출될때, 주석이 없는 게스트 팩스 변환이 발생한다. 팩스 톤 검출은 환영 메시지의 표시와는 별개이며, 인사말의 길이는 팩스톤의 검출에 영향을 미치지 않는다.
사용자가 사용자 프로그래밍을 억세스할 때, 어플리케이션은 가능하면 전체 메일박스 메시지, 새로운 팩스 메시지, 그리고 새로운 보이스매일 메시지의 전체 숫자를 표시한다. 어플리케이션은 이들 정보를 VFP_Trans 서비스를 통하여 VFP로부터 쿼리한다.
또한 사용자는 DTMF를 통하여 새로운 보이스 및 팩스 메시지를 호출기에 통지할 것인지에 대하여 정의할 수 있다. 호출기 통지 옵션은, 보이스메일 통지, 팩스 통지, 보이스 메일 및 팩스의 통지, 그리고 통지하지 않는 것이 있다. 호출기 통지를 위한 설정은 Vmail 플래그(핀 비트 5)의 페이지와 Fax 플래그(핀 비트 6)의 페이지에 저장된다.
페이징(Paging)
가입자를 페이지하는 옵션은 게스트 메뉴에 나타난 여러 가지 종류중의 하나이다. 또한, 게스트는 사용자의 프로그램된 오버라이드 또는 우회 루팅에 따라 페이지를 보내도록 요청받을 수 있다.
페이지를 보낼 때, 어플리케이션은 요청자에게 콜백 번호를 요청한다. 사용자의 고객 기록은 페이지를 처리하는데 사용되는 다음과 같은 정보를 포함한다: 콜을 페이저 회사로 보내는데 사용되는 페이저 처리 번호, 사용자의 페이저 핀, 그리고 페이지 정보를 교환하기 위하여 배열 가능한 다이얼 스트링을 가리키는 페이저 타입. 다이얼 스트링은 응답검출을 기다리기 위한 타임아웃 값, 응답검출 다음에 오는 지연, DTMF로의 핀 디지트의 번호, 및 예를들어 '#'과 같은 임의의 착신 문자를 제공한다. 만약 요청자가 콜백 번호를 입력한 후 연결을 끊으면, 페이저는 완료되고 발표된다. 페이저 타입은 다음의 표와 같다.
| 페이저타입 | 페이저 회사 | 페이저 다이얼 스트링 | 페이저 억세스 번호 |
| 1 | Sky Tel/MT디 | A180T32R7D#ED# | 6019609560 |
| 2 | Air Touch | A180T32R7D#ED# | 6019609560 |
| 3 | Mobile Media | A180T32R7D#ED# | 6019609560 |
| 4 | AirSignal/McCaw | A180T32R7D#ED# | 6019609560 |
| 5 | American Paging | A180T32R7D#ED# | 6019609560 |
| 6 | Mobile Comm | A180T136R6T18ET32 | 8009464646* |
| 7 | MCI Page | A180T136R7T18ET32 | 8006247243* |
| 8 | MCI Word | A180T136R6T18ET32 | 8006247243* |
* : 800-억세스 번호는 브리지 스위치에서 DAP-우회(looparound)를 통해 루트될 것이다.
사용자는 게스트 메뉴 옵션으로 페이저의 프리젠테이션을 인에이블/디스에이블할 수 있다. 페이저가 디스에이블되면, 게스트 메뉴에는 아무것도 나타나지 않으며, 프로그래밍 오버라이드 또는 우회 루팅에서도 사용자에게 나타나는 것은 없다. 보이스 메일 또는 페이저의 게스트 옵션 역시 우회 루팅 프로그래밍 선택으로부터 제거된다. 만약 오버라이드 루팅이 페이저에 세팅되고 페이저가 꺼지면, 콜은 마치 오버라이드가 없었던 것처럼 취급된다. 만약 우회 루팅이 페이저에 세팅되고 페이저가 꺼지면, 요청자는 보이스메일로 루트되고, 요청자가 보이스메일을 갖고 있으면 종료 메시지가 나타난다. 이러한 것들은 오버라이드 및 우회 루팅에 대한 디폴트 처리이다. Pager On/Off 플래그(상태 비트 13)은 페이저의 인에이블/디스에이블된 상태가 저장되었을때이다.
페이저의 인에이블/디스에이블 능력에 덧붙여, 본 명세서의 보이스메일/팩스메일 부분에서 언급된 바와같이, 사용자는 페이저 통지 옵션을 정의할 수 있다. VFP는 새로운 보이스 및 팩스 메시지를 통지하기 위해 페이저를 사용하며, ISN에 의해 지원되는 페이저 타입을 지원한다. 상태 Pager On/Off 플래그는 페이저 통지에 영향을 미치지 않는다. 새로운 메지시의 통지 없음(no notification)을 수신하기 위하여 사용자는 페이저 통지를 통지 없음(No Notification)으로 설정하도록 요구된다.
아웃바운드 다이얼링(Outbound Dialing)
사용자는 콜을 자신의 다이렉트라인 MCI 계정에 기입하는 통화를 할 수 있다. 이러한 옵션은 메인 사용자 프로그래밍 메뉴에서 나타난다. 아웃바운드 요청 옵션은, Domestic Completion 플래그(상태 비트 4)에 의존하는 국내 착신, International Compilations 플래그에 의존하는 국제 착신(상태 비트 5), 그리고 Speed Dial Completion 플래그에 의존하는 프로그램된 스피드 다이얼 착신을 포함한다(상태 비트 6).
필요한 국제 완료를 위해, 어플리케이션은 국가 코드 표에서 착신 국가 코드를 찾는다. 만약 그 국가에 대하여 Direct Dial Country 플래그가 'Y'로 세팅되어 있으면, ARU는 콜을 매뉴얼 콘솔(TTC=9d)로 전송한다.
다음의 확인 체크는 가입자를 위해 콜이 완료되기 전에 이루어진다.
국내 번호
Domestic Compilations 플래그는 'Y'로 세팅해야 된다.
국제 블로킹 데이터베이스는, 카테고리 000, 타입 002, 그리고 프로그램된 NPA를 이용하여 쿼리되며, 프로그램된 번호가 블로킹된 정보/성인 서비스 번호가 아니라는 것을 보증하기 위하여 패턴 매치를 찾는다.
착신이 NANP 번호인지를 결정하기 위하여 교환 매스터(Exchange Master)를 시험한다. 만약, 그렇다면, 타이렉트라인 자동코드 특성(AuthCode Property) 기록에서 찾아낸 국가 세트를 사용하여 국가 세트 블로킹을 인가한다. 국제 로케이션에서 가입자를 불러내는 경우, 발신지의 특성 기록으로부터 그리고 다이렉트라인 MCI 특성 기록으로부터 Country Sets을 검색하고, 어플리케이션은 PCC가 어떤 국가 세트를 위하여 차단되지 않는지를 검증한다. '191' +3-디지트 국가 코드+'0000'를 특성 기록 데이터베이스로의 키로서 사용함으로써 발신지로의 특성 기록을 찾는다.
국제번호
International Compilations 플래그는 'Y'로 세팅되야 한다.
다이렉트라인 MCI Property Record로부터의 Country Set가 검색되고, 어플리케이션은 목적 국가 코드가 그 코드 세트로 블록킹되지 않는지를 검증한다. 국제 발신의 경우, 발신지의 특성 기록으로부터 그리고 다이렉트라인 MCI 특성 기록으로 부터의 국가 세트들이 검색되며, 그 어플리케이션은 목적 국가 코드가 어떤 국가 세트를 위해 차단되지 않는지를 검증한다.
발신을 기초로한 사용자의 콜 편집을 위한 그리고 프로그래밍 스피드 다이얼 번호를 위한 블로킹 체크는 아래에 포함된다.
재발신
요청자는, 2초동안 '#'키를 누름으로써, 콜을 실행하여 VFP 또는 전화번호로 재발신을 할 수 있다. 그 스위치는 그 콜을 위해 재발신이 허용되는지를 입증하며, 만약 그렇게 된다면 요청자를 ISN으로 다시 넘겨줄 것이다.
재발신하는 요청자의 상태는 원래의 콜의 BDR의 Val Stat 필드에서 그 값으로부터 이끌어 낸다. 아래 표는 그 필드에 대하여 가능한 값들과 각 값들을 나타내는 것을 정의한다.
더욱이, # 재발신은 실행완료로부터 보이스메일/팩스메일 플랫폼까지, 가입자에게 유효하다. 이것은, 기입(Billing) 절에서 언급된 바와같이, 스위치 기록(OSR)에 있는 데이터로의 두가지 변화와 함께 수행된다.
| Val Stat 값 | 요청자 타입 | 발신 콜의 성격 | 재발신 가능? |
| 200 | 가입자 | 콜 완료 | Y |
| 201 | 가입자 | 보이스 메일 | Y |
| 202 | 가입자 | 팩스 * | n/a |
| 100 | 게스트 | 오프-라인 | N |
| 101 | 게스트 | 제1 | N |
| 102 | 게스트 | 제2 | N |
| 103 | 게스트 | 제3 | N |
| 104 | 게스트 | 오버라이드 | N |
| 105 | 게스트 | 종료 메시지 | N |
| 112 | 게스트 | 보이스 메일 | N |
| 113 | 게스트 | 페이저 | N |
| 114 | 게스트 | 팩스 | N |
* : 사용안됨 - 현재, 보이스 메일로의 억세스와 팩스 메일로의 억세스 사이에는 차이가 없음; 201의 Val Stat로 나타날 것임.
가입자 재발신
가입자 재발신은 그 자체로서 발신 콜의 Val Stat 필드를 경유하여 확인되며, 사용자 프로그래밍 메뉴가 나타난다. 보이스메일/팩스메일 플램폼 또는 전화번호를 완료한 가입자는 재발신이 허용된다.
콘솔 효과(Console Impact)
콜솔 효과는 다음 장에서, 특히 콜 플로우 다이어그램에서, 상세하게 설명될 것이다.
ARU 전송
콘솔은 표에 도시된 바와같은 이유로 ARU로부터 전송 받는다. 이들 전송의 처리는 콘솔 콜 플로우 다이어그램에 나타난다.
| TTC | 전송 이유 | 텍스트 |
| 1e | 오퍼레이터의 도움을 필요로 하는 게스트 콜 완료 | '게스트 콜은 오퍼레이터의 도움을 필요로 한다' |
| 64 | 페이저 콜백 번호 프롬프트에서 제3 비등록 | '적절히 등록되지 않은 페이저 콜백 번호' |
| 67 | 게스트 메뉴에서의 요구 또는 타임아웃 | '메인메뉴에서의 타임아웃 또는 요청된 전송' |
| 9d | 오퍼레이터의 도움을 필요로 하는 가입자 콜 완료 | '가입자 콜은 오버레이터의 도움을 필요로 한다' |
억세스 방법
ARU 효과 절의 억세스 방법 절에서 언급
직접 부름
다음을 제외하고, ARU 효과의 직접 부름 절에서 언급
디폴트 루팅
디폴트 루팅은 프로그램되거나 오퍼레이터 전송에서 디폴트 될때를 제외하고, 콘솔에서 효과를 갖지 않는다. 이 경우, 콜은 표시되는 게스트 메뉴와 함께 새로운 콜로서 다루어질 것이다.
보이스 메일/팩스메일
ARU 효과의 보이스메일/팩스메일 절에서 언급
페이징(Paging)
ARU 효과의 페이징 절에서 언급
아웃바운드 다이얼링(Outbound Dialing)
ARU 효과의 아웃바운드 다이얼링 절에서 언급
재발신
ARU 효과의 재발신 절에서 언급
플래그 종속(Flag Dependencies)
플래그 종속은 다음의 표에서 보인다.
블로킹 체크
이 명세서에 플래그 체크에 대한 설명이 없으며, 국가 세트, 성인 서비스('Adult Services')(976) 그리고 인터-NANP 블로킹에 대하여 언급한다. 필요할 경우, 국가 세트 블로킹에 대하여 디폴트 ANI 특성 기록을 사용한다.
976 블로킹은 아래와 같이 수행된다.
패턴 매치를 찾기 위한 프로그램된 NPA, 카테고리 000, 및 타입 002를 사용함으로써, 국제 블로킹 데이터 베이스가 쿼리됨으로써, 프로그램된 번호가 블록된 국제/성인 서비스 번호가 아닌 것을 보장한다. 만약 매치가 발견되지 않으면, 콜/프로그래ald은 수행되지 않는다.
인터-NANP 블로킹은 아래와 같이 수행된다.
착신이 NANP 번호인지를 결정하기 위하여 교환 마스터(Exchanger Master)를 검사하며, 만약 그렇다면, 인트라-NANP 플래그가 'Y'로 세트되어 있는지를 체크하며, 조건을 만족하면, 발신번호를 위해 인트라-국가 플래그가 체크된다. 발신번호를 위한 인트라-국가 플래그 역시 'Y'로 세트되어 있으면, 콜은 블록된다. 그렇지 않다면 콜이 허용될 것이다. 요컨데, 발신 및 착신 번호의 인트라-국가 플래그가 모두 'Y'이면, 그 콜은 블록되며, 어느 하나라도 'N'이면 그 콜은 허용된다.
국가 세트 블로킹은 다음과 같이 수행된다.
다이렉트라인 MCI 특성 기록의 국가 세트, 그리고 아래와 같은 발신 ANI/지역은, 착신의 국가 코드에 반하여 유효하게된다. 만약 착신 국가가 임의의 국가 세트에서 블록된다면, 콜은 블록된다.
게스트 콜 완료
| 착신 G발신 B | 국내 | NANP | 국제 |
| 국내NANP국제 | 인터-NANP(허용)인터-NANP(허용)허용 | 인터-NANP(허용)착신 PCC, 발신 ANI ＆ 우회 Cset을 사용한 블로킹인터-NANP(블록)착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹 | 착신 CC, 발신 ANI* ＆ 우회 Cset을 사용한 Cset 블로킹착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹 |
사용자 콜 완료
| 착신 G발신 B | 국내 | NANP | 국제 |
| 국내NANP국제 | DomesticComp 플래그인터-NANP(허용)976 블로킹DomesticComp 플래그인터-NANP(허용)976 블로킹Domestic Comp 플래그976 블로킹 | Domestic Comp 플래그인터-NANP (허용)976 블로킹착신 PCC, 발신 ANI ＆ 우회 Cset을 사용한 Cset 블로킹Domestic Comp 플래그인터-NANP(블록)976 블로킹Domestic Comp 플래그976 블로킹착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹 | International Comp 플래그착신 CC, 발신 ANI ＆ 우회 Cset을 사용한 Cset 블로킹International Comp 플래그착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹International Comp 플래그착신 CC, 발신 ANI ＆ 우회 Cset를 사용한 Cset 블로킹 |
프로그래밍 루팅
| 착신 G발신 B | 국내 | NANP | 국제 |
| N/A | Domestic 플래그976 블로킹 | Domestic 플래그976 블로킹착신 PCC, 우회 Cset를 사용한 Cset 블로킹 | International 플래그착신 PCC, 우회 Cset를 사용한 Cset 블로킹 |
프로그래밍 속도 다이얼 번호
| 착신 G발신 B | 국내 | NANP | 국제 |
| N/A | Domestic Comp플래그976 블로킹 | Domestic Comp 플래그976 블로킹착신 PCC, 우회 Cset를 사용한 Cset 블로킹 | International Comp 블로킹착신 PCC, 우회 Cset를 사용한 Cset 블로킹 |
XIX. 인터넷 팩스
A. 개요
PSTN에서의 대부분의 콜은 팩스 콜이다. 이 콜은 엔코딩된 디지털 정보를 보내며, 전화 회사 본사(Central Office; CO)로 아날로그 전송하기 위해 변조된다. 본사(CO)에서 아날로그 신호는 연속적인 전송을 위해 64 Kbps의 PSTN에서 디지털화 된다. 착신국 본부(CO)에서 디지털 신호는 아날로그로 변환되어 수신 팩스로 전송된다. 국제 팩스 통신의 연속적인 전송으로 인해, 부족한 전송 성능의 유용성이 높아지며, 국제 직통 다이얼 폰 서비스의 비용이 높아진다.
B. 세부사항
현재, 인터넷을 통해 팩스와 음성을 보내는 것에 대한 관심이 증가하고 있다. 과거에, 팩스는 네트워크에서 일부를 차지하는 것으로 인식되었으며, 인터넷에서 고유의 지능을 사용하지는 않았다. 바람직한 실시예는, 전화 네트워크를 설명하기 보다는 인터넷에 대한 팩스를 명백하게 루트한다. 적절한 로직의 도움을 받는 네트워크는 라인의 톤을 검출함으로써 팩스 콜을 검출할 수 있다. 그러면, 그 콜은 인터넷에서 팩스를 수행하는 다른 하드웨어 또는 소프트웨어의 일부분으로 전해진다. 네트워크는 착신국 팩스의 전화번호를 어드레스로서 사용함으로써 루팅을 수행한다. 그러면, DAP를 억세스함으로써, 적절한 게이트웨이가 선택되어, 그 콜은 번화번호에 기초한 적절한 착신국으로 루트된다. 이것은 DAP로 루팅 요청를 보냄으로써 달성된다. DAP는 여러 가지 방법중에서 하나의 방법으로 착신국 게이트웨이를 선택한다. 그 방법은 오리진 포인트에 의해 지정된다. 즉, 룩업 테이블에 의해 특정 오리진 포인트는 특정 착신국 게이트웨이를 할당한다. 다른 방법으로는 로드 밸런스 기법에 의한 것이 있다. 네트워크 로직은 정상적인 전화 네트워크 활동을 정확히 검출할 수 있고, 그것을 보전성에 영향을 미치지 않는 상태에서 인터넷으로 전송할 수 있다. 일 실시예는 현재의 전화 크래디트 카드와 유사한 이중 다이얼링 시나리오를 사용한다. 첫 번째 번호는 콜이 어떻게 루트되었는지를 나타내기 위해서 사용되며, 두 번째 번호는 적절한 게이트웨이가 식별되었을 때 다른 전화 콜 처럼 그 콜을 착신 어드레스로 루트하기 위해 사용된다.
인터넷에서 팩스의 우회 가능한 루팅과 연관된 상세한 로직은 트렁트 그룹에서 콜을 모니터링함으로써 달성된다. 회사나 다른 조직은, 일반적으로, 그 조직의 요구에 서비스할 수 있기 위하여 배타적으로 사용될 수 있는 트렁크 라인에 대한 능력을 구매할 것이다. 바람직한 실시예의 트렁크 그룹은 예컨데, 공공 교환망 대신에 X.25 네트워크 또는 인터넷과 같은 데이터 네트워크를 통해 기설정된 캐리어를 위해 예정된 팩스를 전환하기 위한 디지털 신호 처리기(DSP)를 포함하는 것과 같이, 하이브리드 네트워크로 될수 있는 적절한 검출 하드웨어로 구체화 될 것이다. 특정 트렁크 그룹으로의 콜 검출은 명백하게 수행된다.
트렁크 그룹은 콜을 인터넷 네트워크로 전환시키기 위한 브리지 스위치로 된다. 지능망은, 그 콜이 PSTN이 아닌 어떤 다른 데이터 네트워크 또는 인터넷을 통하여 특별한 루팅을 처리하기 위하여 타겟(지정)되는 특정 지역에 관련되는지를 검출한다. 만약 그 콜이 그 특정지역의 코드로 타겟되지 않으면, 그 콜은 정상적으로 PSTN을 경유하여 착신지로 루트된다.
항목(detail)을 하나 더 낮추어서, 그 콜이 MCI 스위치에 도달할 때, 스위치는 그 콜에 대한 루트를 요청하는 DAP 쿼리를 내보낸다. DAP는 다이얼링된 번호와 다른 프로파일 정보를 근거로 그 콜을 해석한 후 그 콜을 검출 시스템에서 수행된 팩스로 루트 시킨다. 팩스 톤 검출 시스템은 팩스 CNG 톤에 주의를 기울이고, 만약 CHG 톤이 검출되면 두 번째 폰 콜은 팩스 인터넷 게이트웨이에 자리잡는다. 그 팩스 인터넷 게이트웨이가 답신을 하면, 제1 및 제2 콜은 브지리 스위치에서 같이 브리지된다.
요구되는 변경은 착신에 의해 인커밍 콜을 차단하기 위한 것이다. 기설정된 타깃 착신을 위해, 지능망은 추가적인 처리가 이루어지는 동안 콜을 유지한다. 이것은 도 52B에 도시된 바람직한 실시예에 따라 수행된다. 그 도면에서, 사용자의 발신 팩스(F1)는, 스위치(5260)을 경유하여 전화선에 연결된다. 스위치(5260)는 그 콜을 스위치(5261)을 경유하여 연결하고, 루팅 데이터의 쿼리를 위하여 루팅 요구를 DAP(5262)로 위치시킨다. 그 DAP는 장기간 규제 루팅(Long Term Regulatory Routing) 데이터 베이스등의 루팅 데이터 베이스에 연결된다. 트렁크 역시 부호 5263으로 나타나는 팩스 톤 검출기(Fax Tone Detector;FTD)인 적절한 로직에 연결된다. 그 로직은 스위치(5261)(5265)를 경유하여 팩스 게이트(5264)의 기 설정된 지역들을 위해 정해지는 팩스 콜을, 기 설정된 국가에서 팩스 게이트웨이(5267)로의 우회 데이터 네트워크(5266)로 루트 하는 로직을 포함한다. 기설정된 국가가 아닌 다른 국가에 대하여, 스위치(5261)은 PSTN을 경유하여 그 콜을 보낼 것이다.
도 52B에 도시된 상기한 실시예의 동작은 도 52C의 플로우 차트에 나타난다. 플로우 차트의 단계(5270)에서, 도 52B의 발신 스위치(5261)는 그 콜을 수신한다. 그 콜은 전화, PC, 팩스(F1), 또는 다른 적절한 디바이스로부터 올 수 있다. 단계(5271)에서 DAP는 그 콜에 관련된 착신 정보를 사용하면서 스위치(5261)을 경유하여 쿼리된다. DAP는 루팅 정보를 찾으며, 착신이 기설정된 국가, 시(city), 또는 다른 관심있는 곳인지에 대한 판단은 단계(5273)에서 이루어진다. 조건을 만족하지 않으면, 단계(5274)에서 그 콜은 정상 루팅을 통해 처리된다.
만약, 그 콜이 기 설정된 관심있는 착신을 위한 것이라면, 단계(5275)에서 FTP로 루트된다. 그러면, FTP는 이 콜이 팩스콜인지를 단계(5276)에서 결정한다. 이것은 널리 알려진 수단에 의해 CNG를 검출하려는 동작에 의해 이루어질 수도 있다. 이러한 것을 달성하기 위한 하나의 방법으로, 타이머가 사용될 수도 있다. 만약 CNG톤이 특정 주기안에 검출되지 않으면, 그 콜은 팩스 콜이 아닌 것으로 인정되며, 그 경우, 단계(5277)에서 PSTN에서의 정상 루팅을 통해 해제되고 브리지된다. 만약, CNG 콜이 검출되면, 그 콜은 단계(5278)에서, 팩스 게이트(5264)에서 해제되고 브리지되고, 그 콜이 연결됨으로써 팩스는 우회 데이터 네트워크(5266)으로 전송되고 팩스 게이트(5267)로 보내진 다음, 착신 지점에서의 팩스(F2)로 보내진다.
이것은 여러개의 국가를 포함하는 도메인 네임을 경유하여 루트할 수 있다. 도메인 네임 서버는 여러개의 콜을 룩업 테이블을 경유하여 여러개의 착신국으로 분배 할 것이다. 게이트웨이는 착신국에 위치할 것이며, TCP/IP 세션은 제어를 위하여 게이트웨이와 함께 셋업될 것이다. 데이터는 특정 네트워크 특성을 근거로 한 TCP 또는 UDP를 지날 수 있다. 어떤 경우에는, 다이얼링된 디지트들은 그 디지트들을 전화번호가 다이얼링된 착신 게이트웨이로 향하도록 하는 오리진 게이트웨이를 통화한다.
다음으로, 착신 게이트웨이는 착신번호를 다이얼하고, 팩스를 다른 쪽에 맞물리게 한다. 이 시스템은 전화 신호를 패킷으로 변환시켜 되돌리는 두쌍의 팩스모뎀을 사용한다. 그 팩스 모뎀들은 다른 모뎀들과 마찬가지로 보(baud) 레이트 동안 교섭하지만, 매시간 동안 수행함으로써 하나의 페이지가 전송된다. 각 모뎀은 그 기능을 기입하고 자신이 지원할 수 있는 속도를 교섭한다. 첫째로, 팩스 정보의 전송을 시작하고, ACK는 각 페이지 이후에 전송되고, 마지막으로 보 레이트는 다시 300 보(LCD)로 재교섭된다. 결국, 메시지는 먼거리의 모뎀으로부터 수신되고, 패킷은 팩스 패키지로 다시 패키지된다. 각 페이지의 마지막에, 에러 율에 따른 보 레이트의 재교섭이 일어나며, 만약, 에러가 너무 많으면 그 팩스들은 그 페이지를 다시 송신하고/또는 전송하거나, 다시 전달하기 전에 더 낮은 속도로 재교섭될 것이다.
바람직한 실시예에 따라, 시스템은 팩스 정보를 전달하기 전에 착신 전화 회로가 연결되는지를 검출한다. 이와같은 처리에 연관된 오버헤드는 정상 팩스 프로세스에서 다음과 같은 손실을 일으킨다.
1) 자동접속지연의 증가, 그리고
2) 팩스를 실제로 전송함으로써 5% 더 길어진다.
XX. 인터넷 스위치 기술
A. 실시예
현재의 스위치 네트워크의 문제점은 제정된(legislated) 특성 그룹 D 트렁크를 경유하여 연결되는 로컬 교환 캐리어(LEC)를 사용할 때, 싼값으로 억세스를 제공하기는 어렵다는 것이다. 왜냐하면, 억세스 요금은 LEC에 의해 규정되기 때문이다. 그러므로, 만약 인터넷 억세스가 특성 그룹 D 트렁크를 사용하는 서비스를 통해 제공된다면, 소비자에게 부과되는 비용은 과도하게 된다. 만약 그 특성 그룹 D 트렁크가 바이패스된다면, 규정된 네트워크가 제공된다. 예를들어, LEC는 인터넷을 억세스하는 모뎀 풀에 직접적으로 연결되고, 두 번째 문제가 발생한다. 이러한 문제점들은, 확장성, 생존성(survivability), 및 디자인의 비효율성등을 포함한다. 더욱이, 모뎀은 LEC로부터 구입한 DS0의 각각을 위하여 필요할수도 있다. 이러한 모든 문제점들은 아래에서 논의될 구성에 의해 해결된다.
모뎀풀은 네트워크 통화량 요구를 만족시키기 위해 조정될 수 있기 때문에, 확장성은 도 1C에 도시된 CBL들에 의해 주소 지정된다. CBL들은 관심있는 특정 집단의 요구를 만족시키기 위해 조정될 수 있다. 전용 네트워크에서, 일대일 관계는 CBL들 사이에서 존재하며, 모뎀풀에 기입한다. 그러므로, 만약 모뎀이 연결되지 않는다면, 사용자에게 서비스할 가능성은 직접적으로 모뎀을 사용하는 능력에 의해 결정된다. 모뎀풀들과 CBL들과의 직접적인 관계를 제거함으로써, DAP는 동적자원들이 존재하는 모든 네트워크를 통하여 얻어진 동적 자원들로의 콜들을 매핑할수 있다. 이러한 디자인은 현재의 어떤 아키텍쳐보다 더 효과적이다. 이러한 아키텍쳐의 상세한 설명은 아래와 같다.
바람직한 실시예에 의해 해결되는 세 번째 문제점은 이전의 두 문제점등을 해결하는 직접적인 결과이다. 콜을 네트워크에서 루팅하는 방법은 단지 LEC에 의해 발신이 표시될 때 요구되었다. 핫라인의 기능성(functionality)에 관련된 실시예는 이러한 문제점들을 해결한다. 핫라인 기능성이 인에이블되는 인커밍 트렁크(회로)에서 발신이 검출되면, 데이터 베이스 룩업은 스위치의 루팅 데이터 베이스의 내부 프로세스로서 수행된다. 이러한 데이터 베이스 룩업은 콜의 착신을 임시로 결정하기 위해 사용되는 임시 다이얼링 플랜(예로서, 7 또는 10 디지트 수)을 발생시킨다. 핫라인 기능은 스위치들에 존재하지만, DAP로의 콜 정보(ADF 트랜잭션)없이 스위치로 하여금 DAL 절차 요청를 명확하게 하도록 하고 DAP를 이용하는 루팅 능력에 포함되는 것은 아니다. 그 요청은 X.25 프로토콜 링크, 로컬 에어리어 네트워크, 제3 광 연결(Optical Connection Three; OC3), ATM 네트워크, 프레임 릴레이, SMDS, 또는 DAP로의 다른 통신링크를 통하여 전송된다. 그 DAP는 추가적인 데이터베이스 룩업을 수행함으로써 적절한 착신(이 경우, 모뎀풀과의 트렁크 연결에 상응하는 착신 트렁크 그룹(TTG)및 스위치 ID(SWID)가 될 수 있음)을 결정한다. 핫라인은 위에서 언급한 문제점들을 극복하는 디자인의 기초이다.
도 71은, 로컬 다이얼 억세스를 제공하는 동안의 VNET, 비젼 또는 다른 매체등의 구내 네트워크 서비스, 할당 또는 전용 엑세스에 대한 사설 다이얼링을 전달하기 위한 하이브리드 네트워크의 전형적인 고객(customer) 구성를 보인다. FDDI LAN(10201), 트랜잭션 서버들(10205), 그리고 통신 서버들(10215)(10225)의 연결은 DAP로서 공동으로 다루어진다. 광섬유 분포 데이터 인터페이스(Fiber Distrubute Data Interface; LDDI) LAN(10201) 같은 로컬 에어리어 네트워크는 여러 가지 통신 디바이스들을 연결하기 위하여 사용된다. 도시된 바와같은 연결에서, 트랜잭션 서버(TS)(10205)는 LAN(10201)에 연결된다. 스위치(10210)(10220) 같은 전화 스위치들은 통신 서버(CS)(10215)(10225)를 통해 LAN(10201)에 각각 연결된다. 예를들어, 통신서버(CS)(10225)는 어플리케이션 데이터 필드(ADF)(10245)로 명명되는 프로토콜을 사용하여 스위치들과 통신한다. 게이트웨이(10230)은 LAN(10201)과 연결되고 고객 억세스 프로세서(Customer Access Processor;CAP) 사이에서 통신한다. 그 CAP(10235)는 인텔 펜티엄, RISC, 또는 모토롤라 68시리즈 등의 전형적인 마이크로프로세서이다. 그 DAP는 트랜잭션 쿼리를 CAP로 보내기도 한다. 그 CAP는 데이터베이스 룩업을 수행하여 예를들어, 얼마나 많은 교환원이 특정 고객 서비스 센터에서 일할 수 있는지에 대한, 상태에 기초하여 루팅 명령을 리턴한다. 그 CAP는 콜이 상기 데이터베이스 룩업을 기초로 하여 어떻게 루트되는지를 지시하는 응답을 리턴한다. 그 DAP는 기본적으로 그 자신의 데이터베이스의 확장으로서 그러한 정보를 사용한다. 다음으로, 그 DAP는 CAP(10235)로부터 수신된 정보를 해석하고, 고객이 요청한 곳으로 콜을 루트하도록 스위치가 요구하는 루팅 정보로 그 정보를 변환한다.
도 72는 10241, 10242, 10243로 도시되어 있는 DAP(10240)에 대한 동작을 나타낸다. 루팅 및 고객 프로파일 정보는, 확인된 이후에 오더 엔트리 시스템(10235)로 입력되고, 그 정보는 서비스 제어 관리자(Service Control Manager;SCM)(10230)으로 루트된다. SCM(10320)은 그 루팅 및 고객 프로파일 정보를 네트워크의 각각의 DAP로 보낸다.
예를들어, 만약, 윈도우즈 95에 문제가 발생한다면, 고객은 1-800-FIX-WIN95로 콜을 할 수 있다. 그콜은 적절한 루팅 정보를 위하여 쿼리하는 DAP(10241-3)로 트랜잭션을 시작하는 발신 스위치(10350)에서 네트워크로 들어간다. 그 쿼리된 DAP는 번호를 인식하고, 트랜잭션을 만든 후 적절한 CAP(10235)(이 경우에는 마이크로소프트 회사와 연결된 CAP)에 연결되어 있는 적절한 게이트웨이(10230)로 루트시킨다. CAP(10235)는 그 트랜잭션을 입력받아 뉴욕에 있는 고객 서비스 센터가 바쁜지를 결정한다. 그러나, 캘리포니아에 있는 고객 서비스 센터는 그렇게 바쁘지 않다(이 경우, 시간이 카운트된다). 그 CAP(10235)는 이 특정 1-800-FIX-WIN95 콜이 켈리포니아 고객 서비스 센터에 루트되어야만 하는 것을 나타내는 쿼리된 DAP(10241-3)(게이트웨이(10230)을 경유)로 응답을 다시 보낼 것이다. 선택된 DAP(10241-3)는 그 트랜잭션 정보를, 켈리포니아 고객 서비스 센터에 도착하는 MCI 네트워크로부터의 루트에 대응되는 특정 착신 트렁크 그룹(Terminating Trunk Group;TTG)과 특정 스위치 ID(SWID)로 전달한다. 선택된 DAP(10241-3)는 이 응답정보를 발신 스위치(10350)으로 전송하고, 그 발신 스위치(10350)는, SWID를 경유한 DAP 응답에서 나타난 바와같이, 1-800-FIX-WIN95의 발신 콜을 보정 착신 스위치(correct Terminating switch,10351)로 루트한다.
다음으로, 착신 스위치(10351)는 원래의 DAP 응답에서의 파라미터로부터 발생되는 SS7 네트워크를 경유하여 전송된 정보를 이용하는 보정 착신 트렁크 그룹(TTG)을 결정하고, 그 콜을 캘리포니아 고객 서비스 센터로 루트한다. 콜이 스위치를 통하여 루트되면, DAL(10386)같은 직접 억세스 라인(DAL) 연결을 통해 그 콜을 타겟 번호(10361)로 전달하는 고객 PBX(10387)로 전달된다.
도 73은 1-800 콜 처리를 하기 위한 릴리스 링크 트렁크에 전화를 연결하는 과정을 나타낸다. 전화기(10410)등의 전화기는 로컬 교환 캐리어(LEC)(10415)에 연결된다. 전화기(10410)을 사용하는 사용자는 전화기의 키패드를 사용하여 1-800번을 누르며, 그로인해 LEC(10415)가 그 콜을 MCI 발신 스위치(10420)로 루트한다. 1-800 요청을 처리하기 위하여, 스위치(10420)는 ISN(10480)과 연결해야한다. 그러므로, 스위치(10420)는 릴리스 링크 트렁크(10490)을 경유하여 지능 서비스 망(10480)에 연결된 브리지 스위치(10440)에 그 콜을 연결한다. 브리지 스위치(10440)는 DAP 요구를 1-800 정보와 함께 ISN(10480)에 전달하며, ISN(10480)은 그것을 어드레스된 DAP(10241)로 전달한다. DAP(10241)은 1-800 요구를 시험하고, DEC에 교대로 연결되는 MCI D 스위치(10410)에 연결하는 적절한 릴리스 링크 트렁크(10490)를 선택하며, 그 LEC는 궁극적으로 전화기(10410)에 연결됨으로써 콜이 완료된다. ANI는 자동 번호 식별(Automatic Number Identification)를 의미하는 업계에서 사용되는 표준 용어이다. ANI는 콜을 완료하기 위해 사용될 수 있다. 이것은 MCI 네트워크가 콜이 발신되는 것을 식별하기 위하여 LEC로부터 입력받는 정보이다. 간단하게, 만약 사용자가 콜을 발생시킨다면, 그 콜은 사용자의 집 전화번호가 된다. 그것은 카드 사용자가 콜을 발신하는 공중전화일수도 있으며, 그 콜에 대하여 요금을 지불할 사람을 결정하기 위해서만 사용되는 것은 아니다.
유사한 과정이, ISN(10480)을 통해 릴리스 링크 트렁크(10490)로 콜을 브리지하기 위하여 브리지 스위치(10440)을 이용하는 스위치(10460)에, LEC(10455)를 통한 전화기(10450)를 연결하는데 사용될 수도 있다.
도 74는 DAP 과정을 요청하는 고객측을 나타낸다. 가정 또는 규모가 작은 사무실 환경에서, 모뎀(10510), 전화기(10513), 및 팩스(10510)과 같은 디바이스들은 로컬 교환 캐리어에 연결되는 표준 RJ11 잭(10520)에 플러그 연결된다. 로컬 교환 캐리어(10525)는 공통 사무용 라인(10527)을 경유한 스위치(10530)에 연결한다. 대규모 사무실 환경에서, PBX(10540)가 장착된 사무소는 로컬 캐리어가 포함되지 않고도 전용 억세스 라인(DAL)(10547)을 경유하여 스위치(10530)에 연결될수 있다. 스위치(10530)는, 도 75에 상세하게 도시되는 바와같이, DAP(10560)로 DAL 절차 요청을 발행하고, DAP(10560)는 그 콜을 위한 루팅(10570)을 선택한다.
도 75는 요청자에 대한 "핫라인" 또는 특정 번호를 선택하기 위한 스위치(10530)의 동작을 나타낸다. 스위치(10530)는 인커밍 콜을 CBL(10527) 또는 DAL(10547)로 부터 받아들이고, 그 콜을 루팅하는 정보를 위해 DAP(10560)에 연결한다. DAP(10560)는 의사(pseudo)-전화번호의 형태로 인코딩된 루팅 정보를 리턴한다. 의사-전화번호는 정상적인 전화번호와 같은 형태를 나타내지만 원하는 착신 트렁크 그룹(TTG)을 식별하는 파일의 파일번호 및 3-디지트 스위치 식별기(SWID)를 엔코드한다. 스위치(10530)는 SWID에 의해 식별되는 스위치(10610)에 연결되어 파일번호를 전달한다. 스위치(10610)는 TTG를 사용하여 연결을 완성시키기 위한 적절한 모뎀풀(10620)을 선택한다. 그 모뎀풀은 인터넷 프로토콜(IP) 연결(10630)을 인증 서비스(10640) 같은 서비스들과 기본 인터넷 프로토콜 플랫폼(BIPP)(10650)에 교대로 연결시킨다. BIPP(10650)는 ATM 스위치 같은 패킷 스위치들로 구성되어, IP 패킷을 하나의 노드로부터 다른 노드로 전달한다. 인증 서비스(10640)는 요청측을 인증하기 위한 보안 기능을 선택적으로 수행하고 인터넷에서 승인되지 않은 억세스가 이루어지는 것을 방지한다. 또한 그것은, TTG 핫라인을 통해 인터넷을 억세스하는 사용자에 대하여 적절한 조정을 보장하기 위해 필요한 요금부과를 명확히 하는데 사용될 수도 있다. 이러한 핫라인 기능의 설비는 도 72에 도시된 FGD(10380)같은 비싼 FGD를 사용하지 않고, 스위치(10530)(10610)를 통해 콜을 루팅할 수 있게 한다.
도 76은 인터넷을 통해 전화번호를 선택적으로 루팅하는 게이트의 동작을 나타낸다. 터미널 스위치(10710)는 ARU(10720)과 연결되어 루팅 정보를 요청한다. ARU(10720)는 콜이 인터넷 루팅을 위한 후보인지를 결정하기 위하여 콜의 특성을 문의한다. 만약 그 콜이 모뎀 콜이라면, 그 콜은 모뎀풀(10730)로 루트된다. 모뎀풀(10730)로 부터, 그 콜은 베이직 인터넷 프로토콜 플랫폼(10750)으로 루트되어 인터넷 억세스를 그 모뎀 콜에 제공할 수도 있다. 그 모뎀 콜은 인증 서비스(10760)에 의해 선택적으로 인증된다. 만약 그 콜이 팩스 콜이라면, 그 콜은 포뎀풀(10730)로 루트된다. 모뎀풀(10730)로부터, 그 콜은 베이직 인터넷 프로토콜 플램폼(10750)으로 루트될 수 있고 그곳으로부터 팩스 게이트(10770)로 루트 될수 있다. 모뎀 콜처럼, 팩스 콜은 인증 서비스(10760)에 의해 선택적으로 인증된다.
만약 루트되는 그 콜이 보이스 콜이라면, ARU(10720)은 사용자가 콜 카드번호 및 착신 전화번호를 다이얼하는 것을 기다린다. ARU(10720)는 착신전화가 국제 콜인지 국내 콜인지를 결정하기 위하여 착신 번호를 문의한다. 국내콜은 등가(conventional) 루팅을 위한 착신 스위치(10710)로 리턴된다. 국제콜은 아날로그 보이스 신호를 코더/디코더(또는 코덱)(10725)로 공급함으로서 데이터로서 인코더된다. 코덱(10725)는 디지털 데이터로서 인코딩된 신호를 갖고 있으면서 그 콜을 모뎀풀(10730)을 통해 베이직 인터넷 프로토콜 플랫폼(10750)으로 루트한다.
다른 실시예에서, 콜이 네트워크 스위치에 의해 ISN으로 배달될 때, SS7 ISUP 메시지는 상주 ISN 스위치로 루트되며, 그 스위치는 DMS-ACD라고 한다. 여기서, ACD는 자동 콜 분배기(Auto Call Distributor)이다. ACD는 인커밍 SS7 ISUP 메시지를 입력받아 SCAI(스위치/컴퓨터 어플리케이션 인터페이스)로 전환한다. ACD의 반대쪽에는 ISN-AP(지능 서비스 망-부가 프로세서; Intelligent Service Network-Adjunct Processor)이라 불리는 디바이스가 있다. SCAI는 ACD와 ISN-AP 사이에서 사용되는 언어이다. 그러므로, 네트워크로부터 ACD SS7 ISUP로의 인바운드(inbound) 측, 그리고, ACD로부터 ISN-AP SCAI로의 아웃바운드(outbound)로의 두가지 인터페이스가 있다.
콜이 네트워크로부터 ACD에 도달하면, ACD는 자동으로 콜을 어디에 루트할 것인지를 알지는 못한다. ACD는 ISN-AP로부터 그 정보를 입력받는다. 이를 위하여, ACD는 네트워크로 부터의 ISUP 시그널링 파라미터들을 가지고, 그것들을 SCAI 프로토콜 포맷으로 전환하고, SCAI 메시지를 ISN-AP로 보낸다.
특히, SCAI 메시지는 'DV_Call_Received' 라고 부른다.(DV는 데이터/보이스(Data/Voice)를 의미함) ISN_AP가 이 메시지를 입력받을 때, 그것은 SCAI 메시지 내부의 요청측 번호(Called Party Number) 필드로 향하며, 그 번호를 근거로 ISN 내부에서 ACD가 콜을 루트하는 곳을 결정한다. ISN-AP가 결정을 할 때, 그 ISN-AP는 DV_Call_Received_RR을 만든다(이전 메시지 DV_Call_Received_RR의 응답은 리턴 결과를 의미한다). 그 RR 메시지가 내부에서는 어떤 콜이 착신되어야 하는 지에 대한 ACD 포트에 관한 ACD의 명령이다.
이러한 서비스를 위해, 그 ACD는 ARU(10720)에 연결된 ACD 포트로의 콜을 착신하도록 명령을 받는다. 그 콜이 ARU(10720)에 도착하면, 다음과 같은 두가지가 일어난다.
1) 만약 요청자가 a)전화기 또는 b)팩스기에서 엑세스 번호를 다이얼링했다면, 그 요청자는 "보이스의 경우 1을 누르고, 팩스의 경우 2를 누르시오"라고 말하는 보이스 프롬프트를 들을 것이다.
2) 만약 PC 모뎀을 사용하여 억세스번호를 다이얼링했다면, 그 요청자는 아마 어떤 멘트도 듣지 못할 것이다. 다음으로 일어날 일은 ARU 타이머가 끝난다는 것이다. 그 타이머의 종료는 콜이 모뎀으로부터 온 것임을 ARU에게 알린다.
이와같은 시나리오로 전개되는 콜은 혼동될수 있기 때문에, 한번에 하나씩 아래와 같이 고려한다.
만약, 요청자가 전화기로 콜을 했다면, ARU(10720)보이스 프롬프트에서, 요청자는 '1'(보이스 서비스를 위한)을 누를 것이다. 그때, ARU(10720)은 요청자에 대한 더 많은 정보를 얻을 것이다. 이러한 특징은 오늘날 전화회사가 제공하는 전화 카드 서비스의 변형된 형태이다. 그 ARU(10720)는 우선 카드번호를 취합하고, 요청자가 착신하고 싶어하는 번호를 취합한다. 이러한 정보를 취합하는 것이 끝난 후, ARU(10720)는 그 데이터를 ISN 근거로 통신망(LAN)을 통하여 인증 데이터 베이스로 보낸다. 더우기 그 전화카드번호를 검증하기 위해서, 그 데이터 베이스는 착신 번호가 카드 홀더에 대하여 허용된 다이얼링 계획 이내에 있는지를 보증한다.
카드 정보가 인증되면, ARU(10720)는 종료 번호가 국내인지 국제인지를 결정할 것이다. 만약 착신 번호가 국내이면, ARU(10720)는 그 콜을 ISN으로부터 보이스 네트워크로 릴리스할 것이며, 여기서, 보이스 네트워크에서 그 콜은 계획된 착신으로 루트될 것이다. 만약, 착신 번호가 국제이면, 그 콜은 BIPP 사이트의 코덱으로 루트될 것이다. 코덱의 목적은 보이스 신호를 데이터로 변환하여 UDP/IP를 사용하는 인터넷으로 루팅하는 것이다.
다른 실시예에서, 만약 요청자가 ARU(10720) 보이스 프롬프트의 팩스기로부터 콜을 했다면, 그 요청자는 팩스 서비스를 위한 요청을 나타내는 2번을 누를 것이다. 그때, ARU(10720)는 착신 팩스 번호가 가능하게 될 때까지 기다릴수 없는 사람이나 국제 팩스를 전달하는데에 도움이 필요한 사람을 위한 보증 팩스 서비스(10770)인 팩스 플랫폼에 루트할 것이다. 하나의 실시예는 요청자 및 착신 번호에 대한 정보를 모아서, 요청자에게 송신동작이 시작함을 알려준다. 팩스 서비스(10770)는 그 팩스를 취합하여 나중에 배달하기 위해서 저장한다.
만약 요청자가 PC 모뎀으로 다이얼링 했다면, ARU(10720) 보이스 프롬프트에서, 요청자는 어떤 멘트도 듣지 못할 것이다. 이것은 의도적이다. 요청자가 PC 스피커나 모뎀을 통해 ARU(10720) 멘트를 듣는 것은 가능하다. 그러나, 요청자는 ARU(10720)에 등록할수 없으며, 궁극적으로는 (위에서 언급한 바와같이) 이러한 콜이 PC 모뎀으로부터 발생되었다는 것을 나타내면서 타임-아웃될 것이다. ARU(10720)은 착신을 위한 네트워크로의 콜 백을 MCI의 BIPP(10750) 사이트들 중의 하나에서 모뎀풀(10730)로 릴리스할 것이다.
도 77은 중앙집중 구조로 배치된 도 76의 ARU의 동작을 나타낸다. 전화기(10810)은 로컬 교환기(10820)을 통해 스위치(10710)와 통신한다. 스위치(10710)는 브리지 스위치(10830)을 통해 지능 서비스 망(ISN)(10840) ARU(10720)를 연결한다. ARU(10720)은 모뎀풀(10730) 또는 코덱(10725)을 거친 BIPP(10750) 또는 팩스 서버로 루팅하는 그 콜을 조절한다.
도 78은 분산 구조로 배치된 도 77의 ARU의 동작을 나타낸다. 전화기(10910)는 로컬 교환기(10920)를 통해 스위치(10710)와 통신한다. 스위치(10710)은 브리지 스위치(10730)를 통해 지능 서비스 망(10840) ARU(10720)를 연결한다. ARU(10720)은 스위치(10911)와 브리지 스위치(10930)에 연결된 보이스 응답부(10950)의 제어하에 동작하여, 스위치(10910)를 거친 모뎀풀(10730), 또는 코덱으로 루팅하는 콜을 제어한다. ARU는 ISN 내부에 위치 해야 하지만, 다른 디바이스들(예를들어, ARU(10850)(10950), 모뎀풀(10730) 및 코덱(10725))은 네트워크의 어디에 위치해도 된다.
도 79A와 97B는 인터넷 콜 루팅을 위한 샘플 어플리케이션의 동작을 나타낸다. 도 79A는 고객 서비스를 위한 샘플 어플리케이션을 나타낸다. 인트라넷 컴퓨터(11010)는 위에서 설명한 인터넷(11020)에 연결함으로써 서버 컴퓨터(11025)에 연결한다. 서버 컴퓨터(11025)는 패킹 배달 서버 공급기(Packing Shipping Server Provider)(11030)등의 인터넷 자원의 지정을 통해 단일 자원 로케이터를 경유하여 인트라넷 검퓨터(11010) 사용자가 공급기(11030)를 쿼리하는 것을 허용한다. 11032로 도시되는 내부 기능을 통해 공급기(11030)는 사용자 대화에 응답하여 고객 서비스 부서로부터 전체 움직임 영상 디스플레이(11035)와 같은 자원들을 제공하거나, 또는 고객 서비스 대표(11037)에 서로 작용하는 대화를 제공한다.
도 79B는 요청자-가입 고객 트랜잭션(caller-initiated consumer transaction)을 위한 다양한 어플리케이션을 나타낸다. 기설정된 번호(11040)(555-IMCI, 555-PAGE, 또는 555-RNET)를 호출하는 고객은 공통 사무용 라인(CBL)(11050)을 사용함으로써 특정 트랜잭션 프로세서로 루트될 수 있다. CBL(11050)은 스위치(11060)에 연결된다. 스위치(11060)는 요청자 식별을 결정하기 위해 자동 번호 식별(ANI)를 사용하는 인커밍 콜을 분석하는 DAP(11065)를 콜 한다. 요청된 번호와 함께 요청자 식별을 근거로, DAP(11065)는 콜을 예를들어, 데이터 네트워크 인터페이스(DNI)(11070)등의 555-IMCI로 지정하기 위하여 스위치(11060)를 지정한다. DNI(11070)는 판매시점(point-of-sale) 장부 및 신용카드 트랜잭션을 처리할수 있는 데이터베이스 호스트(11075) 및 스위치 네트워크 사이에서 인터페이스로서 작용한다. 타겟 전화번호에 기초한 콜을 루팅하는것에 부가하여, ANI 데이터는 요청자가 데이터베이스 호스트(11075)를 식별하는데 사용된다. 이와 유사하게, 555-PAGE 콜은 패이징 서비스 회사(11080)의 PBX로 루트될 수 있으며, ANI 데이터는 회사에서 제공하는 특정 페이징 서비스(11085)를 선택하기 위하여 사용된다. 결국, 555-RNET 콜은 앞서 설명한 바와같이 기본 인터넷 프로토콜 플랫폼(11090)의 연결을 제공하기 위하여 사용될 수 있다.
도 80은 바람직한 실시예에 따른 서비스 제공자로의 상호연결 뿐만 아니라, 보이스 메일 및 보이스 응답부 서비스를 제공하는 스위칭 네트워크의 구성을 나타낸다. 전화기(11111)(11112)는 각기 스위치(11120)(11121)을 경유하여 네트워크로 들어가며, 전화기(11112)로의 네트워크 기입을 제공하는 것에 더하여, 스위치(11121)는 스위치(11120)을 위한 중간 라인을 제공한다. 스위치(11125)는 PBX(11130)과 같은 직접 입력을 입력받을 뿐만 아니라 스위치(11121)와 상호연결된다. 스위치(11125)는 보이스 응답부 서버(11140)와 보이스 메일 서버(11145)를 연결시킨다. 이에 더하여, 스위치(11125)는 다이얼 억세스 라인(11155)를 통해 서비스 제공자 서버(11150)를 연결한다. 더우기, 서비스 제공자 서버(11150)는 요구되는 서비스 및 인증에 따라 인커밍 콜을 페이징 서비스(11060) 또는 모뎀풀(11076)을 통하여 연결되는 BIPP(11075)를 사용하여 이메일 서비스(11070)에 루트한다.
B. 다른 실시예
도 81은 바람직한 실시예에 따른 데이터베이스를 통해 공유하는 데이터와 자동 콜 분배기(Automated Call Distributed; ACD) 콜을 공유하는 인바운드를 나타낸다. 전화회선을 이용한 인터넷 사용자(12000)는 컴퓨터 모뎀을 사용하여 전화번호를 다이얼링한다. 전화번호는 RBOC/LEC 스위치(12002)로부터 MCI 스위치 1(12004)로 루트된다. MCI 스위치 1(12004)는 다이얼링된 전화번호 및 주어진 ANI를 위한 루트를 요청하기 위하여 네트워크 제어 시스템(NCS)(12020)을 쿼리한다. NCS(12020)은 MCI 스위치 1(12004)가 콜을 MCI 스위치 2(12006)의 트렁크 그룹에 루트하도록 지시하는 착신 어드레스를 리턴한다.
MCI스위치 2인 12006은 인터넷 엑세스 소자 12008로의 호출을 완료한다. 다이얼 업 사용자 컴퓨터 12000와 인터넷 엑세스 소자 12008의 모뎀은 데이터 소집을 시작하고, 데이터 패킷은 포인트 투 포인트 프로토통화(PPP)에 따라 교환된다. 인터넷 엑세스 소자 12008로부터 PPP패킷은 인터넷 프로토통화(IP)로 변환되어 인터넷상으로 12026으로 표현되어 전송된다. 비슷하게, 인터넷 엑세스 소자12008은 인터넷 12026 으로부터 IP패킷을 받아서 다이얼 업 사용자 12000에게 이를 송신한다.
패킷이 인터넷 엑세스 소자 12008를 통해 자유로이 통과하도록 허용되기 전에, 다이얼 업 사용자 12000는 인증된다. 이는 사용자이름/패스워드 방법 또는 시도/응답 방법을 사용하여 이루어진다.
사용자이름/패스워드 방법에서, 인터넷 엑세스 소자 12008은 다이얼 업 사용자를 프롬트하여 사용자이름으로 접속하게한다. 다이얼 업 사용자 12000은 컴퓨터로 사용자 이름을 입력하고, 사용자 이름은 다이얼 업 사용자 12000으로부터 디바이스 12008까지 전송된다. 인터넷 엑세스 소자 12008은 그때 다이얼 업 사용자 12000을 프롬트하여 패스워드를 접속한다. 다이얼 업 사용자 12000은 패스워드를 컴퓨터로 입력하여 패스워드는 다이얼 업 사용자 12000으로부터 인터넷 엑세스 소자 12008까지 전송된다. 일단 사용자 이름과 패스워드가 수신되면 인터넷 엑세스 소자 12008은 사용자 이름과 패스워드가 포함된 확인요청을 확인 서버 12014로 보낸다. 확인서버 12014는 유효한 사용자이름/패스워드 쌍의 데이터베이스에 대해 사용자 이름과 패스워드를 체크한다. 입력된 사용자이름/패스워드가 데이터베이스에 있으면 확인서버 12014는 인터넷 엑세스 소자 12014로 다시 "사용자확인"메세지를 보낸다. 입력된 사용자이름/패스워드가 데이터베이스에 없으면 확인 서버 12014는 인터넷 엑세스 소자 12008로 다시 "사용자 확인안됨"이라는 메시지를 보낸다.
시도/응답 방법에서, 인터넷 엑세스 소자 12008은 다이얼 업 사용자 12000를 프롬트하여 사용자이름을 입력한다. 다이얼 업 사용자 12000은 컴퓨터에 사용자이름을 입력하고, 사용자 이름은 다이얼 업 사용자 12000으로부터 인터넷 접속소자 12008로 전송된다. 인터넷 엑세스 소자 12008은 그때 시도로서 다이얼 업 사용자 12000을 프롬트한다. 다이얼 업 사용자 12000은 시도 디지트(DIGITS)를 입력하고 비밀키를 응답발생 프로그램에 입력함으로써 시도에 대한 응답을 계산한다.
공유비밀키이는 다이얼 업 사용자 12000과 확인서버 12014에만 알려져있다. 다이얼 업 사용자 12000은 계산된 응답으로 입력하여 그 응답은 다이얼 업 사용자 12000으로부터 인터넷 엑세스 소자 12008까지 전송된다. 인터넷 엑세스 소자 12008은 사용자이름, 시도와 응답을 포함하는 확인메세지를 확인 서버12014에 전송한다. 확인서버는 사용자이름을 읽고 사용자이름에 대한 공유비밀키이를 찾으며 응답을 계산하기위해 공유비밀키이와 시도 디지트를 사용한다. 계산된 응답은 다이얼 업 사용자 12000에의해 주어진 응답과 비교된다. 응답이 일치하면 "사용자 확인됨" 이라는 메시지가 확인서버로 12014로부터 인터넷 엑세스 소자12008까지 보내진다. 응답이 일치하지 않으면 "사용자 확인안됨" 이라는 메시지가 확인서버로 12014로부터 인터넷 엑세스 소자12008까지 보내진다.
사용자이름/패스워드 또는 시도/응답방법이 확인에 사용되면, 본 설명의 나머지는 "사용자 확인됨" 이라는 메시지가 확인서버로 12014로부터 인터넷 엑세스 소자12008까지 보내지고 IP패킷 통신이 인터넷 엑세스소자 12008을 거쳐 자유로이 흐를수 있다는 것을 가정한다.
다이얼 업 사용자 12000은 웹브라우저를 시작하여 통합웹서버 12024로부터 웹 페이지를 브라우저한다. 통합웹서버 12024는 통화센터서버 12028에서 다이얼 업 사용자 12000에의해 조사된 웹 페이지를 균일 탐색자를 사용하여 기록한다. 다이얼 업 사용자 12000은 하이퍼텍스트 마크업 언어(HTML)형태를 파일링함으로써 통합웹서버 12024에 정보를 전달하게 된다. 통합웹서버 12024는 같은 균일탐색자를 사용하여 통화센터서버에 이 정보를 저장한다.
다이얼 업 사용자 12000은 다른 웹페이지를 브라우저하고, 한 아이콘이 텍스트표시에 따라 디스플레이되어 사용자는 그 아이콘을 클럭함으로써 대리인에게 이야기할수 있다. 아이콘의 클럭은 통합웹서버 12024로부터 다이얼 업 사용자의 12000웹브라우저까지 다중 인터넷 메일 확장(MIME)의 다운로드를 가져온다. MIME파일은 결과적인 폰통화에 대한 목적지를 표시하면서, 사용자 인식기라고하는 알파벳과 숫자로된 스트링을 포함한다. 브라우저는 지정된 MIME형태의 파일을 취급하기 위해 브라우저 플러그인 또는 도움자 적용을 유도한다. 도움자 적용은 MIME파일을 읽고 다이얼 업 사용자 12000으로부터 디렉토리 서버 12012까지 MIME파일 내용에 물음표를 인가한다. 디렉토리 서버 12012는 MIME파일로부터 알파뉴메릭 스트링을 목적지 인터넷 텔레포니 게이트웨이 12018의 목적지 IP어드레스로 번역하고 IP어드레스를 포함하는 한 메시지를 다이얼 업 사용자의 12000 도움자 적용으로 전송한다. 도움자적용은 그때 인터넷 텔레포니 통화을 인터넷 텔레포니 게이트웨이의 12018 IP어드레스에 인가하고 인터넷 텔레포니 게이트웨이 12018에 MIME파일로부터의 알파뉴메릭 스트링을 통화셋업의 한 부분으로서 제공한다.
인터넷 텔레포니 게이트웨이 12018은 주어진 알파뉴메릭 스트링을 목적지 텔레폰번호로 번역하고 텔레폰 네트워크 인터페이스의 목적지 텔레폰번호를 MCI스위치 12006으로 다이얼한다. MCI스위치 2인 12006은 수행지시를 요구하면서 걸린 전화번호로 NCS 12020을 묻는다. NCS 12020은 적절한 루트를 결정하고 수행지시를 MCI스위치2인 12006으로 돌려보내 MCI 스위치 1인 12004의 특정 트렁크 그룹으로 통화을 수행한다. 통화은 MCI스위치1인 12004로 추적되고 그때 통화은 자동통화분배기(ACD) 12022에 완료된다. ACD 122가 통화에 응답할 때 인터넷 텔레포니 게이트웨이 12018은 ACD 12022와 다이얼 업 사용자 12000사이의 일정오디오 경로를 완료하는데, ACD로부터 PCM오디오로 회로 스위치된 인터넷 텔레포니 게이트웨이까지를 가지며 인터넷 텔레포니 게이트로부터 다이얼 업 사용자까지의 오디오는 오디오코드를 사용하여 디지털 오디오로 엔코드되어 패킷화된다.
통화이 ACD 12022에 전달될 때, 유일기록식별기는 텔레폰 네트워크 시그날 매커니즘을 경유하여 ACD로 전달된다. 통화센터 12026의 대리인이 통화을 받을 때 유일기록식별기는 대리인을 위해 표시되고, 다이얼 업 사용자 12000에의해 접속된 통화정보는 통화센터서버12028로부터 회수된다.
XXL. 요금청구
본발명에 따르는 다른구현은 일반적으로 텔레커뮤니케이션 네트워크에 관련되는데 특히, 유연하고 확장가능한 기록포맷을 사용하여 통화기록을 발생하고 네트워크를 통과하는 각 텔레폰통화에 대한 유일 통화식별기를 발생하는 텔레커뮤니케이션 네트워크의 스위치에 관한 것이다.
전형적인 텔레커뮤니케이션 네트워크는 지정학정 영역을 통해 위치한 다중 텔레커뮤니케이션 스위치들로 구성된다. 사용자가 통화을 할 때 통화은 그 목적지에 도달하기전에 하나 또는 그 이상의 스위치를 통해 수행된다.
FIG 82는 미국을 통과하는 예시의 통신 시스템을 설명한다. 설명의 목적을 위해, 통화하는 사람 30124은 캘리포니아주 로스앤젤레스로부터 뉴욕시티에 위치한 지역까지 통화을 한다. 그러한 통화은 전형적으로 3개의 스위치를 통해 전송된다. : 로스앤잴레스, 스위치 30106 : 시카고, 스위치 30108 : 뉴욕, 스위치 30110 : 이러한 시나리오에서 시작스위치는 로스앤젤레스의 30106이고 끝스위치는 뉴욕스위치 30110이다.
각각의 스위치, 30106-30110, 는 두 개 또는 그 이상의 데이터 억세스 포인트(DAP) 30116-30120 DP 연결된다. 에를 들어 초기 DAP 30116과 백업DAP 30116-30120 과 같은 것이다. DAP 30116-30120은 스위치 30106-30110으로부터 정보요청을 받아 요청한 정보를 요청스위치 30106-30110으로 다시 리턴한다. 스위치 30106-30110은 네트워크를 통하여 통화을 처리하기위해 DAP 30116-30120으로부터 정보를 사용한다.
통화이 스위치들 30106-30110중 하나를 통과할 때, 그 스위치는 통화 기록을 만들어낸다. 통화기록은 루팅(routing), 빌링(billing), 통화특성, 문제해결정보를 포함하는 통화정보를 가진다. 통화이 종료한후 통화을 처리한 각 스위치 30106-30110는 관련된 통화기록을 완료한다. 스위치 30106-30110은 빌링블럭으로 여러통화기록들을 결합한다.
스위치 30106-30110이 빌링블럭을 채울 때, 스위치 30106-30110은 빌링센터로 빌링블럭을 보낸다. 그리하여 빌링센터 30114는 통화을 취급한 각각의 스위치 30106-30110으로부터 하나의 빌링블럭을 수신하는데 이러한 경우는 3개의 빌링블럭이 된다. 빌링센터 30114는 각 빌링블럭을 서치하고 통화에 관련된 통화기록을 회수하여 통화을 취급한 스위치 30106-30110당 하나의 통화기록을 회수한다. 빌링센터 30114는 그때 빌링접속을 발생하기위해 회수된 통화기록들중 하나 또는 그이상의 것들을 사용한다. 빌링센터 30114는 또한 스위치 30106-30110 또는 통화기록관련 정보를 회수하기위해 각각의 DAP에 연결된다.
본발명을 더 잘 이해하기위해 통신 네트워크에 관련된 추가적인 용어를 설명하는 것이 유익하다.
전화는 시작포트 또는 트렁크로 참조되는 송신라인상에 한 스위치로 온다. 이러한 포트그룹은 시작포트그룹이다. 시작포트는 원위치로부터 스위치로 들어오는 많은 송신라인들중 하나이다. 입력통화을 처리한후 스위치는 목적지에 통화을 보내는데 이는 다른 스위치, 국부교환캐리어 또는 개개의 브랜치교환이 된다. 통화은 종료포트 또는 트렁크로 참조되는 송신라인으로 전송된다. 시작포트와 비슷하게 종료포트는 스위치로부터 같은 목적지로 가는 포트그룹중 하나이다. 이러한 포트그룹은 종료포트그룹이다.
현대의 통신네트워크는 고객실질네트워크(VNet)를 정의하는 시설 뿐만 아니라 일반공중네트워크를 사용하는 시설을 고객에게 제공한다. VNet로서 고객은 개개의 다이얼링계획, 계획전화번호를 정의한다. VNet고객은 특정지역으로 헌정된 공중통신 시스템에 할당된 누락전화번호에 제한되지 않고 고객전화번호를 정의할 수 있다.
전화통화을 처리하면서 스위치는 통화상의 필요한 정보를 모두 포함할수 있도록 충분한 크기의통화기록을 발생시켜야 한다. 그러나 통화기록은 일반적인 통화이 사용되지 않는 통화기록에 대다수의 레코드필드가 되지 않도록 너무 크서는 안된다. 그러한 경우에 그런 통화 기록들을 저장하는 것은 저장을 낭비하게 되고 불필요한 송신을 일으키는 통화기록을 송신하게 된다.
통화기록들을 만들고 처리하는 하나의 해결은 32단어 통화기록과 같은 고정된 길이 통화기록포맷을 적용하는 것이다. 한 단어는 2바이트 또는 16비트이다. 그러나 고정길이 기록포맷은 새로운 통화특성이 추가될때는 확장될수 없다. 더욱 중요한 것은 고정된 통화기록 포맷은 통신네트워크가 새로운 특성과 전화번호로 복잡해짐에 따라 확장된 데이터 필드를 취급할수 없다는 것이다.
현대의 고정길이 기록포맷은 시간필드를 포함하는데 3초간격으로 로컬시간을 기록하며 로컬스위치 시간은 스위치에서 그날의 시간을 나타낸다.
시간필드는 네트워크 스위치, 빌링센터 와 다른 네트워크 서브시스템에의해 사용되어 진다. 그러나 각 서브시스템은 포맷의 시대시간과 같은 다른용도와 다른포맷의 시간간격을 요구한다. 시대시간은 역사상 특정일과 시간후 1초 증가한 번호이다. 예를 들어 빌링센터는 빌릴기록에 대해 시대시간을 요구하고 스위치보고와 에러로그는 국부스위치시간을 요구한다.
서머타임과 같은것에 기인해 시간변화에 대한 고려가 없는 국부스위치 시간을 사용할 때 문제가 발생한다. 그외에, 각각의 서브시스템은 현재의 3초증가보다 정확한 세부사항을 요구한다. 3초증가에서 오직 국부스위치 시간을 제공함으로써, 스위치들은 시간을 네트워크 서브시스템의 사용 포맷으로 번역하는 짐을 벗어버렸다. 고정기록포맷은 여러 시간구간 요구를 충족할수 없는데 이는 낮은 정확도의 국부스위치 시간에서의 시간구간을 포함하기 때문이다. 고정된 특성 때문에 고정기록포맷은 다른시간포맷이나 1초증가와 같은 정확도의 세부사항을 포함하여 확장할수 없다.
그러므로 유연하고 확장가능한 포맷으로 통화기록 정보를 저장하는 통신네트워크의 스위치가 필요하다. 서머타임이나 시간구역변화에 쉽게 응답하는 유연한 포맷의 1초단위를 가진 시간포인트를 제공하는 추가 필요성이 있다.
또한, 특정 전화통화에 관련한 통화기록들에 모두 대응시킬수 있는 것이 필요하다. 예를 들어 적절한 빌링과 비용조절을 위해 빌링센터는 시작스위치 통화 기록을 종료스위치 통화 기록에 맞추는 것이 필요하다. 또한 문제해결과 비밀목적으로, 용이하게 문제영역을 차단하도록 전화통화을 네트워크를 통해 추적하는 것이 필요하다.
그러므로, 네트워크를 통과하는 각각의 전화통화을 균일하게 식별하는 통신네트워크의 스위치와 특정 전화통화과 관련된 모든 통화기록을 식별하는 것이 필요하다.
A. 구현
1. 통화 기록 포맷
본 구현은 작고 큰 통화기록 포맷을 구현함으로써 유연하고 확장가능한 통화기록 포맷을 제공하는 문제를 해결한다. 특히 본 구현은 디폴트 32워드 통화기록 포맷과 확장된 64워드 통화기록을 구현한다.
본 구현은 전화통화의 대다수를 이루는 전형적인 전화통화에 대한 32워드통화 기록을 사용하고 통화관련 추가적인 정보가 필요할 때 64워드 통화기록 포맷을 사용한다. 이러한 구현은 주어진 통화기록의 데이터 요구를 변화시킴으로써 효율적으로 운영하는데 필요한 유연성을 제공한다.
이 구현은 또한 시대시간포맷의 시간점을 기록한다. 본 구현은 시대시간포맷의 기원시간을 기록하고 남은 시간점은 오프셋되거나 기원시간으로부터 초단위 숫자가된다. 본 구현은 서머타임시간으로부터 또는 서머타임시간으로 변환하는데 관련된 문제를 해결하는데 이는 서머타임이 국부타임 ??셋이고 시대시간에 영향을 끼치지 않기 때문이다. 더욱이 시대시간 포맷에서 시간점은 국부스위치 시간포맷보다 통화기록에서 보다 적은 공간을 요구한다.
시대시간포맷은 영국 그리니치에서 결정된 조정된 세계시간(UTC)을 나타내는데 이는 제로(0)국부스위치시간 또는 다른시간의 시간영역을 가진다. 시대시간은 오직 하나의 포맷이고 UTC가 반드시 사용되어져야 한다는 것을 지시하지는 않는다. 빌링시간과 국부스위치시간은 UTC 또는 국부시간이 되고 국부스위치시간은 빌링에 사용된 같은 시간이 될 필요는 없다. 그러므로 스위치는 서머타임이 변화하는동안 일어나는 문제를 막기위해 빌링시간과 국부스위치 시간을 분리시켜 유지한다.
2. 네트워크 통화 식별기
본 구현은 각각의 통화기록에 유일한 식별기를 제공함으로써, 특정전화번호에 관련한 모든 통화기록과 각각의 전화번호를 유일하게 식별하는 문제를 해결한다. 통화원점에서 각각의 통화기록에 할당된 네트워크 통화식별기를 발생한다. 즉, 원스위치는 각각의 전화번호에 대해 NCID를 발생한다. NCID는 종료스위치에서 종료점에 통신네트워크를 통하여 관련전화번호를 수반한다. 그러므로, 네트워크에서 전화통화의 어떤점에서 관련 NCID는 전화통화의 원점과 시간을 식별한다. 전화통화이 통과하는 각각의 스위치는 통화에 관련된 통화기록에서 NCID를 기록한다. NCID는 32단어 통화기록에 맞을만큼 작아서 데이터 생산과 저장을 감소시킨다. NCID는 특정전화번호에 통화기록을 시작하고 끝낼수 있는 빌링센터와 다른네트워크 서브시스템을 제공한다.
본 구현은 또한 수신된 NCID를 버리고 새로운 NCID를 발생하는 스위치를 제공한다. NCID포맷이 유효하지 않거나 신뢰성이 없으면 수신된 NCID를 버려 네트워크를 통하여 가는 각 통화에 관련된 유효한 유일한 식별기를 확실히 한다. 예를들어 NCID는 제 3스위치에의해 발생되면 신뢰성이 없다.
본구현은 유연하고 확장가능한 기록포맷을 사용하여 통화기록을 발생하는 송신네트워크의 스위치에 관한 것이다. 통화기록포맷은 작고(32워드) 큰(64워드) 확장된 포맷을 포함한다. 관련분야의 전문가에게는 서로다른 사이즈의 작고 큰 기록포맷을 구현하는 것은 명백하다.
본 구현은 또한 네트워크를 통과하는 각전화통화에 대해 유일한 NCID를 발생하는 송신 네트워크의 스위치에 관한 것이다. NCID는 특정전화통화에 관련된 모든 통화기록들을 매치시키는 매커니즘을 제공한다. 관련분야의 전문가에게는 서로다른 포맷의 통화기록식별기를 구현하는 것은 명백하다.
선택된 구현은 컴퓨터 시스템내에서 수행하는 컴퓨터 소프트웨어이다. FIG 83은 컴퓨터 시스템의 한 예를 보여준다. 컴퓨터 시스템 30202는 프로세서 30204와 같은 하나 또는 그이상의 프로세서를 가진다. 프로세서 30204는 통신버스 30206에 연결되어 있다.
컴퓨터시스템 30202는 또한 주메모리 30208, 램(RAM), 2차 메모리 30210을 포함한다. 예를들어 2차 메모리 30210은 플로피 디스크 드라이버, 마그네틱 테이프 드라이브, 컴팩트 디스크 드라이브를 나타내어 하드 디스크 드라이브30212 와/또는 삭제가능한 저장 드라이브30214를 포함한다. 삭제가능한 저장 드라이브 30214는 잘 알려진 방법으로 삭제가능한 저장 유닛 30216으로부터/으로 읽고 쓰기가 가능하다.
삭제가능한 저장유닛 30216은 또한 프로그램 저장 디바이스 또는 컴퓨터 프로그램 제품이라고 불리며 플로피 디스크, 마그네틱 테이프, 컴팩트 디스크 등을 나타낸다. 삭제가능한 저장유닛 30216은 저장된 컴퓨터 소프트웨어 와/또는 데이터를 가지는 컴퓨터 사용 저장미디엄을 포함한다.
컴퓨터 프로그램(또한 컴퓨터 조정로직으로 불림)은 메인 메모리30208과/또는 2차메모리 30210에 저장된다. 그러한 컴퓨터 프로그램은 수행될 때 컴퓨터 시스템 30202를 구동하여 본 발명의 작용을 수행한다. 특히 컴퓨터 프로그램은 수행될 때 프로세서 30204를 구동하여 본 발명의 작용을 수행한다. 따라서, 그러한 컴퓨터 프로그램은 컴퓨터시스템 30202의 조정기를 나타낸다.
B. [ 다른 구현 ]
다른 구현으로는 조정로직(컴퓨터 소프트웨어)이 저장된 컴퓨터 읽기 매체로 구성된 컴퓨터 프로그램 매체이다. 조정로직은 프로세서 30204에 의해 수행될 때 프로세서 30204를 여기에 설명된대로의 기능을 수행하도록 한다.
또 다른 구현은 예를 들어 하드웨어 상태기계를 사용하여 하드웨어에서 초기에 적용된다. 하드웨어 상태기계의 적용은 관련분야의 전문가에게는 자명하다.
1. 통화 기록 포맷
본 구현은 9개의 서로다른 기록포맷을 가진 송신 네트워크의 스위치를 제공한다. 이 기록들은 다음을 포함한다. : 통화 디테일 레코드(CDR), 확장 통화 디테일 레코드(EDCR), 프라이빗 네트워크 레코드(PNR), 확장 프라이빗 네트워크 레코드(EPNR), 오퍼레이터 서비스 레코드(OSR), 확장 오퍼레이터 서비스 레코드(EOSR), 프라이빗 오퍼레이터 서비스 레코드(POSR), 확장 프라이빗 오퍼레이터 서비스 레코드(EPOSR), 스위치이벤트 레코드(SER), 각각의 레코드는 길이가 32워드이고 확장버젼은 64워드이다.
여기에 설명된 9개의 통화 레코드 포맷에 대한 예시가 FIG 82-86에 나타나 있다. 본 발명의 통화기록의 구현은 32워드와 64워드 통화기록 포맷으로 구성된다. 관련분야의 전문가에게는 다른숫자의 워드와 다른 필드정의로 구성하는 통화레코드의 다른구현을 만들어 내는 것은 용이하다. 첨부의 테이블 301은 CDR과 PNR 통화기록 포맷의 한 예시를 포함한다. FIG84는 CDR과 PNR 통화기록 포맷의 그래픽 표현을 보여준다. 첨부의 테이블 302는 EDCR과 EPNR 통화기록 포맷의 한 예시를 포함한다. FIG 85A와 85B는 EDCR과 EPNR의 통화기록 포맷의 그래픽 표현을 보여준다. 첨부의 테이블 303은 OSR과 POSR통화 기록 포맷의 한 예시를 보여준다. FIG 86은 OSR과 POSR 통화기록 포맷의 그래픽 표현을 보여준다. 첨부의 테이블 304는 EOSR과 EPOSR통화기록포맷의 한 예시를 포함한다. FIG 87(A)와 87(B)는 EOSR과 EPOSR통화기록 포맷의 그래픽 표현을 보여준다. 첨부의 테이블 305는 SER기록포맷의 한 예시를 포함한다. FIG 88은 SER기록 포맷의 그래픽 표현을 보여준다.
CDR, PNR, EDCR 과 EPNR은 표준 통화기록포맷이며, 스위치를 통과할 때 전형적인 전화 통화을 고려하여 정보를 포함한다. CDR은 VNET가 아닌 고객을 위해 사용되고 PNR은 VNET고객을 위해 사용되어 VNET통화을 원천으로 하는 스위치에서 발생된다. 이 두 기록필드는 아래 설명되는 일부의 필드 특정정보를 제외하고는 동일하다.
OSR, POSR, EOSR과 EPOSR은 오퍼레이터 도움을 요구하는 전화통화에 관련된 정보를 포함하고 오퍼레이터 위치에서 실지로 구비한 스위치 또는 시스템에서 발생한다. 스위치는 VNET가 아닌 고객에게는 OSR을 수행하고 사적인 VNET고객에게는 POSR을 수행한다. 이러한 기록들은 네트워크 오디오 시스템(NARS)기능이나 오퍼레이터 서비스를 수행하는 기능을 가지는 시스템 또는 스위치에서 발생한다. 2개의 기록포맷은 아래에 설명된 필드특정정보를 제외하고는 동일하다.
SER은 각각의 시간표시통과, 시간변화, 시스템 수신기와 같은 사건들 그리고 빌링블럭의 끝에서 보존된다. SER기록포맷은 또한 아래에 상세히 설명된다.
FIG 89(A),(B)는 기록포맷의 확장포맷을 언제 사용할지를 결정하기위해 스위치가 사용하는 로직을 공동으로 설명한다. 통화 30202는 스위치 30106-30110으로 와서(참조목적으로 현재스위치라고 함: 현재 스위치는 통화을 현재 처리하는 스위치이다), 스위치 30106-30110은 통화의 30802 통화기록을 위해 어떤 통화기록과 통화기록포맷(작은/디폴트 혹은 큰/확장자)을 사용할지를 기록한다. 이러한 관점에서 스위치 30106-30110은 수신하는 각 통화30802에 대해 9번 채크한다.스위치 30106-30110은 체크의 어떤조합을 통과하는 통화 30802뿐만아니라 어떤 체크를 통과시키는 통화 30802애 대해 확장레코드를 사용한다.
첫째 체크 30804는 현재스위치 30106-30110에서 통화이 직접종료 오버플로우(DTO)에 관련되어 있는지를 결정한다. 예를 들어 DTO는 고객이 30800번호로 전화통화 30802를 할 때와 800번호의 원위치가 통화중일 때 발생한다. 원위치가 통화중이면 전화통화 30802를 새로운 위치로 오버플로우한다.
이러한 경우, 스위치는 원래 시도된 목적지, 전화통화 30802의 최종 목적지, 오버플로우의 횟수를 기록해야 한다. 그러므로, 통화 30802가 DTO에 포함되면 스위치 30106-30110은 확장기록(EDCR,EPNR,EOSR,EPOSR)30816을 완료해야 한다.
두 번째 체크 30806은 스위치 30106-30110이 통화 30802의 통화링지역이 10디지트보다 큰지를 결정함으로써 통화 30802를 한다. 통화링위치는 통화 30802가 위치한곳으로부터 위치의 전하번호이다. 그러한 예는 마지막 11디지트로 구성하는 국제통화이다. 통화링위치가 10디지트보다 크면 스위치는 확장레코드 (EDCR,EPNR,EOSR,EPOSR) 30816에서 통화링위치의 전화번호를 기록한다.
스위치 30106-30110은 지정 어드레스가 17디지트보다 큰지를 결정하기 위해 통화 30802로 3번째 체크 30808을 한다. 지정 어드레스는 통화 위치번호이고 전화번호 또는 트렁크 그룹이 된다. 지정이 17디지트보다 크면 스위치는 확장기록(EDCR, EPNR, EOSR, EPOSR) 30816에 지정을 기록한다.
스위치 30106-30110은 기 번역된 디지트 필드가 구동지원된 서비스 통화에 사용되는지를 결정하기 위해 통화 30802에 4번째 체크를 행한다. 기 번역된 디지트는, 통화 30202가 네트워크 내에서 다른번호로 번역되어져야 한다면, 송화자에 의해 걸려진 통화 30802 번호이다. 그러므로 송화자가 오퍼레이터 서비스를 사용할 때 스위치 30106-30110은 확장기록(EOSR,EPOSR) 30816에 걸려진 번호를 기록한다.
통화 30802의 5번째 30812에서, 스위치 30106-30110은 오퍼레이터 지원없이 송화자에 의해 걸려진 통화 30802의 기 번역된 디지트가 10개이상의 디지트를 가진지를 결정한다. 10개 이상의 디지트를 가지면 스위치 30106-30110은 확장기록(EDCR,EPNR)에서 걸려진 번호를 기록한다.
통화 30802의 6번째 체크30814에서, 스위치 30106-30110은 추가데이터를 포함하여 22디지트 이상이 통화기록의 확인코드필드에 기록되어 있는지를 결정한다. 확인코드는 통화링지역 또는 신용카드통화과 같은 통화에 대한 요금청구를 받는 대상을 지시한다. 데이터 입력이 22디지트 이상을 요구하면 스위치 30106-30110은 확장레코드(EDCR, EPNR, EOSR, EPOSR)30816에서의 요금정보를 기록한다.
통화 30802에서의7번째 체크에서, 스위치 30106-30110은 통화30802가 와이드밴드 통화인지를 결정한다. 와이드밴드통화은 다중전송선 또는 채널을 요구하는 것이다. 예를들어, 전형적인 비디오통화은 6개의 전송채널을 요구하는데, 음성을 위한 하나와 영상전송을 위한 하나이다. 와이드밴드통화 동안에 사용된 더많은 전송채널은 보다낳은 수신이 된다. 현재 동시전송시스템은 24채널까지 제공한다. 그러므로 와이드밴드통화 동안에 사용되어지는 24채널중 어느것을 또 얼마나 많이를 표시하기위해 스위치는 확장레코드(ECDR,EPNR) 30828에서의 채널정보를 기록한다.
통화 30802의 8번째 체크30822에서, 스위치 30106-30110은 시간과 부과특성이 오퍼레이터에 의해 사용되었는지를 결정한다. 시간과 부과특성은 호텔투숙객이 오퍼레이터의 도움으로 전화를 하고 통화 30802로 부과할 때 보통 사용되어진다. 통화 30802가 완료되면 오퍼레이터는 투숙객에게 통화 30802에 대한 요금 및 비용을 부과한다. 시간과 부과특성이 통화 30802에 사용되어졌으면 스위치 30106-30110은 확장레코드(EOSR,EPOSR) 30832에서 투숙객의 이름과 방번호를 기록한다.
스위치 30106-30110에 의해 통화 30802로된 9번째의 마지작 체크는 통화 30802가 개량된 음성서비스네트워크 오디오응답시스템(EVS/NARS)인지를 결정한다. EVS/NARS는 사용자의 전화키패드를 경유하여 자동메뉴에 따라 고객이 선택한 음성메뉴시스템이다. 그러한 시스템은 오디오메뉴시스템이 가진 NARS 스위치를 포함한다. 그러므로, EVS/NARS 통화동안에 NARS스위치 30106-30110은 확장레코드(EOSR, EPOSR) 30832의 메뉴선택을 기록한다.
체크30804-30824중 어느것도 바람직한 결과가 되지 않으면, 그때 스위치 30106-30110은 디폴트기록포맷(OSR,POSR) 30830을 사용한다. 일단 체크가 통하에 되었으면, 스위치는 적절한 통화기록을 발생하고 완료한다. 통화기록 데이터는 2진형태와 전화2진코드데시말(TBCD) 포맷으로 기록된다. TBCD포맷은 아래에 설명된다.
0000=TBCD-Null
0001=digit 1
0010=digit 2
0011=digit 3
0100=digit 4
0101=digit 5
0110=digit 6
0111=digit 7
1000=digit 8
1001=digit 9
1011=special digit 1 (DTMF digit A)
1100=special digit 2 (DTMF digit B)
1101=special digit 3 (DTMF digit C)
1110=special digit 4 (DTMF digit D)
1111=special digit 5 (Not Used)
모든 디지트 필드는 데이터가 기록되기전에 TBCD-null 또는 0으로 채워져야한다.
적용될 때 다이얼된 디지트포맷은 이러한 약속에 따른다.
N=digits 2-9
X=digits 0-9
Y=digits 2-8
따라서 통화레코드 필드에 대한 상세사항에 N을 포함하면 유효한 필드값은 디지트 2-9이다.
SER을 제외하고 각각의 통화기록은 특정한 통화시간필드를 포함한다. 시간필드는 시대시간포맷에 기록된다. 시대시간은 역사상 특정한 날짜/시간으로부터 하나의 두 번째 증가값이다. 본 발명의 구현은 1976년 1월1일에 자정(UTC 0시)일/시간을 사용하지만 이는 하나의 예이고 제한은 아니다. 관련전문가에게는 다른 날짜/시간을 적용하는 것은 용이하다. 레코드에서 시간포인트 1은 통화 30802의 원시간인 시대시간을 나타낸다. 레코드에 저장된 다른 시간포인트는 시간포인트 1로부터 2번째 숫자, 즉 특정시간점이 발생한 시간포인트 1로부터의 오프셋값이다. 다른 모든 시간포인트는 어느 데이터가 기록되기전에 0으로 채워져야한다. 그러므로, 시간포인트가 일어나면 1또는 그 이상을 카운트한다. 추가적으로 시간포인트 1을 포함하지 않는 시간포인트 카운터는 그 값을 롤오버 하지 않지만 시간이 한계치를 초과하면 최대카운트에서 머무른다.
스위치 클럭은 국부스위치시간을 나타내고 빌링을 제외한 모든시간에 사용된다. 빌링정보는 시대시간에 기록되는데 이러한 구현은 UTC이다. 시간 오프셋은 UTC에 관련된 스위치 시간을 반영하는 값이고 적용가능한한 서머타임변화나 시간영역에 따른 오프셋이다. UTC 관련하여 시간변화를 평가할 때 고려해야 할 3가지 요소가 있다. 첫째, UTC양쪽에 시간영역이 있고 따라서 네거티브 및 포지티브 오프셋이 있다. 둘째, 시간영역 오프셋은 국제날짜선이 도달할때까지 동쪽에서 0으로부터(영국 그리니치)카운트 한다. 날짜선에서 날짜는 오프셋이 양으로되고 그리니치에 대해 제로오프셋이 도달할때까지 카운팅 다운을 하는식으로 다음날까지 변화한다. 셋째, 정확히 한시간 증가가 아닌 시간영역을 가지는 영역들이 있다. 예를 들어오스트레일리아는 시간영역 양쪽으로부터 30분차를 가지는 시간영역이 있고, 북인도는 15분차인 시간구역을 가진다. 그러므로 통화기록의 시간오프셋은 15분 증가에서 양과 음의 오프셋 변화치를 설명한다. 본 발명의 구현은 양 또는 음의 1분증가를 나타내는 시간오프셋을 제공함으로써 이러한 요구조건을 만족시킨다.
국부스위치시간을 시대시간으로 뒤로 변환하는데에는 2가지 공식이 있다.
i) 시대시간+(사인비트*시간 오프셋)=국부스위치 시간
ii) 국부스위치시간-(사인비트*시간오프셋)=시대시간
스위치는 1분과 같은 1값을 사용하여 SER에서 시간오프셋을 기록하고 초단위로 계산하여 이 값을 통화가 기록되기전에 각각의 국부시간포인트 1에 더하게 된다. 예를들어 중앙표준시간은 UTC전에 6시간이다. 이러한 경우 사인비트는 음의 오프셋에 대해서는 1을 표시하고 SER에 기록된 시간 오프셋값은 360(6시간*60분/시간=360분)이 될 것이다. SER기록포맷에의 보다 상세한 내용은 FIG 86을 보라. 통화record에 시간포인트 1을 기록할 때, 1분 증가에 60초이기 때문에 스위치는
시간 오프셋에 60을 곱하고 사인비트를 체크함으로써 오프셋이 양인지 음인지를 결정한다. 본 예는 -21,600(-1*360분*60초/분=-21,600)의 값이 된다. 상기로부터 식ii)를 사용하여 국부스위치 시간이 자정이면 예를 들어 해당시대시간은 1,200,000,000이 된다. -21,600의 시간오프셋을 빼면 1,200,021,600초의 보정된 시대시간이 되는데 이는 시대시간 다음날 자정후 6시간이 된다. 이러한 구현은 시간오프셋이 양의값을 가지는 그리니치의 동쪽에 위치한 스위치에 동일하게 작용한다.
시간을 변화시킬 때 2개의 명령어가 사용된다. 먼저, FIG 90은 국부스위치시간과 시간오프셋을 변화시키는 변화시간명령어 30900의 흐름을 조정하는 것을 설명한다. FIG 90에서, 스위치 오퍼레이터가 변화시간명령어를 입력한후 스위치는 스텝 30902로 들어가서 UTC로부터 시간오프셋과 국부스위치시간에 대해 스위치 오퍼레이터를 프롬프트한다. 스텝 30902에서 스위치 오퍼레이터는 새로운 국부스위치시간과 시간오프셋을 입력한다. 스텝 30904에 이어 새 시간과 시간오프셋이 스위치 오퍼레이터에 다시 표시된다. 스텝 30906에 이어 스위치 오퍼레이터는 실제 시간과 오프셋이 스위치에 변화하기전에 입력된 시간과 시간오프셋을 검증한다. 스텝 30906에서 스위치 오퍼레이터는 변화를 확인하고 스위치는 스텝 30908로 진행하여 변화가 국부스위치시간과 스위치의 시간오프셋에 일어난 것을 확인하는 둘에 일치하는 이벤트 한정자를 가진 SER을 발생한다. 빌링센터는 빌 처리를 위한 SER을 사용한다. 스위치는 스텝30910으로 진행하여 명령어를 배출한다. 스텝 30906으로 돌아가서 스위치 오퍼레이터가 변화를 확인하지 않으면 스위치는 스텝30910으로 진행하여 국부스위치시간과 시간오프셋을 갱신하지 않고 명령어를 내보낸다. SER에 대한 보다 자세한 것은 FIG 86을 보라.
FIG 91은 시간을 변화시키는 두 번째 명령어인 변화서머타임 명령어 31000의 조정흐름을 설명한다. FIG 91에서, 스위치 오퍼레이터가 변화서머타임 명령어를 입력한후 스위치는 스텝 31002로 들어가서 스위치 오퍼레이터가 앞 또는 뒤 시간 변화를 선택하도록 프롬프트한다. 스텝 31004에 이어 스위치 오퍼레이터는 선택을 하게 된다. 스텝 31004에서 스위치 오퍼레이터가 앞선택을 하면 스위치는 스텝 31006으로 간다. 스텝 31006에서 국부스위치 시간을 한 시간 앝으로 세팅하고 한 시간을(60 카운트) 시간 오프셋에 더한다. 스위치는 그때 스텝 31010으로 진행한다. 스텝 31004로 돌아가서 스위치 오퍼레이터가 뒤를 선택하면 스위치는 국부스위치시간을 한시간 뒤로 세팅하고 시간오프셋으로부터 한시간 빼게된다. 스위치는 그때 스텝 31010으로 진행한다.
스텝31010에서 스위치 오퍼레이터는 실제시간이 변하기전에 앞 또는 뒤선택과 새국부스위치시간 및 시간 오프셋을 확인해야한다. 스텝 31010에서, 스위치 오퍼레이터가 새시간과 시간오프셋을 확인하면 스위치는 스텝 31012로 진행하여 스위치의 오프셋과 국부스위치시간을 변화시키는 9에 일치하는 이벤트 한정자를 가진 SER을 발생한다. 스위치는 스텝 30104로 진행하여 명령어를 배출한다. 스텝 31010으로 돌아가서 스위치 오퍼레이터가 변화를 확인하지 않으면 스위치는 스텝31014로 진행하여 국부스위치시간과 시간 오프셋을 갱신하지 않고 명령어를 배출한다.
변화서머타임 명령어의 성공적인 완료후, 빌링기록은 새로운 시간 오프셋에의해 영향받는다. 이 구현은 빌링시간으로서 사용된 시대시간이 서머타임변화과정을 통해 보통으로 증가하도록 하고 국부스위치시간과 시간오프셋에의해 영향받지는 않는다.
2. 네트워크 통화 식별기
모든 구현은 통신네트워크를 이동하는 각각의 전화콜에 할당되는 유일한 NCID를 제공한다. 그래서 NCID는 모든 네트워크 통화중에서 구분된 식별기이다. NCID는 전화통화에 관련된 각스위치에 기록되고 전송된다.
전화통화의 발생스위치는 NCID를 발생한다. 본 발명의 NCID의 선택된 구현은 다음 서브필드로 구성되는 82비트 식별기이다.
i) 원천스위치ID(14비트): 이 필드는 각각의 스위치에서 오피스 엔지니어링에 정의된 NCS스위치 ID를 나타낸다. 그러나 SER통화기록은 스위치ID의 알파뉴메릭 표현을 포함한다. 그래서 스위치는 해당NCS스위치 ID를 수신하기위해 데이터베이스로의 인덱스로서 알파뉴메릭 스위치ID를 사용한다.
ii) 원천트렁크 그룹(14비트): 본 필드는 상기에서 설명된 32/64워드통화 레코드포맷에서 정의된 원천트렁크 그룹을 나타낸다.
ii) 원천포트숫자(19비트): 본 필드는 상기에서 설명된 32/64워드통화 레코드포맷에서 정의된 원천포트숫자를 나타낸다.
iii) 시간포인트 1(32비트): 본 필드는 상기에서 설명된 32/64워드통화 레코드포맷에서 정의된 시간포인트 1값을 나타낸다.
iv) 연속숫자(3비트): 본 필드는 동일한 시간포인트(두번째)값을 가진 같은 포트숫자에서 발생한 통화수를 나타낸다. 첫 번째 전화통화는 0으로 세팅되는 연속숫자를 가질 것이다. 이 값은 동일한 시간포인트 1값을 가진 같은 포트숫자에서 발생하는 각각의 연속숫자를 점진적으로 증가시킨다.
관련분야의 전문가에게는 서로다른 포맷의 NCID를 만들어 내는 것이 명백하다. 각각의 스위치는 32 또는 64 통화기록 포맷에서 NCID를 기록한다. 32단어 통화기록포맷을 고려하여 중간과 종료스위치는 확인코드필드가 다른정보를 기록하기위해 사용되지 않으면 32워드통화레코드의 확인코드필드에서 NCID를 기록한다. 이 경우 원천스위치 ID는 SER통화기록에 기록된것으로서 알파뉴메릭 스위치ID가 아닌 NCS스위치ID이다. 확인코드가 다른정보를 위해 사용되면 중간과 종료스위치는 64워드통화기록포맷에 NCID를 기록한다. 반대로 원천스위치는 32워드통화레코드에서 NCID를 저장할 때 확인코드필드를 사용하지 않는다. 원천스위치는 분리된 해당 32워드 통화기록에서 NCID서브필드를 기록한다. 즉, 원천스위치ID는 SER통화레코드의 스위치ID필드에서 알파뉴메릭 스위치 ID로서 저장된다. 원천 트렁크 그룹은 32워드통화레코드의 원천 트렁크그룹필드에 저장된다. 원천포트번호는 32워드통화레코드의 원천포트필드에 저장된다. 시간포인트 1은 32워드통화레코드의 NCID연속숫자필드에 저장된다. 연속숫자는 32워드통화기록의 NCID연속숫자필드에 저장된다. 32워드통화기록은 또한 통화기록확인필드에서 NCID가 기록될때를 식별하기위한 NCID 위치(NCIDLOC)필드를 포함한다. NCID위치필드가 1을 포함하면 그때 확인필드는 NCID를 포함한다. NCID위치필드가 0을 포함하면 그때 NCID는 통화기록의 분리된 서브필드에 저장된다. 오직 중간과 종료스위치만이 NCID위치필드를 1로 세트하는데 이는 원천스위치가 32워드통화레코드의 각각의 필드에서 NCID를 저장하기 때문이다.
64워드통화기록포맷을 고려하여 확장된 통화기록은 NCID의 82비트를 저장하기위해 NCID필드를 통화하고 분리된 필드르 포함한다. 이러한 통화기록은 원천,중간 또는 종료스위치가 NCID를 저장여부에 상관없이 동일하게 취급된다. 64워드통화기록포맷에서 원천스위치ID는 SER통화기록에 기록된 알파뉴메릭 스위치가 아닌 NCS 스위치ID 이다.
FIG 92는 네트워크 통화 식별기 스위치통화 처리에 대한 조정흐름을 설명한다. 통화 30202는 스텝 31104에서 스위치 30106-30110 (기준목적을 위한 현재스위치라고 함: 현재 스위치는 현재 통화를 처리하는 스위치임) 스텝 31104에서 현재스위치는 통화 30202를 수신하고 스텝31106으로 진행한다. 스텝 31106에서, 현재스위치는 로컬데이터베이스를 억세스하고 통화30202의 원천트렁크그룹과 관련된 트렁크그룹 패러미터를 얻는다. 패러미터를 얻고난후 현재스위치는 스텝31108로 진행한다. 스텝31108에서, 현재스위치는 통화 30202를 가진 NCID가 수신되었는지를 결정한다. 현재스위치가 통화 30202를 가진 NCID를 수신하지 못했으면 스위치는 스텝 31112로 연속한다.
스텝 31112에서, 스위치는 원천 트렁크그룹형태를 결정하기위해 원천트렁크그룹 패러미터를 분석한다. 원천 트렁크그룹형태가 인터머신 트렁크(IMT) 또는 방출링크 트렁크(RLT) 이면 그때 스위치는 스텝 31116으로 진행한다. IMT는 2개의 일반적인 통신스위치를 연결하는 트렁크인 반면 RLT는 일반적인 통신스위치에 인텔러전트 서비스 네트워크(ISN)플랫폼을 연결하는 트렁크이다. 현재스위치가 스텝31116에 이를 때, 현재스위치는 원천스위치가 아니라는 것을 알고 NCID를 수신해오지 않았다. 스텝 31116에서, 현재스위치는 통화 30202에 대한 NCID를 만들도록 되었는지를 정하기위해 원천트렁크그룹 패러미터를 분석한다. 스텝 31116에서, 통화 30202에대한 NCID를 만들지 않도록 되었다면 현재스위치는 스텝31118로 진행한다. 스텝 31118에서 현재스위치는 원천스위치가 아니라는 것을 알기 때문에 통화 30202에 대한 NCID를 수신하지 않았으나 NCID를 발생시킬 권한이 없다. 그러므로, 스텝 31118에서 현재스위치는 통화 30202에 관련된 통화기록을 국부스위치 데이터베이스로 기록하고 스텝 31120으로 진행한다. 스텝 31120에서 현재스위치는 통화 30202를 관련 NCID와 함께 네트워크를 통해 전송한다. 스텝 31120은 아래에 보다 더 자세히 설명된다.
스텝 31116을 다시 참조하여, 현재스위치가 통화 30202에 대한 NCID를 만들도록 되면 현재스위치는 스텝 31114로 진행한다. 스텝 31114에서, 현재스위치는 스텝 31136으로 게속하기전에 통화 30202에 대한 새로운 NCID를 발생한다. 스텝 31136에서 현재스위치는 NCID를 포함하여 국부스위치 데이터베이스에 통화 30202에 관련된 통화기록을 쓴다. 스텝 31120에서, 현재 스위치는 NCID와 관련한 네트워크를 통해 통화 30202밖으로 전송한다. 스텝 31120은 아래에 보다 자세히 설명되어 있다. 스텝 31112로 다시 돌아가서 현재 스위치가 원천 트렁크 그룹형태가 IMT 또는 RLT 인지를 결정하면 현재스위치는 스텝31114로 진행한다. 스텝 31114에 도달할 때 현재스위치는 원천스위치임을 알고 통화 30202에 대해 NCID를 발생한다. 스텝 31114는 아래에 자세히 설명되어 있다. 스텝 31114에서 NCID를 발생한후 현재 스위치는 스텝 31136으로 진행하여 국부데이터베이스에 통화 30202에 관련된 NCID를 포함하여 통화기록을 쓴다. 통화기록을 쓴후 현재스위치는 스텝 31120으로 진행하여 관련NCID와 함께 네트워크를 통하여 통화를 밖으로 전송한다. 스텝 31120은 아래에 또한 자세히 설명되어 있다.
스텝31108로 다시 돌아가서, 현재스위치가 통화 30202와 함께 NCID를 수신하였는지를 결정하면 현재스위치는 스텝 31110으로 진행한다. 스텝 31110에서 현재스위치는 수신된 NCID를 처리한다. 스텝 31110에서 두가지 가능한 결과가 있다. 먼저 현재스위치는 수신된 NCID를 유지하지 않는 것으로 결정하여 스텝 31110으로부터 스텝 31114로 진행하여 새NCID를 발생한다. 스텝 31110은 아래에 자세히 설명되어 있다. 스텝 31114에서 스텝 31116으로 계속가기전에 통화 30202에 대한 새NCID를 발생한다. 스텝 31114는 또한 아래에 자세히 설명되어 있다. 스텝 31136에서 현재스위치는 국부데이터베이스에 통화 30202에 관련한 통화기록을 쓴다. 현재스위치는 그때 스텝 31120으로 진행하여 NCID와 관련한 네트워크를 통해 통화 30202를 전송한다. 스텝 31120은 또한 아래에 자세히 설명되어 있다.
스텝 31110을 다시 참조하여 현재스위치는 수신된 NCID를 유지하도록 결정하여 스텝 31110으로부터 스텝 31115로 진행한다. 스텝 31115에서, 현재스위치는 수신된 NCID를 통화 30202에 과년한 통화기록에 추가한다. 스텝 31110과 31115는 아래에 자세히 설명된다. 스텝 31115후 현재스위치는 스텝 31136으로 계속되어 국부 데이터베이스로 통화 30202에 관련한 통화기록을 쓴다. 현재스위치는 그때 스텝 31120으로 진행하여 관련NCID와 함께 네트워크를 통해 통화 30202를 전송한다.
FIG 93은 수신된 NCID를 처리하는 스텝 31110에 대한 조정로직을 설명한다. 현재스위치는 NCID는 통화 30202로 수신되었는지를 결정할 때 스텝 31110의 스텝 31202로 들어간다. 스텝 31202에서 현재스위치는 원천 트렁크그룹 패러미터를 분석하여 원천트렁크그룹 형태를 결정한다. 원천트렁크 그룹형태가 IMT 또는 RLT 이면 그때 현재스위치는 스텝31212로 진행한다. 스텝 31212에서 현재스위치는 원천스위치가 아님을 알고 통화 30202에 대한 NCID를 수신하였다. 그러므로 스텝 31212에서 현재스위치는 수신된 NCID를 유지하고 스텝 31110을 방출하고 FIG 92의 스텝 31115로 연속하여 그후 현재스위치는 통화레코드에서 수신된 NCID를 저장하고 통화를 저장한다.
스텝 31202를 다시 참조하여 원천트렁크 그룹형태가 IMT 또는 RLT가 아니면 현재스위치는 스텝 31204로 진행한다. 스텝 31204에서 현재스위치는 원천트렁크 그룹형태가 집적서비스 사용자부문 직접억세스 라인(ISUP DAL) 또는 집적서비스 디지털 네트워크 프라이머리 레이트 인터페이스(ISDN PRI)인지를 결정한다. ISUP는 정보 파라미터로서 스위치로부터 스위치로 전송되는 정보를 허용하는 신호 프로토콜이다. ISUP DAL은 최초로 네트워크의 여러 고객에 의해 공유되는 트렁크 그룹이고 또한 단일 네트워크 고객에게 전용될수 있다. 반대로 ISDN PRI는 최초로 네트워크의 단일고객에 의해 공유되는 트렁크 그룹이고 또한 여러 네트워크 고객에게 전용될수 있다. 네트워크 고객은 네트워크 자원을 빌리는 실체이다. 스텝 31204에서 현재스위치가 트렁크그룹 형태가 ISUP DAL인지 ISDN PRI인지 결정하면 현재스위치는 스텝 31206으로 진행한다. 스텝 31206일 때 현재스위치는 네트워크 고객인 스위치 또는 통신네트워크의 일부인 스위치에 의해 발생되지 않은 NCID를 수신하였다는 것을 안다. 그러므로 스텝 31206에서, 현재스위치는 수신된 NCID를 버리는데 이는 믿을 수 없는 NCID이기 때문이다. 스텝 31206으로부터 스텝 31110을 방출하는데 FIG 92에서 현재스위치가 새로운 NCID를 만들어내고 통화 30202와 함께 NCID를 전송하는 스텝 31114로 계속된다.
스텝31204를 다시 참조하여, 현재스위치가 원천트렁크 그룹형태가 ISUP DAL 또는 ISDN PRI인지 결정하면 현재스위치는 스텝 31208로 계속된다. 스텝 31208일 때 현재스위치는 고객트렁크 그룹으로부터 NCID를 수신하였다는 것을 안다. 그러므로 현재스위치는 원천 트렁크그룹 패러미터를 분석하여 통화 30202에 대한 새로운 NCID를 만들권한이 있는지 없는지를 결정한다. 현재스위치는 새로운 NCID를 만들 수 있고 통화 30202에 해당하는 유효한 NCID를 확실히 하기위해 고객에 의해 제공된 NCID를 겹쳐쓰고 네트워크를 통해 전송한다. 스텝 31208에서, 새로운 스위치가 통화 30202에대한 새로운 NCID를 만들지 않도록 된다면 현재스위치는 스텝 31210으로 진행한다.
스텝 31210에서 현재스위치는 NCID길이와 같은 수신된 NCID의 유효성을 체크한다. 수신된 NCID가 유효하지 않으면 현재스위치는 스텝 31206으로 진행한다. 스텝 31206에서 현재스위치는 유효하지 않은 NCID를 버린다. 스텝 31206으로부터 현재스위치는 스텝 31110을 방출하여 FIG92의 스텝 31114로 가서 새로운 NCID를 만들어내고 통화 30202와 함께 그 NCID를 전송한다.
스텝 31210을 다시 참조하여 전류스위치가 수신된 NCID가 유효한지를 결정하면 전류스위치는 스텝 31212로 진행한다. 스텝 31212에서 전류스위치는 수신된 NCID를 유지하고 스텝 31110으로 빠져나와 FIG 92의 스텝 31115로 계속되어 통화기록에 수신된 NCID를 저장하고 통화를 전송한다.
FIG 94A는 NCID를 발생하는 스텝 31114에 대한 조정로직을 설명한다. 현재스위치는 NCID가 만들어질 때 스텝 31302로 들어간다. 스텝 31302에서 현재스위치는 연속숫자를 계산할 것이다. 연속숫자는 동일한 시간포인트값을 가진 동일한 포트에서 발생한 통화수를 나타낸다. 첫 번째 통화는 '0'값의 연속숫자를 가지며 그후 연속숫자는 같은 시간포인트를 가지는 동일한 포트번호에 근원하는 연속통화에 대해 점진적으로 증가한다. 스텝 31302에서 연속숫자를 만들어낸후 전류스위치는 스텝 31304로 진행한다. 스텝 31304에서 전류스위치는 통화 30202에서 새로이 만들어진 NCID를 포함하여 통화 30202에 대한 통화기록을 만들어 낸다. 통화기록이 만들어진후 현재스위치는 스텝31114로 가서 FIG 92의 스텝 31136으로 진행하여 국부스위치 데이터 베이스에 통화기록을 쓴다.
FIG 94B는 수신된 NCID를 통화 30202에 관련된 통화기록에 추가하는 스텝 31115에 대한 조정로직을 설명한다. 스텝 31115로 입력되어 현재스위치는 31306으로 들어간다. 스텝 31306에서, 중간 또는 종료스위치 또는 고객스위치로부터 유효한 NCID를 수신하였다는 것을 안다. 스텝 31306에서 현재스위치는 32워드 통화기록의 확인코드필드가 NCID를 저장하는데 유효한지를 결정한다. 유효하면 현재스위치는 스텝 31310으로 진행한다. 스텝 31310에서 현재스위치는 32워드통화 기록의 확인코드필드에서 NCID를 저장한다. 현재스위치는 또한 확인코드필드에 저장된 NCID를 지시하는 '1'값을 NCID위치필드에 세팅시켜야한다. 스텝 31310후에 현재스위치는 스텝 31115로 가서 FIG 92의 스텝 31136으로 연속되어 국부스위치 데이터베이스에 통화기록을 쓴다.
스텝 31306을 다시 참조하여 확인코드필드가 32워드통화기록에 유용하지 않으면 현재스위치는 스텝 31308로 진행한다. 스텝 31308에서 현재스위치는 64워드통화기록의 NCID필드에 NCID를 저장한다. 스텝 31308후 현재스위치는 스텝 31115로 가서 FIG 92의 스텝 31136으로 연속하여 국부스위치 데이터베이스에 통화기록을 쓴다.
FIG 95는 현재스위치로부터 통화를 전송하는 스텝 31120에대한 조정로직을 설멸한다. 조정로직에 대해 2개의 입력점이 있다. 스텝 31402와 31412. FIG 92의 스텝 31136으로부터 스텝 31402의 입력으로 현재스위치는 NCID를 만들었는지 또는 유효한 NCID를 수신했는지를 안다. 스텝 31402에서 현재스위치는 국부데이터베이스를 억세스하고 통화 30202를 전송하기 위한 트렁크 그룹과 관련된 트렁크 그룹 패러미터를 얻는다. 패러미터를 얻고난후 현재 스위치는 스텝 31404로 진행한다. 스텝 31404에서 현재스위치는 종료트렁크그룹 형태를 결정한다. 종료트렁크가 ISUP트렁크이면 현재스위치는 스텝 31408로 진행한다. 스텝 31408에서 현재스위치는 ISUP트렁크 형태와 관련한 패러미터를 분석하여 NCID를 다음 스위치로 전달할것인지 아닌지를 결정한다. 현잿스위치가
NCID를 전달할수 있도록 되면 현재 스위치는 스텝 31416으로 진행한다. 스텝 31416에서 현재스위치는 SS7 초기 어드레스 메시지 (IAM)를 따라 다음 스위치로 통화를 전송한다. NCID는 IAM의 포괄적인 디지트 패러미터의 부분으로서 전송된다. IAM는 통화 30202를 받아들이고 완료하는 다음 스위치를 준비하는 다음 스위치에 대한 셋업정보를 포함한다. 포괄적인 디지트 패러미터의 포맷은 아래 테이블 306에 보여진다.
포괄적인 디지트 패러미터 :
코드; 11000001
형태; 0
| 바이트#, 비트# | Description |
| 바이트 1, 비트 0-4 | 디지트 형태 : 패러미터의 내용을 지시한다.이 필드는 패러미터가 NCID를 포함한다는 것을 나타내기 위해 '11011'의 2진값을 가진다. |
| 바이트 1, 비트 5-7 | 엔코딩 구조 : 패러미터 내용의 포맷을 지시한다. 이 필드는 NCID가 2진 형태로 저장됨을 나타내기 위해 2진값 011을 가진다. |
| 바이트 2, 비트 0-7바이트 3 , 비트 0-5 | 원천스위치 ID |
| 바이트 3, 비트 6-7바이트 4, 비트 0-7바이트 5, 비트 0-3 | 원천 트렁크 그룹 |
| 바이트 5, 비트 4-7바이트 6, 비트 0-7바이트 7, 비트 0-6 | 원천포트번호 |
| 바이트7, 비트 7 | 사용되지 않음 |
| 바이트8, 비트 0-7바이트9, 비트 0-7바이트10, 비트0-7바이트11, 비트0-7 | 시간포인트 1 |
| 바이트 12, 비트0-2 | NCID연속숫자 |
| 바이트 12, 비트 3-7 | 사용되지 않음 |
테이블 306
통화 30202와 IAM을 전송한후 현재스위치는 스텝 31418로 진행하여, 스위치 프로세싱을 종료한다.
스텝 31408을 다시 참조하여 현재 스위치가 IAM메세지에서 NCID를 다음 스위치로 전달하도록 권한이 부여되면 현재 스위치는 스텝 31412로 진행한다. 스텝 31412에서 현재스위치는 포괄적인 디지트 패러미터의 부분으로서 기록되는 NCID없이 다음스위치로 IAM메세지를 보내는 것으로 이루어지는 보통의 과정하에 통화 30202를 다음스위치로 전송한다. 통화 30202로 전송한후, 현재스위치는 스텝 31418로 진행하여 거기서 스위치 프로세싱을 종료한다.
스텝 31404를 다시 참조하여 현재스위치가 종료트렁크가 ISUP가 아님을 결정하면 현재스위치는 스텝 31406으로 진행한다.
스텝 31406에서 현재스위치는 종료트렁크 그룹이 ISDN트렁크(종료트렁크 그룹은 하나의 네트워크 고객에게 바쳐진다) 인지를 결정한다. 종료트렁크 그룹이 ISDN이면 현재스위치는 스텝 31410으로 진행한다. 스텝 31410에서, 현재스위치는 ISDN트렁크 그룹형태와 관련된 패러미터를 분석하여 다른 스위치로 NCID를 전달할것인지 아닌지를 결정한다. 현재스위치가 NCID를 전달하도록 권한이 부여되면 현재스위치는 스텝 31414로 진행한다. 스텝 31414에서, 현재스위치는 셋업 메시지를 따라 통화를 다음 메시지로 전송한다. 셋업 메시지는 다음스위치가 통화 30202를 받아들이고 완료하도록 준비하도록 하는 다음스위치에 대한 셋업정보를 포함한다. NCID는 셋업메세지의 이동코드셋 6 패러미터를 록킹하는 부분으로서 전송된다. 이동코드셋 6패러미터를 록킹하는 포맷은 아래에 테이블 307에서 보여진다.
록킹 이동코드셋 6패러미터 :
코드: 11000001
형태: 0
형태; 0
| 바이트#, 비트# | Description |
| 바이트 1, 비트 0-4 | 디지트 형태 : 패러미터의 내용을 지시한다.이 필드는 패러미터가 NCID를 포함한다는 것을 나타내기 위해 '11011'의 2진값을 가진다. |
| 바이트 1, 비트 5-7 | 엔코딩 구조 : 패러미터 내용의 포맷을 지시한다. 이 필드는 NCID가 2진 형태로 저장됨을 나타내기 위해 2진값 011을 가진다. |
| 바이트 2, 비트 0-7바이트 3 , 비트 0-5 | 원천스위치 ID |
| 바이트 3, 비트 6-7바이트 4, 비트 0-7바이트 5, 비트 0-3 | 원천 트렁크 그룹 |
| 바이트 5, 비트 4-7바이트 6, 비트 0-7바이트 7, 비트 0-6 | 원천포트번호 |
| 바이트7, 비트 7 | 사용되지 않음 |
| 바이트8, 비트 0-7바이트9, 비트 0-7바이트10, 비트0-7바이트11, 비트0-7 | 시간포인트 1 |
| 바이트 12, 비트0-2 | NCID연속숫자 |
| 바이트 12, 비트 3-7 | 사용되지 않음 |
테이블 307
통화 30202와 셋업메세지를 전송한후 현재스위치는 스텝 31418로 진행하여, 스위치 프로세싱을 종료한다.
스텝 31408을 다시 참조하여 현재 스위치가 셋업메세지에서 NCID를 다음 스위치로 전달하도록 권한이 부여되면 현재 스위치는 스텝 31412로 진행한다. 스텝 31412에서 현재스위치는 록킹이동코드셋 6 패러미터의 부분으로서 기록되는 NCID없이 다음스위치로 셋업 메세지를 보내는 것으로 이루어지는 보통의 과정하에 통화 30202를 다음스위치로 전송한다. 통화 30202로 전송한후, 현재스위치는 스텝 31418로 진행하여 거기서 스위치 프로세싱을 종료한다.
다시 스텝 31412를 참조하여 현재스위치가 NCID를 수신하지 않았을 때, 중간과 종료스위치일 때 그리고 NCID를 만들도록 되지 않았을 때 FIG 92의 스텝 31118으로부터 입력된다. 이러한 경우 스텝 31412에서 현재스위치는 패러미터의 부분으로서 기록되는 NCID없이 다음스위치로 셋업 메시지 또는 IAM을 보내는 것으로 이루어지는 보통의 과정하에 통화 30202를 다음스위치로 전송한다. 통화 30202로 전송한후, 현재스위치는 스텝 31418로 진행하여 거기서 스위치 프로세싱을 종료한다.
전화에 대한 통화기록들을 발생시키기 위한 통신네트워크의 스위치에 대한 시스템 및 방법은 유연하고 확장된 포맷을 사용한다. 전화통화의 수취로 네트워크의 스위치는 전화통화를 분석하여 디폴트 통화기록이 전화통화를 포함하여 통화기록정보를 저장할만큼 충분히 큰지 또는 확장된 통화기록이 전화통화를 포함하여 통화기록을 저장하여야만 하는지를 결정한다. 어떤 통화기록을 사용할지를 결정한후 스위치는 디폴트 또는 확장통화기록을 발생한다. 스위치는 전체 빌링블럭을 파일함으로 완료된 통화기록들로 구성된 빌링블럭을 빌링센터로 보낸다.
ⅩⅩⅡ. 우선화 억세스/라우터 ⅩⅩⅡ
A. 우선화 억세스/라우터 개관
우선화 억세스 라우터(PAR)는 인터넷 억세스 장치 및 인터넷 프로토콜 (IP) 라우터의 특성들을 결합하도록 되어있다. 이것은 필연적인 모뎀 및 PPP/SLIP를 IP로 그리고 IP를 PPP/SLIP로의 변환을 수행함으로써 인터넷으로의 다이얼업 모뎀 억세스를 가능케 한다. 이는 또한 IP 패킷 소오스/착신지 어드레스 및 UPD 또는 TCP 포트를 분석하고, 각 패킷에 대한 적절한 출중 네트워크 인터페이스를 선택한다. 마지막으로, 이는 다른 네트워크 인터페이스에 대해 예정된 패킷에 대해 특정 네트워크 인터페이스에 대해 예정된 패킷을 선호처리 하기위해 우선화 라우팅 기술을 사용한다.
우선화 억세스/라우터의 설계목적은 인터넷 네트워크를 통해 최선의 데이타 트래픽의 나머지로부터 실시간 트래픽을 분리하는 것이다. 실시간 및 인터액티브 멀티미디어 트래픽은 인터넷으로의 억세스 포인트에서 실시간 제약없이 트래픽으로부터 최상으로 분리되어, 서비스 품질에 대한 최상의 제어가 얻어질수 있다. 도 114A는 바람직한 실시예에 따른 억세스/라우터 시스템의 블록선도이다.
B. 우선화 억세스/라우터 프로세스
1. 컴퓨터가 모뎀을 통해 PAR을 다이얼업한다. 이 컴퓨터모뎀은 PAR 모뎀(11410)과 데이타 전송비율 및 모뎀 프로토콜 파라미터와 교섭한다.
2. 컴퓨터는 PSTN 접속을 통한 모뎀-모뎀 접속을 이용하여 PAR과 포인트-포인트 프로토콜(PPP)을 셋업한다.
3. 컴퓨터는 모뎀 접속을 이용하여 PPP 패킷을 PAR에 전송한다. PAR 모뎀(11410)은 모뎀-호스트프로세서 인터페이스(11480)를 통해 PPP 패킷을 PPP-ID 변환 프로세스(11420)에 전송한다. 모뎀-호스트프로세서 인터페이스는 현재 유용하거나 또는 발명된 어떤 물리적인 인터페이스로 될 수 있다. 현재 나와있는 예로써 ISA, EISA, VNE, SC버스, MVIP 버스, 메모리 채널 및 TDM 버스들이 있다. 여기서 언급한 시분할 멀티플렉싱 버스와 같은 멀티플렉싱 버스들을 이용하는데에 일부 장점이 있는데, 그 이유는 특정 데이타 흐름 용량을 충당 및 결정적인 행위를 보전할 능력을 가지기 때문이다.
4. PPP-ID 변환 프로세스(11420)는 PPP 패킷을 IP 패킷으로 변환하고, 결과적인 IP 패킷을 프로세스-프로세스 인터페이스(11485)를 통해 패킷 분류기(11450)에 전송한다. 프로세스-프로세스 인터페이스는 전용 프로세서 하드웨어간의 물리적인 인터페이스로 될 수 있거나 또는 소프트웨어 인터페이스로 될 수 있다. 프로세스-프로세스 소프트웨어 인터페이스들의 예로써 함수 또는 서브루틴호출, 메시지큐, 공유 메모리, 직접 메모리 억세스(DMA)및 메일박스가 포함된다.
5. 패킷분류기(11485)는 패킷이 어떤 특별한 우선화된 그룹에 속하는지를 판단한다. 패킷분류기는 다음과 같이 정의되는 흐름 명세표를 유지한다.
착신지 IP 어드레스
소오스 IP 어드레스
결합된 소오스/착신지 IP 어드레스
결합된 착신지 IP 어드레스/UDP 포트
결합된 착신지 IP 어드레스/TCP 포트
결합된 소오스 IP 어드레스/UDP 포트
결합된 소오스 IP 어드레스/TCP 포트
결합된 소오스 IP 어드레스와 TCP 또는 소오스 IP 어드레스를 갖는 UDP 포트
결합된 착신지 IP 어드레스와 TCP 또는 소오스 IP 어드레스를 갖는 UDP 포트 결합된 소오스 IP 어드레스와 TCP 또는 착신지 IP 어드레스와 TCP/UDP 포트를 갖는 UDP 포트 패킷분류기는 패킷에서 사용되는 IP 어드레스와 UDP 또는 TCP 포트에 대해 그것의 흐름 명세표를 체크한다. 만일 어떤 매칭이 발견되면, 그 패킷은 우선화 흐름에 속하는 것으로 분류되며, 우선화 태그가 붙여진다. 자원 예약 셋업프로토콜기법들이 패킷분류기 단계에서 사용될 수 있다.
6. 패킷분류기(11450)는 태그 및 비-태그 패킷을 프로세스-프로세스 인터페이스(11490)를 통해 인터페이스(11490)는 프로세스-프로세스 인터페이스(11485)와 동일할 필요가 없지만은 동일한 기법의 선택이 유용하다. 패킷 스케쥴러(11460)는 (패킷분류기에 의해 확인되는) 우선화 패킷이 보다 높은 우선권을 수여받을 수 있도록 하는데 기여하기 위해 가중화된 페어큐(Weighted Fair Queueing)와 같은 우선화큐 기법을 사용하며, 최선노력의 트래픽과 경합하기에 앞서 아웃바운드 네트워크 인터페이스큐에 설정될 수 있다.
7. 패킷 스케쥴러(11460)는 호스트 프로세서-주변버스(11495)를 통해 우선순위로 패킷을 어떤 아웃바운드네트워크 인터페이스(11410, 11470, 11471 또는 11472)에 핸드오프한다. 어떤 수의 아웃바운드네트워크 인터페이스도 이용될 수 있다.
8. 단계 3과 마찬가지로, IP 패킷은 비-모뎀인터페이스(11470, 11471, 11472)를 통해 PAR에 도달할 수 있다. 이들 인터페이스들의 예로써, 이터넷, 고속 이터넷, FDDI, ATM 및 프레임 길레이가 포함된다. 이들 패킷들은 모뎀 PPP 인터페이스에 도달하는 IP 패킷과 같이 단계 5 내지 7 을 통해 진행한다.
9. 우선화 흐름 명세는 컨트롤러 프로세스(11430)를 통해 관리된다. 이 컨트롤러 프로세스는 외부 제어 응용 프로그래밍 인터페이스(11440)를 통해 외부적으로 설정된 우선화 예약을 받아드릴 수 있다. 컨트롤러는 인정 제어 절차 및 정책절차에 대해 특별흐름에 대한 우선화 예약의 유효성을 판단하며, 만일 예약이 인정되면, 흐름 명세는 프로세스-프로세스 인터페이스(11465)를 통해 패킷분류기(11450)에 있는 흐름 명세표에 입력된다. 프로세스-프로세스 인터페이스(11465)는 프로세스-프로세스 인터페이스(11485)와 동일할 필요는 없지만은 동일한 기법들의 선택이 유용하다.
XXIII. 콜백전화시스템
A. 바람직한 실시예에 따른 콜백전화시스템의 소개
오늘날의 전화 환경에서, 호출자는 회의호출을 개시하기 위해서 모퍼레이터와 접촉하거나 또는 회의 호출에 연결하기 위해서 모든 진영들의 공통 다이얼 번호를 가져야만 한다. 이는 사람이 오퍼레이터 역할을 해야함을 요하며, 각 회의 호출의 오버헤드로서 수행될 소정의 번호를 다이얼링해야하는 번거로움이 따른다. 또한, 회의 호출을 스케쥴링하고, 모든 진영들이 참여할 수 있도록 하는데 매우 비효율적이다.
또한, 모든 진영들이 호출을 용이하게 억세스하기 위한 전용 번호가 필요로 된다.
바람직한 실시예에 따르면, 콜백 시스템은 컴퓨터로부터 디스플레이를 억세스하고 그리고 어느 한 호출의 파라메터들을 설명하는 정보를 써넣는데 있어 호출자에 의해 용이하게 이용된다. 호출이 개시되는 날짜 및 시간과 같은 정보, 요금부와 정보, 호출에 참여할 진영들의 전화번호들이 포착될 수 있다. 그리고나서, 입력된 정보에 근거하여, 하이브리드 네트워크로의 억세스를 갖는 중앙 또는 분산 계산설비가 다른 진영을 복사하는 호출이 참여를 검증하고 이벤트의 일정을 짜는데 요구되는 전자메일을 각 진영에 전송한다. 전자메일은 호출과 관련된 패스워드 및 호출이 개시되는 시간과 같은 특별사항들을 포함할 수 있다. 필요한 네트워크 설비들이 또한 적절한 서비스 품질(QOS)이 유용하도록 하기 위해 예약될 수 있으며, 요청된 날짜 및 시간이 도달할 때, 그들이 PSTN에 연결된 전화를 이용하고 하이브리드 네트워크에 연결된(컴퓨터 또는 지능 텔레비젼과 같은) 음성 능력 장치를 이용하건간에 참여자들 각각을 접촉하므로써 호출이 시작된다. 호출의 스케쥴링, 개시 또는 지속 동안 어느시간에, 어느 진영도 호출과 관련된 디스플레이로부터 서비스를 선택하므로써 오퍼레이터의 도움을 요청할 수 있다. 따라서, 호출 셋업 및 제어에 대한 완전 자동화된 호출시스템이 제공된다. 정규적인 기반으로 콜백 시스템을 이용하는 호출자들에 대해 고객 프로파일이 유저 프로파일정보에의 연장으로서 제공된다. 고객 프로파일은 유저가 빈번한 회의호출 참여자 정보를 저장할 수 있게 한다. 이 프로파일 정보는(DDD, IDDD, IP 어드레스 또는 셀룰러폰 번호로 될 수 있는) 참여자의 전화번호, 전자메일 어드레스, 페이징서비스, 팩스번호, 비서전화번호, 위치, 시간대, 작업시간 및 호출을 시작하는데 유용한 기타 관련 정보를 포함한다. 회사 또는 지지 필요성에 근거한 디폴트 프로파일들이 또한 인에이블되고 그리고 보다 많은 글로벌 정보에 근거 특별한 유정의 필요성을 충족시킬 수 있도록 맞추어질 수 있다.
요금부와 정보 또는 온라인으로 제공될 수 있다. 유저는 미리배열된 요금부와 번호 또는 요금부와 능력을 신용카드 또는 전화번호에 기입할 수 있다. 전화번호에의 요금부과시, 시스템은 요금부과를 검증하기 위한 호출 또는 제로진영호출처럼 상기 호출을 처리한다.
만일 프로파일정보가 특별한 호출 시나리오에 대해 미리 정의되어 있으면, 한 호출자가 호출진영의 간섭없이 합류할 수 있는것 이상으로 인터넷호출자들이 지원되고 그리고 한 오퍼레이터가 요구에 따라 합류될 수 있는 것을 제외하고, 다른 옵션이 오늘날 스피드 다이얼링이 수행되는 것처럼 많이 버튼의 누름에 의해 회의 호출 또는 단일호출의 즉각적인 연결을 가능하게 할 수 있다.
B. 인터넷기반 콜백 아키텍춰
다음 정보는 바람직한 실시예에 따른 인터넷기반 콜백 아키텍춰의 상세한 구조를 설명하는 것이다. 바람직한 실시예에 따른 이키텍춰의 블록선도가 도 114B에 도시되어 있다. 도 114B의 부호 11410 에 예시한 바와 같이, 호출자 11412 가 지역 인터넷 서비스 제공자 11419 에 호출을 보낼때 콜백 호출 흐름이 진행된다.
호출자는 인터넷 구름으로 표시된 기본 인터넷 프로토콜 플랫폼 11419 로서 보인 바와 같이 인터넷 11419 를 통해 콜백 홈페이지 11411 을 억세스하기 위해 콜백 서버 11414 를 어드레스한다. 콜백 서버 홈페이지 11411 에서, 호출자는 콜백 인터넷 프로토콜(IP) 어드레스, 호출-전화 번호(또는 회의 호출을 개시하기 위한 다중 전화번호) 및 최소로 요금부과하는 방법등과 같은 디폴트 정보를 입력, 검토 및/또는 갱신한다. DDD(Direct Directing Dirling), IDDD(International Direct Distance Dialing) 또는 인터넷 프로토콜(IP) 어드레스의 엔드리로 구성되는 하나 이상의 번호와 같은 다른 정보들이 음성능력을 갖는 인터넷 컴퓨터 또는 전화번호를 특정화하는데 이용될 수 있다. 추가로, 날짜 및 시간들은 콜백 동작을 스테이직하는데 미리 배열될 수 있다. 콜백 서버홈페이지 11411 에서 캡춰될 수 있는 추가의 정보들이 본 발명의 바람직한 실시예에 따라 명확히 하도록 된 특정 예를 들어 하기에 상세히 설명된다.
이어서, 단계 11420 에서 콜백 서버 11414 는 적절한 호출정보와 함께 메세지를 콜백 스위치 11432 에 전송하며, 콜백 스위치 11432 는 단계 11430 에서 보인 바와 같이 호출의 콜백 레그를 PSTN 11435 를 통해 호출자에 의해 특정화된 착신지에 전송하고 그럼으로써 콜백 호출자는 11437 에서 입력 호출에 응답한다. 일단 호출자의 호출이 준비되면, 콜백 스위치는 경로 11440 내지 PSTN 11445 를 통해 호출을 전화 세트 11446 및/ 또는 11447 에 연결하는 호출을 위한 호출 레그를 개시한다. 모든 호출자가 연결되면, 호출상태가 변화할 때, 만일 IP 호출이면 예외 조건이 디스플레이상에 표시되거나 또는 만일 이들이 표준 전화 장치를 사용하면, 그 조건에 대한 음성 표시가 호출자들에게 전송된다. 상태에서의 변화는 호출자 행업 또는 전송시 발생하는 고장일 수 있다. 이 예외조건을 또한 서비스 품질 분석을 위해 캡춰될 수 있다.
콜백 호출의 초기화 부분으로서 콜백 서버 홈페이지 11411 로 입력되는 정보를 이용하여 호출이 초기화될 때, 콜백 세션의 개시자에 의해 선택된 패스워드를 통해 콜백의 모든 회원에 억세스될 수 있는 개별 임시 웹페이지가 창출된다. 모든 호출자가 연결되어 전화 경험 구간 동안 지속되는 동안, 호출 레그의 상태가 변하며, 예외 조건들이 임시 생성된 웹페이지 상에 표시되거나 혹은 적절할시 상기 조건의 음성 표시가 만일 호출자들이 표준 전화 장치를 이용하는 경우 호출자들에게 전송된다. 이어서, 호출자들이 연결, 제거 또는 상태변화되면, 디스플레이는 각 참여자의 연결 상태를 반영하도록 갱신된다. 추가로, 호출이 진행될 때, 참여자들은 파일, 비디오클립 또는 호출시 장식물로서 활용될 수 있는 어떤 다른 정보를 드래그 또는 드롭할 수 있다. 각 참여자들은 웹페이지가 임시적이고 호출의 종료하에서 삭제되기 때문에 호출이 종료되기전 그들의 퍼스널 컴퓨터로 정보를 이동시키도록 요구받는다. 임시 웹페이지는 이 웹페이지에 포함된 정보로의 허락되지 않는 억세스를 회피하도록 보호되는 패스워드이다.
C. 콜백 서비스 포텐셜
콜백 서비스는 일-일 호출, 일-다수 호출(회의 호출, 팩스방송, 텍스트-스피치 메세지 배달, 음성-음성 메세지 배달, 회의 호출 예약에 대한 지원을 포함하며, 그럼으로써 서버는 전자메일을 회의 호출 상세사항과 함께 호출 참여자들에게 전송하거나 또는 서버는 텍스트-스피치 메세지를 호출 암여자에게 전송한다.
D. 인터넷 서비스 포텐셜
각 회의 호출 참여자의 상태, ANI 및 호출의 "예약" 될때 개시자에 의해 입력된 각 참여자를 확인하기 위한 알파벳 표시의 실시간뷰가 참여자들이 회의에 연결될 때 스크린 상에 디스플레이 될 수 있다. 이 정보는 서두에 언급하고 첨부에서 상세히 설명되고 있는 호출 레코드의 일부로서 캡춰된다.
다른 실시예에서, 콜백 레그없이 회의 호출이 인에이블된다. 이 실시예에서, 콜백고객은 음성능력을 갖는 컴퓨터를 이용하여 VON(Voice Over Network)을 통해 참여하며, 비디오 오퍼레이터에 관한 상기 설명에서 상세히 언급한 수동 오퍼레이터의 도움을 위해 컴퓨터 디스플레이 상에서 비디오 스크린 팝업을 시작할 수 있다.
E. 인터넷기반 콜백 아키텍춰
도 115 에 예시된 인터넷 기반 콜백 아키텍춰에서, 콜백 호출자는 로컬 인터네서비스 제공자에 다이얼링 한다(11512), 이어서, 호출자는 콜백 홈페이지(11510, 11511)를 포함하는 호스트 서버(11514)를 어드레스 한다. 콜백 서버 홈페이지(11511)에서, 호출자는 이전에 언급한 바와 같은 콜백 인터넷 프로토콜(IP) 어드레스, 호출전화번호(또는 회의 호출을 개시하기 위한 복수의 전화번호) 및 최소의 요구부과 방법을 포함하는 정보를 입력한다. 이어서, 호출을 개시하기 위한 콜백 호출흐름에 있어, 콜백 서버홈페이지(11511)로 부터 발생되는 필요한 호출정보와 함께 메세지를 콜백 스위치(11532)에 전송한다. 마지막으로, 콜백 호출자는 초기 클라이언트(11535)와 음성 IP 세션을 설정하기 위해 인터넷 서비스 제공자(11512)를 이용한다. 이어서, 콜백 스위치(11511)는 PSTN(11541)을 통해 전화기 세트(11542)로 호출(11540)을 라우팅하는 호출을 위한 호출레그를 초기화 한다.
F. 자기 조정 시스템
바람직한 실시예에 따르면 전문가 시스템이 각 호출을 감시한다. 이 시스템은 예외 발생시 어떤 로직이 실행되어야 할지를 정의하는 규칙을 가지고 있다. 이 규칙은 호출이 PSTN 을 통해서 라우팅되는지 또는 인터넷을 통해서 라우팅되는지에 근거하여 특별한 프로세싱을 행하는 것을 포함한다. 추가로, 이 시스템은 만일 접속에 대한 다른 보정이 활용될 수 없는 경우 수동 오퍼레이터와의 디폴트 접속을 포함한다. 예컨데, 만일 호출자가 전화회의동안 행업하거나 또는 다른 호출자들이 계속 접속중인 경우, 상태변화를 통보하는 예외메세지가 상기 계속 접속중인 호출자들 각각에 전송된다. 전문가 시스템의 또 다른 특징은 서비스품질(QOS)을 보장하고 완전성 및 예외를 표시하는 리포트를 생성한다는 것이다. 자원들에 대한 스케쥴링이 이 전문가 시스템에 연결되며, 이 시스템은 제안된 호출시간에 이용가능하거나 또는 정해진 자원들에 근거하여 호출이 스케쥴링 될 수 있는지 여부를 조정한다. 예컨데, 이 시스템에 의해 이용되는 모든 호출은 콜백스위치(도 114B 에서 11432 및 도 115에서 11532)에 의해 초기화되기 때문에, 만일 콜백 가입자가 요청하는 시간주기동안 출중계 포트가 불충분하면 콜백 가입자는 다른 시간 또는 그 시간동안 상기 자원들로의 거부된 억세스를 선택하도록 요청받는다. 이것은 추가의 포트들 및/또는 자원들이 요청되는 때를 예측하는데 활용된다.
본 발명은 콜백 특성 실행에 대한 보다 효과적인 방법을 설명한다. 제안된 방법은 외부 로컬 억세스 선로들에 대한 필요성을 제거하고, 동시에 콜백 특성을 이용할 수 있는 유저들의 수를 증가시킨다. 이 방법은 원격 테스트 시스템으로부터 원격 유저까지의 물리적인 접속보다는 가상 접속 이용에 관해 설명한다. 원격 테스트 시스템과 원격 유저들로부터의 로컬 전화 선로들은 더 이상 필요하지 않다.
다음 설명은 DXC I/O를 통해 회로를 통과하는 고객들을 이용하는 예들을 보여준다. 원격 테스트 시스템이 TAD를 통해 억세스한 교환국 유지 포트를 경유하여 회로들의 인입 포트를 억세스함으로서 교환국을 통하는 억세스 및 테스트 고객의 회로 뿐만아니라 다른 DXC 유형/레벨들을 통해 회로를 통과하는 고객들에게 동일하게 적용될 것이다.
도116은 콜백 특성을 통상적으로 실행하는 방법을 보여준다. 이 예에서, 디지털 VAX 컴퓨터(11650)로부터 원격 테스트 시스템까지의 접속은 X.25 네트워크를 이용하는 X.25 접속을 경유한다. 원격 유저(11660)는 테스트 시스템(11602)에서 DXC I/O(11617)를 통해 통과하는 고객 회로에 대한 음성 회로 테스트을 선택한다. 테스트 시스템(11602)은 원격 유저(11660)에게 원격 유저의 디스플레이상에 "콜백 번호를 입력했습니까?"라는 문장을 디스플레이한다. 원격 유저(1166)는 같은 장소에 배치된 전화(11603)의 전화 번호를 입력한다. 같은 장소에 배치된 전화번호를 입력한 후에, 원격 테스트 시스템(11602)은 자신의 로컬 전화 선로들(11622) 중 하나를 선택한다. 로컬 전화 회사로부터의 다이얼톤을 검출하자 마자, 원격 테스트 시스템(11602)은 원격 유저의 전화번호를 나타내는 DTMF 톤을 보내거나 전송한다. 원격 유저의 로컬 전화회사는 들어오는 호출을 수신하여 호출을 로컬 선로를 통해 원격 유저와 같은 장소에 배치된 전화(11603)에 보낸다.
원격 유저(11660)는 전화를 훅오프 상태에 놓고, DXC I/O(11617)을 통해 통과하는 고객 회로를 청각적으로 감시하거나, 또는 고객 전화로 호출을 시작하기 위해서 원격 테스트 시스템(11602)의 신호 상태를 이용할 수 있다.
고객이 전화에 응답할 시, 원격 테스트기(11660)는 테스트 시스템(11602)을 통해 같은 장소에 배치된 전화(11603)로부터 고객과 통화한다.
도 117 - 도표 B
도117은 양호한 실시예에 따라 가상 콜백을 이용하는 콜백 특성을 실행하기 위한 방법을 보여준다. 이 아키텍춰에서, 원격 유저로부터 원격 테스트 시스템까지의 전체 경로는 인터넷 프로토콜(IP) 네트워크를 통과한다. 원격 유저의 컴퓨터(11721) 및 원격 테스트 시스템(11702)은 전술된 것과 같이 IP 호출을 유저가 입력한 IP 목적 어드레스로 접속하는 인터넷 전화를 용이하게하는 소프트웨어를 가지고 있다. 원격 유저의 컴퓨터(11721)는 적절한 내장형 모뎀 또는 스피커와 마이크의 가능한 출력을 지원하기 위해 특별히 설계된 네트워크 인터페이스 카드(NIC)를 갖는다. 유저가 모뎀이나 NIC 카드를 통해 통신하기 위해서는 스피커 및 마이크를 갗춘 헤드폰을 경유하여야 한다. 헤드폰은 유저 컴퓨(11721)내의 모뎀이나 NIC 카드에 직접 플러그를 꽂아야 한다.
원격 유저(11721)는 테스트 시스템(11702)에 접속되는 DXC I/O(11717)를 통해 고객 회로를 통과하는 음성 회로 테스트을 선택한다. 원격 유저는 자신의 컴퓨터(11721)상에 있는 인터넷 전화 소프트웨어를 동작시키며, 테스트 시스템 (11702)은 원격 유저(11721)에게 "가상 콜백을 원합니까?"라는 문구를 디스플레이한다. "예"를 선택하자 마자, 원격 테스트 시스템(11702)은 자신의 인터넷 전화 소프트웨어를 동작시킨다. 원격 테스트 시스템(11702)의 인터넷 전화 소프트웨어는 원격 유저(11721)에게 그들의 IP 어드레스를 요청한다. 그들의 IP 어드레스를 입력한 후에, 원격 테스트 시스템(11702)은 원격 유저의 컴퓨터(11721)로 IP 호출을 시작할 것이다. 원격 유저의 컴퓨터(11721)로 IP 접속이 이루어지면, 원격 테스트 시스템(11702)의 인터넷 전화 소프트웨어는 원격 유저(11721)의 인터넷 전화 소프트웨어에 대한 접속을 요청한다. 일단 원격 유저(11721)의 소프트웨어가 원격 테스트 시스템(11702)의 인터넷 전화 소프트웨어와 링크되면, 원격 유저(11721)는 전술된 것과 같이 테스트중인 고객 회로를 통해 감시 및 통신한다.
원격 유저에 대한 모든 통신은 헤드폰과 전화기를 통해 이루어진다. 로컬 억세스 선로는 더이상 필요하지 않을 것이다. 원격 테스트 시스템은 로컬 억세스 선로들이 더이상 이용될 수 없기 때문에 콜백 특성을 갖고 호출을 지원하는 로컬 선로들의 수에 의해 제한되므로, 전화회사가 부과하는 로컬 억세스 요금은 어떤 것도 이용되지 않기 때문에 더이상 적용되지 않는다.
도 118 - 도표 C
도118은 양호한 실시예에 따라 인터넷 전화 지원을 받는 시스템 아키텍춰를 설명하는 도면이다. MCI의 원격 테스트 시스템은 음성 회로 보장 테스트, 다이얼 계획 및 신호 상태들에 필요한 커맨드 구조를 지원한다. 일단 적절하게 개선된 장치들이 설치되면, MCI 원격 테스트 능력들은 개선된다. 원격 VAX(11876)와 원격 테스트 시스템(11884)은 인터넷 통신에 대한 TCP/IP 프로토콜을 지원하기 위해 개량된 소프트웨어와 하드웨어다. 이것은 TCP/IP 시스템 소프트웨어 및 토큰 링(Token Ring), 이터넷(Ethernet) 또는 다른 네트워크 지원 카드를 부가한다. 원격 VAX(11876) 및 원격 테스트 시스템(11884)은 토큰 링, 이터넷 또는 다른 네트워크에 접속된다.
네트워크는 광 로컬 정보 통신망(WAN) 및/또는 인터넷에 억세스하기 위해 라우터(11878,11882)에 접속한다. 원격 테스트 시스템(119\884)은 원격 테스트 시스템(11884)이 음성 회로 보장 테스트을 실시하게하는 소프트웨어를 포함한다. 이것은 루프 시작 또는 그라운드 시작, 전화를 걸기 위한 번호와 같은 여러가지 신호 상태들, 및 DTMF, 다이얼 펄스 또는 다중 주파수(MF)와 같은 적절한 신호를 선택하는 능력을 포함한다. 원격 테스트 시스템(11884)은 고객의 회로 경로를 통한 고객과의 음성 통신 및 청각적인 감시에 대한 인터넷 전화 소프트웨어에 고객이 선택한 회로를 브리지한다. 원격 유저의 컴퓨터(11811)와 원격 테스트 시스템(11884)은 전술된 것과 같이 IP 호출을 유저가 정의한 IP 목적지 어드레스에 접속하는 인터넷 전화를 용이하게 하는 소프트웨어를 갗춘다.
원격 유저의 컴퓨터(11811)는 적절한 내장형 모뎀 또는 스피커와 마이크의 출력을 지원하는 네트워크 인터페이스 카드(INC)를 갖춘다. 유저는 마이크와 스피커를 갖춘 자신의 헤드폰을 모뎀이나 또는 청각적인 감시 또는 음성 통신 지원을 위해 유저의 컴퓨터(11811)내의 NIC 카드에 직접 플러그를 꽃는다.
본 발명은 인터넷을 통한 데이터 통신 뿐만아니라 음성에 대한 새로운 서비스와 기능을 설명한다. 고객들은 분당 훨씬 낮은 비율로 이 서비스를 청구할 수 있으므로, 모든 다른 장거리 캐리어(carrier)에 비교할 시에 월별 장거리 호출 요금을 줄인다. 이 통신 방법은 현재 인류가 다이얼 호출 음성 및 데이터 통신을 바라보는 방법에 대변혁을 일으킬 것이다. 이 서비스는 본 발명이 규정하는 2가지 단계들로 펼쳐질수 있다. 서버/루트 교환국은 개념적인 장치이고 그리고 내가 제안한 물리적인/가상 통신 방법을 지원하기 위해 개발을 필요로한다.
통상적인, 미국대륙 호출 배치를 설명하기 위한 예제들이 제공된다. 전세계적인 호출에 대해서도 역시 동일하게 적용될 수 있다. 국가 및 도시 코드들은 국가 서버 교환국 도시 목적지의 아웃(out)을 식별하기 위해서 서버 교환국내에 상호 참조표를 갖는다.
도119 - 도표 A
도119는 양호한 실시예를 따르는 호출 흐름도다. 원격 개인 컴퓨터(PC) 유저(11904)는 다이얼 억세스(11902)를 경유하여 인터넷(11905)을 억세스한다. 이 서비스에 가입하는 고객들은 인터넷 억세스 소프트웨어를 갖춘 PC들(11903,11904)을 갖으며, 상기 소프트웨어는 서버 루트 교환국(11906) IP로 호출을 제기하는 소프트웨어에 의해 고객들이 서버 루트 교환국(11906)에 접속 및 억세스하게 하며, 상기 IP는 고객이 제공한 계좌 번호와 암호를 통해 개인을 액티브한 계자로 간주한다. 유저의 PC(11903,11904)는 마이크 기능 뿐만아니라 스피커를 갖춘 적절한 모뎀 유형을 갖는다.
인터넷 전화 소프트웨어는 성공적으로 설치를 하였다는 것을 나타내는 설치 파일들을 갱신하고 그리고 또 다른 PC에 동일한 소프트웨어 패키지에 대한 제2 설치를 허락하지 않을 것이다. 이 검사가 다른 사람들이 프로그램을 불법적으로 이용하는 것을 방지한다. 인터넷 프로그림이 활성화될 시, 유저는 계자 번호, 유저 ID 및 할당된 암호를 입력할 것을 요구받는다. 암호는 문자와 숫자를 조합한 것이고, 이 조합이 권한이 없는 사용자의 프로그램 사용을 어렵게한다. 이 소프트웨어 프로그램은 또한 FAX를 전송에 대한 데이터 모드 또는 음성 통신을 위한 채트(chat) 모드를 허락하게 하기 위한 선택 버튼을 갖는다.
PC(11903 또는 11904)로부터 프로그램을 시작하기 전에, 가령 그들의 유저 계좌 번호, 패스워드, 및 목적지 번호와 같은 개인 정보가 입력되어야 한다. 필드 완료 후, 유저는 전송을 시작하기 위하여 인디시어(indicia)를 선택할 것이다. 직접적인 IP 억세스를 위하여, PC(11903)는 서버 라우트 교환국(11906)과 통신할 것이다. 유저 PC(11904)로부터의 다이얼업 억세스를 위하여, 유저는 먼저 인터넷(11905)과의 다이얼업 접속을 설정할 것이다. 인터넷(11905)으로 그들의 다이얼업 접속(11902)이 일단 설정이 되면, 유저는 인터넷 폰 소프트웨어를 활성화하며 서버 라우트 교환국(11906)으로 IP 호출을 한다. 일단 유저의 PC(11903 또는 11904)가 서버 라우트 교환국(11906)과 IP 접속을 설정하게 되면, 유저의 계좌 번호 및 패스워드가 서버 라우트 교환국(11906)에 의해 액티브한 계좌로 검증된다. 정보 검색이 이루어지면, 서버 라우트 교환국(11906)은 그 호출을 라우팅하는데 이용된 목적지 서버 교환국을 결정하기 위하여, 다이얼된 목적지 번호를 스캔한다. 만일 유저(11903 또는 11904)가 서버 교환국을 갖지 않는 영역 코드 및 NXX를 입력한다면, 유저는 다른 번호에 대하여 적절하게 프롬프트될 것이다.
남 캐롤라이나는, 3개의 서버 교환국을 갖는데, 이들 각각은 찰스턴(11907), 콜롬비아(11908), 및 플로렌스(11909)의 주요 도시에서 사용된다. 워싱턴 D.C.에 있는 다이얼업 고객(11904)은 로컬 루프(11902)를 통하여 인터넷(11905)으로의 접속을 설정한다. 일단 인터넷(11905)으로의 억세스가 설정되면, 유저(11904)는 PC(11904)에 설치된 인터넷 폰 소프트웨어를 활성화한다.
유저(11904)는 인터넷 폰 소프트웨어 내의 적절한 필드에 유저 id, 패스워드, 및 목적지 전화 번호를 입력한다. 정보가 입력된 후, 유저(11904)는 인터넷 폰 프로그램 내의 접속 버튼을 클릭한다. 본 예에서, 유저(11904)는 803-554-9899를 찰스턴 S.C. 전화 번호인 목적지로서 다이얼하였다.
서버 라우트 교환국(11906)은 영역 코드(803)를 검사한 다음, 이 전화 번호가 남 캐롤라이나 서버 교환국 NPA인지를 명확하게 결정하기 위하여 영역 코드(803)를 자체의 알고 있는 서버 라우트 테이블들과 교차 대조한다. 그런 다음, 서버 라우트 교환국은 스캔(554)을 통해 남 캐롤라이나에 대한 NXX 테이블과 교차 대조한 다음, 이것이 찰스턴(11907)에 대한 서버 교환국인지를 결정한다. 서버 라우트 교환국(11906)은 찰스턴 서버 교환국(11907) IP 어드레스에 대한 IP 교차 대조 테이블을 스캔한다. 통화 용량에 따라서, 각 도시는 교환국으로의 IP 노드를 하나 이상 가질 수도 있다. 서버 라우트 교환국은 어떤 노드들이 적은 통화량 노드를 나타내는 최상의 응답 시간을 갖는 지를 결정하기 위하여 각 노드(11910, 11911, 11912 또는 11913)를 핑(ping)한다.
본 예에서는, 노드 어드레스 166.22.784.215(11911)가 최상의 응답을 갖는 것으로 밝혀졌다. 최상의 응답 시간을 갖는 IP 어드레스(11911)가 일단 확인되면, 서버 라우트 교환국(11906)은 인터넷(11905)을 통하여 찰스턴 서버 교환국(11907)에서 노드(11911)에 IP 콜을 설정 한다. 일단 찰스턴 서버 교환국(11907)로의 접속이 설정되면, 서버 라우트 교환국(11906)은 호출 번호로부터 803 NPA를 제거하며, 그 호출을 인터넷(11905)을 통해 피호출 진영의 교환과 함께 위치된 찰스턴 서버 교환국(11907)에 연결한다.
찰스톤 서브 교환국(11907)에는 도 120에 도시된 로컬 텔코 탠덤 교환국(12015) 또는 텔코 중앙국(12106)으로의 다중 FG-A 억세스, 또는 FG-B 직렬 트렁크(11914)가 제공된다. 억세스 라인들(11914) 중의 하나가 선택되어 찰스톤 서버 교환국(11907)에 의해 점유되면, 텔코는 로컬 텔코 중앙국(12016) 또는 탠덤 교환국(12015)로부터 다이얼 톤을 제공할 것이다. 다이얼 톤 검출 후에, 찰스톤 서버 교환국(11907)은 호출 진영(12014)으로부터 피호출 진영(12017)에 가장 가까운 텔코 중앙국(12016)으로 도 120에 도시한 바와 같이, DTMF 또는 MF 수신 숫자들을 다이얼펄스한다. 도 120은 바람직한 실시예에 따른 중앙국의 동작을 상세하게 도시한다.
텔코 중앙국(12016)은 NXX를 그의 통화 영역 내에 있는 것으로서 인정하며, 수신된 숫자 7을 로컬 통화로서 처리하고, 최종 고객의 전화(12017)를 울리게 할 고객의 로컬 루프(12018)에 대하여 통용하는 링 주기(ring cycle)를 배치할 것이다. 피호출 진영이 전화(12017)에 응답하면, 통화 경로는 끊기며 완료된 것으로 간주된다. 이렇게 되면, 호출 진영(11904)은 호출 진영(11904)의 PC를 통하여 피호출 진영(12017)과 음성으로 통화할 수 있게 된다.
이러한 통신 방법은 또한 음성 통신 또는 팩스의 송신을 위하여 PC 대 PC에서 사용될 수 있다. 국제 호출에 대해서도 유사한 구조가 이용될 것이다. 국가 및 도시 코드들은 국가 서버 교환국 IP 목적지를 벗어나는 지를 결정하기 위하여 교차 대조 테이블을 이용하여 인덱스된다.
본 발명에 따른 라우팅 테이블의 예가 하기에 제공된다.
라우트 테이블 표시
NPA: 803: 남 캐롤라이나
NXX: 522: 찰스톤
766: 찰스톤
572: 찰스톤
IP1: 161.22.784.214
IP2: 161.22.784.215
IP3: 161.22.784.216
IP4: 161.22.784.217
730: 콜롬비아
761: 콜롬비아
856: 콜롬비아
IP1: 161.22.796.112
IP2: 161.22.796.113
IP3: 161.22.796.114
IP4: 161.22.796.115
943: 플로렌스
683: 플로렌스
IP1: 161.22.796.122
IP2: 161.22.796.123
IP3: 161.22.796.124
IP4: 161.22.796.125
도 121은 인터넷을 통한 PC 대 PC, PC 대 전화 또는 전화 대 전화 통신을 지원하는 블록도를 도시한다. 이들 유저들은 서버 교환국에 의해 서비스되는 교환 영역 내에 위치될 필요가 있다. 유저의 거주지가 아닌 곳으로부터 이동 및 호출이 있을 때, 유저는 음성 통신에 대해 특정한 800 번 및 PC 통신에 대해 특정한 800번을 호출함으로써 억세스를 얻게 된다.
단계 Ⅱ 구성에서는, 전용 라우트 교환국을 필요로 하지 않는다. 각각의 주요 도시에는 로컬 텔코로/텔코로부터 2가지 방법의 통신을 처리할 수 있는 서버 교환국이 제공될 수 있다. 서버 교환국에는 로컬 텔코로부터의 교환국으로/교환국으로부터의 아웃바운드 뿐 아니라 인바운드를 지원하기 위하여 2가지 방법의 특성 그룹 A 또는 2가지 방법의 FG-B 트렁크가 제공될 수 있다.
PC 유저는 단계 Ⅰ에서 설명된 바 있는 특별하게 개발된 인터넷 폰 소프트웨어 프로그램을 구비할 것이다. 유저는 유저의 주거지가 아닌 곳으로부터 호출이 있을 때 적절한 800번을 입력할 필요가 있다. 인터넷 폰 소프트웨어는 유저가 “거주(residence)”또는 “방랑(roaming)”표시를 선택할 수 있는 선택권을 가지게 할 것이다. 만일 유저가 “거주”를 선택하였다면, 유저는 그들의 주요 원거리 제공자로서 PIC'd 내지 MCI가 되어야 한다. 이렇게 되면 그들의 호출은 동등한 억세스 호출로서 처리될 것이며, 유저 id 및 패스워드 검증은 필요없게 된다. 만일 유저가 “방랑”을 선택했다면, 유저는 원격 PC 억세스를 위하여 적절한 인터넷 폰 필드 800번을 입력하도록 요청 받는다. 유저는 또한 유저 계좌 번호를 입력하도록 요청받는다. 소프트웨어 프로그램은 FAX 및 파일 전송을 전송하기 위한 데이터 모드 또는 음성 통신을 위한 채트 모드를 가능하게 하는 선택 버튼을 가질 수 있다.
가령, 토미제이(12149)와 같은 전화 유저는 그들의 주요 거주지, PIC'd 내지 MCI를 가질 수 있다. 주요 거주지가 아닌 곳으로부터 이동 또는 호출이 있을 때, 유저는 음성 통신용 서버 교환국로의 원격 다이얼을 위한 특별한 800번을 가질 것이다. 그들의 주요 거주지로부터 호출이 있을 때, 그들의 호출은 동등한 억세스 호출로서 처리될 것이다. 주요 거주지가 아닌 곳으로부터 호출이 있을 때, 유저는 음성 통신용 서버 교환국로의 억세스를 위하여 적절한 800번을 다이얼하도록 요청받는다. 서버 교환국로의 접속이 설정되자 마자, 서버 교환국은 유저에게 그들의 계좌 번호를 입력하도록 한다. 일단 서버 교환국이 유저의 계좌 번호를 수신하여 이것을 액티브한 것으로서 검증하면, 유저는 자신이 다이얼하기를 원하는 번호를 입력하도록 요청받을 것이다. 이때, 유저는 그들이 호출하기를 원하는 번호와 7개의 숫자 교환이 뒤따르는 영역 코드를 입력한다. 이 유저는 음성 응답 유닛 (VRU)에 의해 상기 정보를 요청받을 수 있는바, 상기 음성 응답 유닛은 유저 명령을 매우 간략화 시킨다.
유저는 동등한 억세스 또는 800 억세스 라인을 통하여 서버 교환국을 억세스한다. 서버 교환국은 인터넷을 이용하여, 사기 호출된 번호에 대한 탈코 로컬 교환내에서 호출 종료를 위해 유저가 원격 서버 교환국에 도달되도록 한다. 전개 교환국 가상 통신 네트워크(evolution Switched Virtual Commuications network)가 완성된 후의 호출예가 다음에 설명된다. 고객의 견지로부터, 모든 호출들은 그들이 전형적인 표준 IMT 교환국들에 의해서 그랬던것과 다르지 않게 처리된다. 하나의 예외는 모든 호출들이 인터-머신 트렁크보다는 IP 네트워크를 통하여 그들이 목적지 교환국로 라우팅된다는 것이다.
워싱턴 D.C.(12149)에 있는 고객은 그의 원거리 제공자로서 MCI를 가지며, 18035524475를 다이얼한다. 텔코(12151)는 고객의 로컬 루프(12150)로부터 오프를 인지하며, 텔코 중앙국(12151)이 1을 수신하자 마자 고객은 그 호출이 MCI로 라우팅되었음을 알게 된다. 호출은 CO(12151)로부터 텔코 탠덤 교환국(12152)으로 라우팅된다. 텔코 탠덤 교환국(12152)은 호출을 탠덤 억세스 라인(12153)을 통하여 로컬 MCI 서버 교환국(12154)으로 보낸다. MCI 서버 교환국(12154)은 ANI를 MCI 고객으로서 인정하며, 접속이 완료된 다음부터 그 호출에 대한 청구가 시작될 것이다. 서버 교환국(12154)은 NPA로부터 다이얼된 번호를 스캔하며 이를 남 캐롤라이나로서 인정한다. 그런 다음, 서버 교환국(12154)은 NXX를 스캔하며 이를 찰스턴 NXX로서 인정한다. 그런 다음 서버 교환국(12154)은 그의 로직 라우팅 테이블을 스캔하며 찰스턴 서버 교환국(12158)에 대한 적절한 IP 어드레스를 찾는다. 전화량 용량에 의존하는 각 도시는 교환국로의 하나 이상의 IP 노드(12157)를 가질 수도 있다.
서버 교환국(12154)은 어떤 노드가 최상의 응답 시간을 가지며 이에 따라 적은 통화량 부하를 갖는 지를 결정하기 위하여, 각각의 IP 노드(12157)를 핑(ping)할 수 있다. 일단 최상의 응답 시간을 갖는 IP 노드(12157) 어드레스가 확인되면, 서버 교환국(12154)은 인터넷(12156)을 통하여 확인된 노드(12155)로 찰스턴 서버 교환국(12158)에 IP 호출을 한다. 찰스턴 서버 교환국(12158)과의 접속이 일단 설정되면, 워싱턴 서버 교환국(12154)은 803 NPA를 제거하고, 찰스턴 서버 교환국(12158)에 524475를 전송한다. 찰스턴 서버 교환국(12158)은 그의 물리적인 라우팅 테이블 및 그의 로컬 교환으로 확인된 552를 스캔한다. 찰스턴 서버 교환국(12158)은 로컬 텔코 탠덤 교환국(12160)으로의 FG-A/FG-B 탠덤 트렁크들(12159) 중의 하나를 점유한다. 그런 다음 로컬 텔코 탠덤 교환국(12160)은 5524475의 전화 번호 계좌(12163)를 갖는 고객에 서비스하는 적절한 텔코 CO(12161)에 호출된 숫자들을 라우팅한다.
로컬 CO(12161)는 탠덤 교환국(12160)로부터 호출된 숫자들을 받으며, 5524475에 대한 트렁크(12162)를 점유하고, 고객 라인(12162)상에 링 주기(ring cycle)을 설정한다. 찰스턴 목적지(12163)에서 호출에 응답하자 마자, 호출은 완료된 것으로 간주되며 워싱턴 D.C. 서버 교환국 (12154)으로부터 청구가 시작된다. 워싱턴 D.C.(12149) 및 찰스턴(12163)의 목적지 위치에서의 고객은 이제 음성 통신할 수 있게 된다.
지금까지 여러가지 실시예에 대해 설명하였지만은 이들은 단지 예를 든것으로 어떤 제한을 갖는 것이 아니다. 따라서, 바람직한 실시예의 범위는 상기한 실시예에 국한되지 않고 다음의 청구범위 및 이의 균등범위에 따라 한정되어야 할 것이다.
색 인
Claims (45)
- 하이브리드 통신 시스템으로서,교환 통신 네트워크와;상기 교환 통신 네트워크에 연결되는 패킷 전송 네트워크와;상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크에 연결되는 호출 라우터와; 그리고상기 호출 라우터에 연결되며, 호출 제어 파라메터 데이타베이스를 저장하는 메모리를 구비하며,상기 호출 라우터가 상기 호출 제어 파라메터 데이타베이스로부터의 적어도 하나의 호출 파라메터에 근거하여 상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크를 통해 호출을 라우팅하도록 된 하이브리드 통신 시스템.
- 제 1항에 있어서,상기 호출 파라메터 데이타베이스가 상기 하이브리드 통신 시스템의 가입자에 관한 프로파일 정보를 구비하는 하이브리드 통신 시스템.
- 제1항에 있어서,상기 호출 파라메터 데이타베이스가 호출 타입에 관한 정보를 구비하는 하이브리드 통신 시스템.
- 제1항에 있어서,상기 호출 파라메터 데이타베이스가 상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크의 사용에 관한 정보를 구비하는 하이브리드 통신 시스템.
- 제1항에 있어서,상기 호출 파라메터 데이타베이스가 상기 호출의 시간에 관한 정보를 구비하는 하이브리드 통신 시스템.
- 제5항에 있어서,상기 패킷 전송 네트워크가 인터넷을 구비하는 하이브리드 통신 시스템.
- 제1항에 있어서,상기 교환 통신 네트워크가 공용 회선 교환 통신 네트워크를 구비하는 하이브리드 통신 시스템.
- 제1항에 있어서,상기 공용 회선 교환 통신 네트워크가 전화 네트워크인 하이브리드 통신 시스템.
- 교환 통신 네트워크와 패킷 전송 네트워크를 포함하는 하이브리드 통신 시스템에서의 호출 설정 방법으로서,메모리에 호출 파라메터 데이타베이스를 저장하는단계와;상기 하이브리드 통신 시스템에서 호출을 수신하는 단계와;적어도 하나의 호출 파라메터를 결정하기 위해 상기 호출 파라메터 데이타베이스를 억세스 하는 단계와; 그리고상기 적어도 하나의 호출 파라메터에 근거하여 상기 교환 통신 네트워크와 상기 패킷 전송 네트워크를 통해 상기 호출을 라우팅하는 단계를 구비하는 호출 설정 방법.
- 제9항에 있어서,상기 호출 파라메터 데이타베이스가 상기 하이브리드 통신 시스템의 가입자에 관한 정보를 구비하는 호출 설정방법
- 제9항에 있어서,상기 호출 파라메터 데이타베이스가 호출 타입에 관한 정보를 구비하는 호출 설정 방법.
- 제9항에 있어서,상기 호출 파라메터 데이타베이스가 상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크의 사용에 관한 정보를 구비하는 호출 설정방법.
- 제9항에 있어서,상기 호출 파라메터 데이타베이스가 상기 호출의 시간에 관한 정보를 구비하는 호출 설정방법.
- 제9항에 있어서,상기 패킷 전송 네트워크가 인터넷을 구비하는 호출 설정방법.
- 제14항에 있어서,상기 교환 통신 네트워크가 공용 회선 교환 통신 네트워크를 구비하는 호출 설정방법.
- 제15항에 있어서,상기 공용 회선 교환 통신 네트워크가 전화 네트워크인 호출 설정방법.
- 교환 통신 네트워크와 패킷 전송 네트워크를 포함하는 하이브리드 통신 시스템에서 호출을 설정하기위한 컴퓨터로 판독 가능한 매체상에 수록된 컴퓨터 프로그램으로서,호출 파라메터 데이타베이스를 메모리에 저장하기 위한 제1 소프트웨어와;상기 하이브리드 통신 시스템이 적어도 하나의 호출 파라메터를 결정하기 위해 호출을 수신할 때, 상기 호출 파라메터 데이타베이스를 억세스 하는 제2 소프트웨어와; 그리고상기 적어도 하나의 호출 파라메터를 근거로 상기 교환 통신 네트워크와 상기 패킷 전송 네트워크를 통해 상기 호출을 라우팅하는 제3 소프트웨어를 구비하는 컴퓨터 프로그램.
- 제17항에 있어서,상기 호출 파라메터 데이타베이스가 상기 하이브리드 통신 시스템의 가입자에 관한 프로파일 정보를 구비하는 컴퓨터 프로그램.
- 제17항에 있어서,상기 호출 파라메터 데이타베이스가 호출 타입에 관한 정보를 구비하는 컴퓨터 프로그램.
- 제17항에 있어서,상기 호출 파라메터 데이타베이스가 상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크의 사용에 관한 정보를 구비하는 컴퓨터 프로그램.
- 제17항에 있어서,상기 호출 파라메터 데이타베이스가 상기 호출의 시간에 관한 정보를 구비하는 컴퓨터 프로그램.
- 제17항에 있어서,상기 패킷 전송 네트워크가 인터넷을 구비하는 컴퓨터 프로그램.
- 제22항에 있어서,상기 교환 통신 네트워크가 공용 회선 교환 통신 네트워크를 구비하는 컴퓨터 프로그램.
- 제23항에 있어서,상기 공용 회선 교환 통신 네트워크가 전화 네트워크인 컴퓨터 프로그램.
- 하이브리드 통신 시스템으로서교환 통신 네트워크와;상기 교환 통신 네트워크에 연결되는 패킷 전송 네트워크와;상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크에 연결되는 호출 라우터와;상기 교환 통신 네트워크와 상기 패킷 전송 네트워크의 통신에서, 부착된 디스플레이를 갖는 컴퓨터를 구비하며,상기 컴퓨터가 상기 하이브리드 통신 시스템의 원격 관리를 개시하도록 구성된 하이브리드 통신 시스템.
- 제25항에 있어서,상기 하이브리드 통신 시스템에 대한 테스트를 개시할 수 있는 콜백 로직을 구비하는 하이브리드 통신 시스템.
- 제25항에 있어서,상기 테스트는 회로 분석을 포함하는 하이브리드 통신 시스템.
- 제25항에 있어서,루프 스타트, 그라운드 스타트와 같은 신호 상태를 선택하거나 또는 두얼톤 다중 주파수 검출, 다중 주파수 또는 다이얼 펄스와 같은 신호상태를 선택하는 관리 장치를 더 구비하는 하이브리드 통신 시스템.
- 제25항에 있어서,상기 하이브리드 통신 시스템이 인터넷 전화에 대한 지원을 포함하는 하이브리드 통신 시스템.
- 제25항에 있어서,오퍼레이터가 상기 하이브리드 네트워크의 관리를 감시할 수 있게 하는 수단을 구비하는 하이브리드 통신 시스템.
- 제25항에 있어서,상기 하이브리드 통신 시스템의 서비스 품질을 조정하는 전문가 시스템을 더 구비하는 하이브리드 통신 시스템.
- 하나 이상의 패킷 전송 네트워크에 연결되는 하나 이상의 교환 네트워크를 포함하는 하이브리드 통신 시스템에서 통신을 인에이블하는 방법으로써,상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크에 호출 라우터를 연결하는 단계와;상기 패킷 네트워크와 교신하도록 컴퓨터를 부착된 디스플레이와 합체하는 단계를 구비하며, 상기 컴퓨터는 하이브리드 통신 시스템의 원격 관리를 개시할 수 있도록 된 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제32항에 있어서,상기 하이브리드 통신 시스템의 테스트를 개시하기 위해 콜백 로직을 사용하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제 33항에 있어서,상기 테스트가 회로 분석을 포함하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제32항에 있어서,루프 스타트, 그라운드 스타트와 같은 신호 상태를 선택하거나 또는 듀얼 톤 다중 주파수, 다중 주파수 또는 다이얼 펄스와 같은 신호들을 검출하므로써 하이브리드 통신 시스템을 관리하는 단계를 더 구비하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제32항에 있어서,상기 하이브리드 통신 시스템이 인터넷전화에 대한 지원을 포함하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제32항에 있어서,오퍼레이터가 상기 하이브리드 통신 시스템의 관리를 감시하는 단계를 더 구비하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 제32항에 있어서,하이브리드 통신 시스템의 서비스 품질을 조정하기 위하여 전문가 시스템을 이용하는 단계를 구비하는 하이브리드 통신 시스템에서의 통신 인에이블 방법.
- 하나 이상의 패킷 전송 네트워크에 연결되는 하나 이상의 교환 네트워크를 포함하는 하이브리드 통신 시스템에서 통신을 인에이블 하는 컴퓨터 독출가능 매체에 수록되는 컴퓨터 프로그램으로서,(a) 상기 교환 통신 네트워크 및 상기 패킷 전송 네트워크에 호출 라우터를 연결하는 제1 소프트웨어와;(b) 상기 패킷 네트워크와 교신하며, 상기 하이브리드 통신 시스템의 원격 관리를 개시하는 제2 소프트웨어를 구비하는 컴퓨터 프로그램.
- 제39항에 있어서,상기 하이브리드 통신 시스템의 테스트를 개시하기 위해 콜백 로직을 더 포함하는 컴퓨터 프로그램.
- 제 40항에 있어서,상기 테스트가 회로 분석을 포함하는 컴퓨터 프로그램.
- 제39항에 있어서,루프 스타트, 그라운드 스타트와 같은 신호 상태를 선택하거나 또는 듀얼 톤 다중 주파수, 다중 주파수 또는 다이얼 펄스와 같은 신호들을 검출하는 관리 소프트웨어를 더 구비하는 컴퓨터 프로그램.
- 제39항에 있어서,상기 하이브리드 통신 시스템이 인터넷 전화에 대한 지원을 포함하는 컴퓨터 프로그램.
- 제39항에 있어서,오퍼레이터가 상기 하이브리드 통신 시스템의 관리를 감시할 수 있게 하는 오퍼레이터 소프트웨어를 더 구비하는 컴퓨터 프로그램.
- 제39항에 있어서,상기 하이브리드 통신 시스템이 하이브리드 통신 시스템의 서비스 품질을 조정하는 전문가 시스템을 포함하는 컴퓨터 프로그램.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US83578997A | 1997-04-15 | 1997-04-15 | |
| US83432097A | 1997-04-15 | 1997-04-15 | |
| US08/834,320 | 1997-04-15 | ||
| US08/835,789 | 1997-04-15 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20010006455A true KR20010006455A (ko) | 2001-01-26 |
Family
ID=27125701
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1019997009545A KR20010006455A (ko) | 1997-04-15 | 1998-04-15 | 교환 전화 통신용 시스템, 방법 및 그 제조물 |
Country Status (13)
| Country | Link |
|---|---|
| EP (1) | EP0976234A2 (ko) |
| JP (1) | JP2001521695A (ko) |
| KR (1) | KR20010006455A (ko) |
| CN (1) | CN1271491A (ko) |
| AP (1) | AP9901678A0 (ko) |
| AU (1) | AU738963B2 (ko) |
| BR (1) | BR9808592A (ko) |
| CA (1) | CA2286132A1 (ko) |
| IL (1) | IL132397A (ko) |
| NO (1) | NO995042L (ko) |
| NZ (1) | NZ500383A (ko) |
| TR (1) | TR199902599T2 (ko) |
| WO (1) | WO1998047298A2 (ko) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100841997B1 (ko) * | 2003-08-12 | 2008-06-27 | 박종도 | 무료통화권 서비스 시스템 |
| WO2010058908A2 (ko) * | 2008-11-24 | 2010-05-27 | 한국과학기술원 | 다중 인터페이스를 탑재한 이동 단말 및 멀티미디어 스트리밍 수신 방법, 다중 망을 이용한 멀티미디어 스트리밍 제공 서버 및 그 방법 |
| US7738531B2 (en) | 2000-07-19 | 2010-06-15 | Qualcomm Incorporated | Method and apparatus for reducing code phase search space |
| KR101027357B1 (ko) * | 2001-05-31 | 2011-04-11 | 퀄컴 인코포레이티드 | 무선 통신 장치용 데이터 관리자 및 무선 장치에서데이터를 관리하는 방법 |
| KR101470976B1 (ko) * | 2013-12-03 | 2014-12-09 | 주식회사 안동통신 | 스쿨존 cctv 감시장치 성능개선 시스템 |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6529594B1 (en) | 1998-06-05 | 2003-03-04 | Inet Technologies, Inc. | System and method for generating quality of service statistics for an international communications network |
| US6411604B1 (en) | 1998-06-05 | 2002-06-25 | Inet Technologies, Inc. | System and method for correlating transaction messages in a communications network |
| ATE324006T1 (de) * | 1999-01-08 | 2006-05-15 | Netnumber Com Inc | Verfahren und gerät zur korrelation eines einzigartigen identifizierers, wie z.b. eine pstn telefonnummer, an eine internetadresse zur kommunikation über das internet |
| US6791970B1 (en) * | 1999-02-11 | 2004-09-14 | Mediaring Ltd. | PC-to-phone for least cost routing with user preferences |
| WO2000054468A2 (en) * | 1999-03-10 | 2000-09-14 | Inet Technologies, Inc. | System and method for providing interoperability between circuit-switched and packet networks |
| WO2000062519A2 (en) | 1999-04-09 | 2000-10-19 | General Instrument Corporation | Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification |
| US6556659B1 (en) * | 1999-06-02 | 2003-04-29 | Accenture Llp | Service level management in a hybrid network architecture |
| US6775277B1 (en) | 1999-06-04 | 2004-08-10 | Nortel Networks Limited | Methods and systems for processing calls in a packet network using peer call servers |
| US6791975B1 (en) | 1999-06-29 | 2004-09-14 | Siemens Information & Communication Networks, Inc. | Call signature in a packet-based network |
| US8464302B1 (en) | 1999-08-03 | 2013-06-11 | Videoshare, Llc | Method and system for sharing video with advertisements over a network |
| US6611867B1 (en) * | 1999-08-31 | 2003-08-26 | Accenture Llp | System, method and article of manufacture for implementing a hybrid network |
| WO2001017169A2 (en) * | 1999-08-31 | 2001-03-08 | Accenture Llp | A system, method and article of manufacture for a network-based predictive fault management system |
| US8271336B2 (en) | 1999-11-22 | 2012-09-18 | Accenture Global Services Gmbh | Increased visibility during order management in a network-based supply chain environment |
| WO2001039030A2 (en) * | 1999-11-22 | 2001-05-31 | Accenture Llp | Network and life cycle asset management in an e-commerce environment and method thereof |
| WO2001039086A2 (en) * | 1999-11-22 | 2001-05-31 | Accenture Llp | Technology sharing during asset management and asset tracking in a network-based supply chain environment and method thereof |
| KR100338683B1 (ko) * | 1999-12-29 | 2002-05-30 | 정 데이비드 | 통합 아이피 콜 라우팅 시스템 |
| US7801157B2 (en) | 2000-02-18 | 2010-09-21 | Nortel Networks Limited | Methods and systems for processing calls in a packet network using peer call servers |
| US20020056123A1 (en) | 2000-03-09 | 2002-05-09 | Gad Liwerant | Sharing a streaming video |
| ATE424690T1 (de) * | 2000-04-13 | 2009-03-15 | Verizon Lab Inc | System zur bereitstellung integrierter dienste über ein computernetzwerk |
| FR2809563B1 (fr) * | 2000-05-26 | 2004-08-27 | Schlumberger Systems & Service | Procede de gestion d'un reseau de telephonie publique permettant d'acceder a internet, telephone public et serveur de gestion pour sa mise en oeuvre |
| FR2812151A1 (fr) * | 2000-07-20 | 2002-01-25 | Infoleague | Procede pour l'echange de donnees multimedias |
| JP3494168B2 (ja) | 2001-06-25 | 2004-02-03 | 日本電気株式会社 | パケットパス監視方式及び装置 |
| DE10201649B4 (de) * | 2002-01-17 | 2005-02-17 | Siemens Ag | Anordnung zur Überwachung von Komponenten in einem Kommunikationsnetz |
| JP3917454B2 (ja) * | 2002-04-17 | 2007-05-23 | 株式会社ナカヨ通信機 | Ｉｐ通信システムにおけるｉｐアドレス登録方法および該ｉｐ通信システムを構成するゲートキーパーならびにｉｐ端末装置 |
| DE50303492D1 (de) * | 2002-07-02 | 2006-06-29 | Siemens Ag | Überprüfung der übertragungsqualität in paketbasierten netzen |
| US7372826B2 (en) | 2002-08-01 | 2008-05-13 | Starent Networks, Corp. | Providing advanced communications features |
| JP4627760B2 (ja) * | 2004-11-02 | 2011-02-09 | 富士通株式会社 | 通信中継方法、通信中継プログラムおよび通信中継装置 |
| US8756328B2 (en) | 2005-01-19 | 2014-06-17 | Qualcomm Connected Experiences, Inc. | Caller-callee association of a plurality of networked devices with direct dial through thin client |
| US8856359B2 (en) | 2005-06-29 | 2014-10-07 | Qualcomm Connected Experiences, Inc. | Caller-callee association of a plurality of networked devices |
| US8351419B2 (en) | 2005-01-19 | 2013-01-08 | Qualcomm Iskoot, Inc. | Local access to a mobile network |
| US7746997B2 (en) * | 2005-10-07 | 2010-06-29 | Avaya Inc. | Interactive telephony trainer and exerciser |
| US9479604B2 (en) | 2006-01-30 | 2016-10-25 | Qualcomm Incorporated | System and method for dynamic phone book and network content links in a mobile device |
| US8059641B1 (en) | 2006-07-20 | 2011-11-15 | Avaya Inc. | Encapsulation method discovery protocol for network address translation gateway traversal |
| US10885543B1 (en) | 2006-12-29 | 2021-01-05 | The Nielsen Company (Us), Llc | Systems and methods to pre-scale media content to facilitate audience measurement |
| US8805325B2 (en) | 2007-01-08 | 2014-08-12 | Qualcomm Connected Experiences, Inc. | Methods and systems of implementing call-cost features on a mobile device |
| WO2008086412A2 (en) | 2007-01-09 | 2008-07-17 | Iskoot, Inc. | Method and system for transmitting audio data between computing devices |
| CN101237333B (zh) * | 2007-01-31 | 2011-06-29 | 北京邮电大学 | 一种基于多网络融合的支持多种业务的通用业务平台 |
| US9100501B2 (en) | 2007-02-12 | 2015-08-04 | Qualcomm Incorporated | Methods and systems for performing authentication and authorization in a user-device environment |
| US8391848B2 (en) | 2007-06-07 | 2013-03-05 | Qualcomm Iskoot, Inc. | Telecommunication call support for mobile devices with presence features |
| US8792118B2 (en) | 2007-09-26 | 2014-07-29 | Ringcentral Inc. | User interfaces and methods to provision electronic facsimiles |
| US8600391B2 (en) | 2008-11-24 | 2013-12-03 | Ringcentral, Inc. | Call management for location-aware mobile devices |
| US8670545B2 (en) | 2007-09-28 | 2014-03-11 | Ringcentral, Inc. | Inbound call identification and management |
| US8275110B2 (en) | 2007-09-28 | 2012-09-25 | Ringcentral, Inc. | Active call filtering, screening and dispatching |
| WO2010062981A2 (en) | 2008-11-26 | 2010-06-03 | Ringcentral, Inc. | Centralized status server for call management of location-aware mobile devices |
| CN102495619B (zh) * | 2011-12-29 | 2013-08-28 | 深圳市再丰达科技有限公司 | 停车场管理系统 |
| CN103369292B (zh) * | 2013-07-03 | 2016-09-14 | 华为技术有限公司 | 一种呼叫处理方法及网关 |
| TW201601407A (zh) | 2014-06-24 | 2016-01-01 | 萬國商業機器公司 | 電源分配單元與用於其之警示方法 |
| CN105225388A (zh) * | 2014-06-28 | 2016-01-06 | 陈娇 | 一种视网膜识别报警系统 |
| US9674057B2 (en) | 2014-10-07 | 2017-06-06 | At&T Intellectual Property I, L.P. | Method and system to monitor a network |
| CN106101143A (zh) * | 2016-08-04 | 2016-11-09 | 广州中国科学院沈阳自动化研究所分所 | 一种全方位船舶内部ip通讯系统及通讯方法 |
| US11257155B2 (en) * | 2018-08-27 | 2022-02-22 | Chicago Mercantile Exchange Inc. | Apparatuses, methods and systems for a computationally efficient volatility index platform |
| CN109344353B (zh) * | 2018-09-12 | 2021-10-08 | 福建天泉教育科技有限公司 | 一种可配置化的本地缓存刷新方法及终端 |
| CN109253808B (zh) * | 2018-10-26 | 2020-04-21 | 上海星秒光电科技有限公司 | 时间符合计数系统、方法及装置 |
| US10805690B2 (en) | 2018-12-04 | 2020-10-13 | The Nielsen Company (Us), Llc | Methods and apparatus to identify media presentations by analyzing network traffic |
| US10917454B1 (en) | 2019-08-01 | 2021-02-09 | Rohde & Schwarz Gmbh & Co. Kg | System and method for ATC voice quality assurance |
| CN110888731B (zh) * | 2019-12-09 | 2023-07-07 | 北京博睿宏远数据科技股份有限公司 | 路由数据采集方法、装置、设备及存储介质 |
| CN111078798B (zh) * | 2019-12-27 | 2024-01-30 | 上海莉莉丝科技股份有限公司 | 分布式数据处理系统、方法、服务器及计算机可读存储介质 |
| CN113810517B (zh) * | 2020-03-17 | 2023-11-21 | 腾讯科技（深圳）有限公司 | 多链路设备mac地址管理方法和多链路设备 |
| CN111654864B (zh) * | 2020-06-15 | 2023-05-26 | 河北幸福消费金融股份有限公司 | 二次鉴权方法及相关设备 |
| CN113467906B (zh) * | 2021-06-18 | 2024-05-17 | 北京达佳互联信息技术有限公司 | 图片处理方法、装置、设备及存储介质 |
| US20230206368A1 (en) * | 2021-12-29 | 2023-06-29 | Advanced Micro Devices, Inc. | Disabling selected ip |
| CN114554353B (zh) * | 2022-02-24 | 2024-01-16 | 北京小米移动软件有限公司 | 音频处理方法、装置、设备及存储介质 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5440620A (en) * | 1992-08-28 | 1995-08-08 | At&T Corp. | Telecommunications system subscriber profile updating |
| US5615225A (en) * | 1994-02-09 | 1997-03-25 | Harris Corporation | Remote measurement unit containing integrated line measurement and conditioning functionality for performing remotely commanded testing and conditioning of telephone line circuits |
| EP0767568A2 (en) * | 1995-10-03 | 1997-04-09 | AT&T Corp. | Method and apparatus for processing telephone calls |
| EP1059814B1 (en) * | 1995-12-11 | 2005-11-02 | Hewlett-Packard Company, A Delaware Corporation | Method of providing telecommunication services |
| US7336649B1 (en) * | 1995-12-20 | 2008-02-26 | Verizon Business Global Llc | Hybrid packet-switched and circuit-switched telephony system |
| WO1997028628A1 (en) * | 1996-01-31 | 1997-08-07 | Labs Of Advanced Technologies International Corporation | Hybrid network for real-time phone-to-phone voice communications |
| DE59610895D1 (de) * | 1996-04-17 | 2004-02-19 | Siemens Ag | Steuerungseinrichtung im Intelligenten Netz |
| IL129974A0 (en) * | 1996-11-18 | 2000-02-29 | Mci Worldcom Inc | A communication system architecture |
-
1998
- 1998-04-15 AU AU72511/98A patent/AU738963B2/en not_active Ceased
- 1998-04-15 WO PCT/US1998/007927 patent/WO1998047298A2/en not_active Application Discontinuation
- 1998-04-15 KR KR1019997009545A patent/KR20010006455A/ko not_active Application Discontinuation
- 1998-04-15 BR BR9808592-1A patent/BR9808592A/pt not_active IP Right Cessation
- 1998-04-15 NZ NZ500383A patent/NZ500383A/xx unknown
- 1998-04-15 AP APAP/P/1999/001678A patent/AP9901678A0/en unknown
- 1998-04-15 JP JP54436998A patent/JP2001521695A/ja active Pending
- 1998-04-15 IL IL13239798A patent/IL132397A/en not_active IP Right Cessation
- 1998-04-15 EP EP98919806A patent/EP0976234A2/en not_active Withdrawn
- 1998-04-15 TR TR1999/02599T patent/TR199902599T2/xx unknown
- 1998-04-15 CN CN98806251A patent/CN1271491A/zh active Pending
- 1998-04-15 CA CA002286132A patent/CA2286132A1/en not_active Abandoned
-
1999
- 1999-10-15 NO NO995042A patent/NO995042L/no not_active Application Discontinuation
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7738531B2 (en) | 2000-07-19 | 2010-06-15 | Qualcomm Incorporated | Method and apparatus for reducing code phase search space |
| KR101027357B1 (ko) * | 2001-05-31 | 2011-04-11 | 퀄컴 인코포레이티드 | 무선 통신 장치용 데이터 관리자 및 무선 장치에서데이터를 관리하는 방법 |
| KR100841997B1 (ko) * | 2003-08-12 | 2008-06-27 | 박종도 | 무료통화권 서비스 시스템 |
| WO2010058908A2 (ko) * | 2008-11-24 | 2010-05-27 | 한국과학기술원 | 다중 인터페이스를 탑재한 이동 단말 및 멀티미디어 스트리밍 수신 방법, 다중 망을 이용한 멀티미디어 스트리밍 제공 서버 및 그 방법 |
| WO2010058908A3 (ko) * | 2008-11-24 | 2010-07-15 | 한국과학기술원 | 다중 인터페이스를 탑재한 이동 단말 및 멀티미디어 스트리밍 수신 방법, 다중 망을 이용한 멀티미디어 스트리밍 제공 서버 및 그 방법 |
| KR101470976B1 (ko) * | 2013-12-03 | 2014-12-09 | 주식회사 안동통신 | 스쿨존 cctv 감시장치 성능개선 시스템 |
Also Published As
| Publication number | Publication date |
|---|---|
| NZ500383A (en) | 2002-09-27 |
| CN1271491A (zh) | 2000-10-25 |
| IL132397A (en) | 2004-07-25 |
| EP0976234A2 (en) | 2000-02-02 |
| AP9901678A0 (en) | 1999-12-31 |
| AU738963B2 (en) | 2001-10-04 |
| WO1998047298A3 (en) | 1999-05-14 |
| AU7251198A (en) | 1998-11-11 |
| CA2286132A1 (en) | 1998-10-22 |
| IL132397A0 (en) | 2001-03-19 |
| WO1998047298A2 (en) | 1998-10-22 |
| BR9808592A (pt) | 2001-07-31 |
| NO995042L (no) | 1999-12-14 |
| TR199902599T2 (xx) | 2001-02-21 |
| JP2001521695A (ja) | 2001-11-06 |
| NO995042D0 (no) | 1999-10-15 |
| WO1998047298A9 (en) | 1999-10-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR20010006455A (ko) | 교환 전화 통신용 시스템, 방법 및 그 제조물 | |
| US8094647B2 (en) | System and method for providing requested quality of service in a hybrid network | |
| US7145898B1 (en) | System, method and article of manufacture for selecting a gateway of a hybrid communication system architecture | |
| US5867494A (en) | System, method and article of manufacture with integrated video conferencing billing in a communication system architecture | |
| KR20000071228A (ko) | 통신 시스템 아키텍쳐 | |
| US6754181B1 (en) | System and method for a directory service supporting a hybrid communication system architecture | |
| KR20000069024A (ko) | 통신 시스템 아키텍쳐 | |
| US6731625B1 (en) | System, method and article of manufacture for a call back architecture in a hybrid network with support for internet telephony | |
| US5999525A (en) | Method for video telephony over a hybrid network | |
| US6909708B1 (en) | System, method and article of manufacture for a communication system architecture including video conferencing | |
| US5867495A (en) | System, method and article of manufacture for communications utilizing calling, plans in a hybrid network | |
| US7457279B1 (en) | Method, system, and computer program product for managing routing servers and services | |
| US7123608B1 (en) | Method, system, and computer program product for managing database servers and service | |
| US6760324B1 (en) | Method, system, and computer program product for providing voice over the internet communication | |
| JP2001520820A (ja) | 通信システム構造 | |
| CN1294812A (zh) | 一种通信系统体系结构 | |
| JP2002505043A (ja) | 通信システム構造 | |
| WO2001020859A1 (en) | System for managing routing servers and services | |
| AU6259298A (en) | A communication system architecture | |
| MXPA99007165A (en) | A communication system architecture | |
| WO2001072025A2 (en) | Method, system, and computer program product for managing routing and database servers and services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PA0105 | International application |
Patent event date: 19991015 Patent event code: PA01051R01D Comment text: International Patent Application |
|
| PG1501 | Laying open of application | ||
| A201 | Request for examination | ||
| PA0201 | Request for examination |
Patent event code: PA02012R01D Patent event date: 20030415 Comment text: Request for Examination of Application |
|
| E902 | Notification of reason for refusal | ||
| PE0902 | Notice of grounds for rejection |
Comment text: Notification of reason for refusal Patent event date: 20050520 Patent event code: PE09021S01D |
|
| E601 | Decision to refuse application | ||
| PE0601 | Decision on rejection of patent |
Patent event date: 20050729 Comment text: Decision to Refuse Application Patent event code: PE06012S01D Patent event date: 20050520 Comment text: Notification of reason for refusal Patent event code: PE06011S01I |