Здравейте, седнах да напиша този документ с идеята да е в помощ на тези, които сега навлизат в IP телефонията, или са решили да навлизат, или се чудят дали и как да навлязат. Изборът на доставчик на IP телефония е като изборът на кола - почти винаги първият път се бърка и ако сбъркате главоболията са повече от удобствата. Не претендирам доколко е меродавно моето мнение и опитът, който споделям. Който смята, че го нямам - нищо против, просто да прескочи текста. Ще се постарая да го напиша на обясним език, за да го разбират и тези, които още не са наясно технически с нещата (все пак се предполага, че тези, които са много наясно, вече са си пробили път и нямат нужда от подобни "помагала" и "букварчета"). Carrier или provider/доставчик ще наричаме фирмата, към която вие ще изпращате вашите разговори по IP, а те от своя страна ще ги "терминират/ приземяват" (без да обсъждаме темата дали го правят директно или не). Ще срешнете терминате "A-Z". A-Z доставчик е този, който предлага терминиране на разговорите ви до всички дестинации. Имайте в предвид, че 90% (ако не всички) от провайдерите работят с депозит, t.e. prepaid. Изпращате някаква сума като депозит при тях и започвате да изпращате разговори докато не свърши депозита. Депозита варира от $200 до $10,000. Малките компании, които купуват от Големите и после препродават, биха се съгласили и на $200 депозит. Големите обаче (като Genuity, Level3, KPN, TeleGlobe, MCI и т.н.), които имат висококачествени дестинации с добър ASR (Average Seizure Ratio) и ДОБРИ ЦЕНИ, в никакъв случай не биха приели да си губят времето с "дребни риби". При такива като тях депозита варира от над $2000 до $10,000. Трябва да се пазите и от огромния брой cyber-crooks, които щъкат из форумите и които се прехранват с измама. Най-често това са иранци, бангладешци, индийци, пакистанци (това е факт, моля да не се счита като проява на расизъм), които публикуват убийствени цени с обещание за убийствено качество. След като се разберете за тест, те ви включват към gateway, директно свързан към телефонната мрежа на местния телекомуникационен оператор и вие получавате впечатляващи резултати от теста. Веднага се договаряте с него и изпращате тлъста сума за депозит. След това има два варианта: * Човека изчезва напълно * Получавате нискокачествени "канали" (с ASR около 20%), напълно неизбираеми дестинации и т.н. и т.н. И в почти всички случаи - забравете да ви върнат парите :) Технически детайли, за които би трябвало да се осведомите, преди да се "обвържете" с доставчика. В противен случай рискувате да потрошите време, нерви и евентуално изгубени/ядосани клиенти. Задайте тези въпроси директно на доставчика и изискайте писмен/електронен отговор, за да имате отговора му после като доказателство. 1. Какъв тип "кодеци" се поддържат от негова страна? Някои от voice gateway'ите не поддържат autonegotiation (договаряне) на кодека, а само твърдо конфигуриране на един кодек. Ако доставчикът ви не го поддържа, ще изгубите клиента с такова устройство, или просто няма да можете да използвате това устройство. G729 и G723 (6.3 версията) са абсолютно задължителни. Препоръчително е да има и поддръжка на G711u/a-law за краен случай (или за клиент с широк канал, който изключително много държи на качеството). Добре е да се отбележи, че има няколко варианта на G729 (G729A, G729, G729AB), но за щастие те са съвместими един с друг. oshte za codecs, tablica za smiatane na bandwidth. VAD i .t.n. cisco DSP, kompresia. 2. Има ли поддръжка на T.38 факс протокола (и на каква максимална скорост)? Честно казано, досега почти не съм срещал VoIP провайдер, който да поддържа факс до ВСИЧКИ дестинации, затова изискайте от него по възможност списък с дестинациите, за които е сигурно, че поддържат T.38. 3. Освен H.323 протокола (който е най-масово използваният при VoIP мрежите засега), кои други протоколи се поддържат? SIP, MGCP, IAX (касае Ви ако имате, или планирате да използватe Asterisk PBX)? За H.323 е добре да се знае и коя версия е. Най-новата за момента е v5, но още не е влязла в употреба, на ниво "одобрение" е. Така че приемаме най-новата за v4. Препоръчително е версията да е от v2 нагоре. 4. Запитайте го дали поддържа H.323/SIP/MGCP клиенти зад NAT (ако Вие самият сте зад NAT, иначе не Ви интересува). 5. Поддържат ли "Fast start" и "H245 tunelling"? Ако да, то това би било добре, защото ще съкрати времето за изграждане на връзката (не чак толкова осезаемо, на практика). 6. По какъв начин е възможно/ще бъдете автентикирани? * IP адрес * H.323 ID (поддържат ли CAT / H.235 автентикация?) * tech-префикс (пред всеки изпратен към тях от вас номер се поставя определен префикс, по който те ви разпознават). * ANI/CLI/DNIS (т.е. разпознават ви по "викащия номер", който може ръчно да конфигурирате във Вашия voice gateway). 7. Какви са възможните начини за "interconnect" с тях? * Регистриране в гейткипъра им като H.323 терминал (RRQ) * Директна връзка gateway-към-gateway (Direct H.225 signalling) * връзка гейткипър-гейткипър (LRQ, remote zone routing) Ако се регистрирате като терминал в гейткипъра на доставчика си, това значи че всичките изходящи разговори от вашето "оборудване" (gateway, гейткипър) безусловно ще бъдат изпращани към гейткипъра на доставчика Ви, което понякога не е желателно, ако искате да имате няколко маршрута към различни доставчици (например да изберете български доставчик за разговорите ви към България). 8. Разполага ли доставчикът с web базирана система за таксуване в реално време, откъдето вие във всеки момент може да направите справка за разговорите (CDR), дължими суми и т.н. 9. С какъв тип оборудване оперира (gateway, gatekeeper, softswitch), модел? (Възможно е да ви бъде отказан отговор на този въпрос). По принцип масово използваните от големите оператори типове оборудване са: Cisco Quintum/Tenor MERA / MVTS (това е softswitch) NexTone (softswitch) Alter PSS (softswitch) VoiceMaster/SysMaster Lucent Excel Digitalk (по-скоро е calling card платофрма. Kъм него се връзвате само по ISDN PRI) TSP Voiceware (същото като Digitalk) и други. 10.Поддържат ли cRTP (Compressed RTP, за Cisco) или PacketSaver (за Quintum)? Ако поддържат и вие имате същият тип оборудване, което поддържа, то при повече едновременни разговори към този оператор ще спестите немалко Интернет капацитет от компресията/обединяването на хедърите от IP пакетите. 11. Използват ли режим "пълно проксиране" или само "проксират" канала за сигнализация? При режим на пълно проксиране, целият трафик (и контролните сигнали, и гласа (RTP)) минава през гейткипъра/софтсвича на оператора ви по пътя към крайната дестинация. Ако проксира обаче само контролните сигнали, то гласовият поток се обменя директно между викащия и викания "абонат". Това има значение например ако и вие, и доставчика ви сте в България, защото тогава на вас ще ви е нужен само пииринг към него, а той от своя страна ще поеме целия ви IP трафик за разговорите навънка през собствения си външен Интернет канал. 12. Измерете колко е RTT (иначе казано - ping) до оборудването на доставчика ви. Мисля, че не е нужно да се обяснява защо го правим. 13. Какъв метод за "DTMF relay" (т.е. предаване на цифри по гласовия канал след осъщестяване на връзката. Нужно е например за набиране на PIN код и др) ? In-band, Outband (H.245 alphanumeric), OutBand (H245 signal) и т.н. 14. Имат ли резервни "канали" за най-важните дестинации? Имат ли 24 часова поддръжка от ТЕХНИЧЕСКИ персонал ? 15. По какъв timeslot ще ви таксуват? Под timeslot се разбира времевата стъпка, по която ще бъдат таксувани разговорите ви. Например timeslot 30/6 значи, че първата минимална стъпка за таксуване е 30секунди и след нея - на всеки 6 секунди. Например, един разговор с продължителност 12 секунди ще бъде таксува като 30 секунди при такъв тимеслот. Един разговор от 43 секунди ще бъде таксуван като (int(43 / 6) = 7, 7 * 6 = 42, 42 < 43, тогава 42 + 6 (следваща стъпка)) = 48 секунди. Естествено, че най-добрата за вас стъпка за таксуване (timeslot) е 1/1. 16. Проверете дали доставчикът ви изпраща фалшив ringback (или т.нар. "контрол на повикването"). Това е сигналът "звънене", който чувате в слушалката и който ви известява, че в момента се изпраща позвъняване към викания абонат. Този сигнал е редно да се изпраща от телефонната централа, към която е вързан викания абонат, а не от някоя централата или voice gateway по пътя. Някои провайдери са настроили оборудването си така, че да получавате ringback веднага след като се свържете с техния gateway/softswitch, което може да доведе до неприятности и скандали с клиентите. Типичен случай е когато връзката до викания абонат не може да се изгради (поради липса на свързаност, претоварен канал, абонатът вече е зает и т.н), а викащият абонат получава сигнал "Свободно" на слушалката и чака. TODO [борси за минути] Това е засега. Обещал съм си да отделям по малко време (15-20мин) всяка седмица за разширяване на документа. Ще вкарам информация помагаща за избор на оборудване (софтуер/хардуер) за CallShop, ITSP wholesale, терминиране, връзване на офис-PABX (УАТЦ) към VoIP и т.н. Ще разгледам най-често използваните gatekeeper'и, gateway'с, billing софтуер и т.н. както и приблизителни цени. Ще се отдели и внимание на параметрите, които следва да притежават gatewayite, гейткипърите и таксуващия софтуер, за да ви вършат безпроблемно работа. Ще отделя внимание и на форумите, където се търгува с "минути". Ако някой има да добави нещо към документацията (приемат се критики също), да пише на: lv_tokata@yahoo.com или tgeorgiev@is-bg.net Ако някой също иска да приведе написаното в нормален/комерсиален/удобен за четене вид (HTML, Word) и т.н. - да го направи :) Приложение 1 Често използвани съкращения във VoIP/Telecom индустрията: ASR (Average Seizure Ratio) - това е процентът калкулиран на базата брой свързани повиквания (към дадена дестинация/switch) към брой осъществени повиквания. Стойността еднозначно говори за "качеството на дестинацията" (така да се каже). Т.е. ако от например един GSM жлюз направите 50 опита за набиране към мрежата на Глобул и от тях 35 са успешни, то ASRът е 70%. ASRът е стойност, която задължително (или силно препоръчително) се обявява за всяка една дестинация/маршрут при (преди ;)) продажбата й. Когато предложите на борсите за минути някоя терминирана от вас дестинация (например Пловдив), то задължително ще стане въпрос за ASRа. Тук възниква и един малко особен момент - начинът по който се определят успешните повиквания. А те са 2, кой от тях е по-верният не може да се реши, то е като спора коя Линукс дистрибуция е по-добра: 1. За успешно проведено повикване се счита САМО ТОВА, при което наистина е настъпил разговор. Технически казано - switch'а, обслужващ дестинацията, е върнал Q.931 съобщение "CONNECT", т.е. виканият абонат е вдигнал слушалката. Ситуации, при които разговор не е протекъл, защото абонатът е бил зает или не е вдигнал слушалката за определения брой позвънявания, не се броят за успешни повиквания. 2. За успешно проведени повиквания се считат всички, при които switch'а, обслужващ дестинацията е върнал Q.931 disconnect reason code (код определящ причината за разпадане на разговора) - 16 (или 10HEX, което значи "Normal Call Clearing"). Също (в някои случаи) и кодове - 17 и 18. ACD (Average Call Duration) - Средна продължителност на разговора. Това е една осреднена стойност от продължителността на осъществените повиквания за определен период (например - седмица). Това също е добър критерий за качеството на канала. Ако връзката е лоша (например IP канала е нестабилен), то голяма част от позвъняванията ще са с лошо качество (ниска разбираемост), абонатите ще са недоволни от това и ще прекъсват разговора, за да наберат наново. Вследствие на това, голяма част от разговорите ще са с ниска продължителност :) ANI (Automatic Number Identification) - известно е още като CLI (Calling Line Identification) или "номер на викащия абонат". Предава се в полето "Calling party number" в Q.931 за ISDN линиите или чрез FSK / DTMF при аналоговите линии (броим и тези линии, които са вързани към изцяло цифрови централи, те ВСЕ ПАК са си аналогови). Или - модифициран тип DTMF (както е при руския "АОН"). Често се използва и за идентификация на не-IP-базирани комуникации. Представете си следната схема - voice gateway, към който по IP изпращат обажданията си X (немалък) на брой клиенти. От voice gateway'а разговорът се терминира по n на брой T1/E1 линии към PSTN switch. Да предположим сега, че автентикацията и таксуването на тези повиквания по една или друга причина не е уместно да се прави чрез voice gateway'а. Това ще се прави от система, получаваща по един или друг начин информация от PSTN switch'а. Дотук добре, само че: 1. PSTN switch'а не работи с IP и няма как да знае от кое IP е дошло обаждането. 2. Не може да се задели самостоятелен E1/T1 канал за всеки клиент. В такъв случай един от (двата) начина да се идентифицира клиента, изпращащ обаждането, е по ANI, или иначе казано - по номера на викащия абонат. За тази цел доставчикът на услугата се договаря с клиентите, които пращат разговори по IP, да настроят оборудването си (voice gateway'а) да изпраща всички разговори с определен ANI. След това от софтуера, който получава информация от PSTN switch'а, разговорите на всеки клиент се разпознават по номера на викащия абонат (ANI). Това се прави и ако имаме ситуация с т.нар. "кабинки" (callshop) - имаме примерно 4 портов FXS gateway, всеки порт от които е вързан към телефонен апарат в отделна кабинка. Тъй като и в този случай всичките обаждания са от едно IP (това на Voice gateway'а), таксуването може да се осъществи като се конфигурира ANI номер на всеки от портовете. Този метод е основният, който се използва от някои системи като TSP Voiceware и Digitalk. Използва се и без причина за идентификация на VoIP трафик от некадърни VoIP "специалисти" (най-често Cisco biased), които и "през плет" не са чували за Radius AAA. DNIS (Dialed Number Identification Service) - този термин идентифицира виканият номер, или по-скоро т.нар. "access number" (номер за достъп). Този термин намира приложение при ISDN (Q.931) комуникациите, тъй като при аналоговите (не-ISDN) линии този "атрибут" (така да го наречем) не се предава. И логично - при аналоговата линия, избираният номер си е точно номерът на линията, за която е закачено оборудването. Нещата обаче стават малко по-различни, когато започнем да говорим за ISDN и Q.931 протокола. Нека да си представим следната ситуация: фирма А наема от БТК един (1) ISDN PRI канал в Плевен с цел - бизнес със voip карти. От своя край това PRI го връзват например към Cisco 5350. Дотук добре, но все пак това са 30 порта, но да предположим че Плевен е място, където тези 30 порта не могат да се запълнят с "voip карти" дори и наполовина, което си е чисто хабене на ресурси. За тази цел на фирма А й хрумва идеята да пусне и dial-up по същото E1. Супер идея!!! Само че как Cisco-то ще знае дали входящото позвъняване е за dial-up или VoIP карта. Ами елементарно - фирма А се договаря с БТК да маршрутизира номерата 800301 и 800350 към нейния (на фирмата) E1 порт (или ако предпочитате - ISDN PRI). След това се обявява, че номерът 801301 е за voip карти, а 800350 - за dial-up. Този номер ще е и избраният номер, който ще се предава от ISDN switch'а с Q.931 SETUP съобщението в полето "Called number". Така, Cisco-то (след нужната преконфигурация) ще знае как да обработи типа позвъняване в зависимост от това, кой номер е бил набран. И все пак, 30 порта не могат да се запълнят и с voip, и с dial-up карти. Тогава се сещаме за думи като "outsourcing" и виртуален POP (Point of Presence). Представете си, че фирма А се договаря с фирми Б и В, които също искат да продават voip карти в Плевен, но нямат пари за VoIP жлюз с E1 порт, нито е оправдана таксата за ISDN PRI порта. За тази цел номерата 800315 и 800320 ще се рутират от БТК към ISDN PRI порта на фирма А. Cisco-то ще е конфигурирано да рутира входящи обаждания към тези номера по IP към софтсвичовете (calling card / IVR системите) на фирми Б и В. Едно обаждане към номер 800315 ще бъде маршрутизирано към E1 порта на фирма А, а оттам Cisco-то ще го засили по IP към софтсвича на фирма Б, където викащият абонат ще чуе IVR промпта "Добре дошли в системата на фирма Б, моля въведете номера на картата си и номера на желаната дестинация", ще го авторизира и ще свърже разговора му по H323/SIP (или каквото и да е) към желаната дестинация (например Русия). Така фирмите Б и В могат да влязат в бизнеса с voip и без никакви вложения освен за Интернет канал и един сървър с инсталиран на него софтсвич, таксуващ софтуер и prepaid calling card платформа. Друго приложение - да се настрои определен номер за всеки език. Например номер 800302 за български език, 800303 за руски и номер 800304 за английски. Всичко друго е въпрос на конфигурация на dial-peer и TCL приложението. И всичко това е възможно благодарение на т.н. DNIS, или полето "called number" от Q.931. Примери за това колко е полезен могат да се дават "до утре". VAD (Voice Activity Detection) - Това е "feature", което има за цел да разпознава липсата на глас по канала. Както сами знаем от опита си при водене на телефонни разговори, ние не говорим през 100% от времето. Нито пък другата страна. Едната страна казва нещо, млъква и чака другата страна да го чуе, осмисли и тогава да отговори. Тъй като по време на "тишината" реално не се предава глас, то логично е да се замислим дали не може да спрем предаването на RTP в този период и да спестим малко трафик. Възможно е и точно за това се използва опцията "VAD". Всички (почти) voice шлюзове (да, това е възможност на шлюзовете, а не на гейткипърите, софтсвичовете или SIP прокситата) имат опция за активиране/дезактивиране на VAD. При включването на VAD трябва да вземете впредвид и използваният кодек, защото не всички кодеци поддържат VAD (G723 варианта, който не е по Annex-A, не поддържа VAD и CNG). Процентът на мълчание във всеки разговор е силно относителен. Най-вече, зависи от характера и типа на говорещите :) Но да приемем, че средно той е около 10%. Ако на някой му трябва bandwidth калкулатор (въвежда се процента на VAD, броят канали и му се калкулира количеството канал в Kbps за всеки кодек). CNG (Comfort Noise Generation) - Та, когато гласовият жлюз усети мълчание, той спира да предава RTP. В резултат на това връзката от двете страни като че ли "прекъсва" - настъпва пълна тишина. Това може да подведе участниците в разговора, че връзката се е е разпаднала и те да прекъснат. За да се избегне това, на помощ идва друг "feature", наречен CNG. Функцията му е да генерира обратно към локалния порт "фонов шум", за да създаде илюзията че това идва от отсрещната страна. В телефонната техника има подобен термин, наречен "имитиране на импеданс". FXO (Foreign Exchange Office) - това е тип аналогов порт (RJ-11), който се включва към телефонна линия. Тази телефонна линия идва от телекома или PBX и осигурява работно напрежение, изпращане на сигнал повикване (25/50Hz) и други служебни сигнали (заето и т.н.). VoIP шлюз с FXO портове купуваме, когато искаме да организираме терминиране или оригинация (карти / wholesale) на трафик през телефонната мрежа с аналогови (не-ISDN) линии. FXS (Foreign Exchange Station) - това е тип аналогов порт (RJ-11), който се включва към крайно абонатно устройство - телефонен апарат / факс апарат. VoIP шлюзът с такъв порт е отговорен за подаването на работно напрежение и служебни сигнали (повикване, заето и т.н.) към абонатния комплект (слушалката/апарата). VoIP шлюзове с този тип портове се използват при организирането на callshops (кабинки). PDD (Post Dial Delay) - Това е закъснението в секунди, измерено между интервалите (1) изпращане на Q.931 "SETUP" съобщение / заявка за разговор (изпращане на последната цифра от номера на викания абонат) до получаване на ringback (ALERTING / PROGRESS, или казано на български "контрол на повикването) съобщение от ТЕРМИНИРАЩИЯ switch (т.е. този, който обслужва викания абонат). Това също е критерий за качеството на даден маршрут. E1/T1, ISDN PRI/BRI - Е за тези не ми се пише. Има го подробно написано на куп места, например - в CCNA курикулума. T1 се ползва само в Северна Америка, Австралия и Япония (за последното не съм сигурен). Всичко друго - Европа, Русия, Близкия Изток, Азия, Африка, Южна и Латинска Америка, ползва E1. Има и няколко типа ISDN протокола, които се използват в различните части на света. За Япония - използва се протокола NTT, то там всичко е NTT, това е името на техния телеком. 5ESS и 4ESS се използват в Северна Америка. DMS-100 протокола (носещ името и на Nortel'ските telecom switch'ове - DMS-100) се използва в Канада. Най-масово използваният е ETSI (имащ куп други имена - EuroISDN, DSS1, NET5) - Европа, Близкия Изток, Африка, Руссия. Протоколът QSIG не се използва (почти) в публичните телекомски мрежи. Той (поне така си мисля) се използва и е предназначен за PBX (учрежденските централи) поради широкия си набор от FACILITY атрибути. На негова основа е изграден и прочутия протокол CORNET (собственост на Siemens), за връзка по IP на Siemens'ки централи. Толкова по тая тема. R2 - R2 е протокол, който също като ISDN работи върху цифров 2Mbit-тен канал (E1). Той е предшественик на ISDN Q.931 и SS6/SS7/C7 протоколите. Започнат е да се използва на практика още в средата на 70те години първо по международните канали, за да замести системите за сигнализация No4 и No5 (R1) и техните слабости. При R2 за пръв път линейната сигнализация се изважда извън гласовия канал (честотната лента за глас) и се въвеждат параметри за категоризация на обаждането и други разширени функции. R2 линии в България се даваха на клиенти преди да стане възможно пускането на ISDN PRI. R2 все още се използва в момента в редица развиващи се (да бъдем честни - изостанали) страни от третия свят, чието оборудване (централи) не са надстроени да поддържат ISDN Q.931. В Европа R2 почти не се използва, ако не броим Молдова и Сърбия. Примери, за страни, в които R2 стандарта е единственият вариант за отдаване на цифрова 2Mbit'на линия са - Алжир, Заир, Ирак, Гана, Ангола, Индия, Египет, Монголия, Северна Корея. В Китай също стандарта е R2 освен за големите градове като Пекин и ШангХай. Проблемът с R2 е, че въпреки че има стандартизация на "ABCD-сигнализацията" (CCITT стандарта), много от държавите са настроили оборудването си да възприема/изпраща ABCD-битовете по различен начин за някои типове съобщения. Трябва да се има впредвид, че R2 си е сложно/гадно нещо и малка част от gateway'ите с E1 портове поддържат R2. Cisco, Quintum, Teles, Nuera, AddPac са едни от вендорите, които имат R2 поддръжка. Dialogic картите на Intel също поддържат R2. T. Георгиев *** The original of this document can be found at http://web1.egvrn.net/tokata/ ***