Caller ID - hogy lenne jó?

VoIP

Van egy Asterisk központom, amibe mindenféle külső trunkök jönnek be. Többféle SIP szolgáltató is van, de van analóg, GSM, és ISDN is az érdekesség kedvéért.

A probléma abban lakozik, hogy minden irányból más formátumban jön be a caller id. Az egyik irányból +36xxx, a másik irányból 36xx, a harmadiktól 0036xx, a negyediken országhívószám nélkül, stb.

A caller id-ket praktikus volna egységesíteni, egyrészt a júzer érdekében, másrészt, a caller id-ket olyan formába kell hozni, hogy az visszahívható legyen, és nyilván nem akarok a dialplan-ben húszféle variációra felkészülni.

A kérdés főként nem technikai, mert tudom, hogyan kell stringeket átalakítani, hanem főként elméleti, hogy ki hogyan szokta megoldani ezt a problémát?

Egyfajta praktikus megközelítés volna mindent +36xx nemzetközi formátumra hozni, viszont azt nem lehet letárcsázni hagyományos készülékről.

Vélemények?

  • 10956 megtekintés

ez csak akkor érdemes, ha a szolgáltató partnerek között nincs nemzetközi...

Én is azt javaslom, hogyha az Asterisk-ed csak magyarországi szolgáltatókkal áll kapcsolatban akkor 00; 06; valamint 1XX és 1XXX valamint 1XXXX formátumokat engedd a ha "helyi" akkor egészítsd ki a hívó körzetszámára.
Segítség lehet az alábbi is a kitaláláshoz.
http://webpub-ext.nmhh.hu/aga/common/setLanguageAction.do?lang=hu

Viszont, amennyiben nemzetközi és magyarországi szolgáltatóid is vannak, akkor mindenképp E164 formátumot ("+" jel nélküli) javasolnék és src_num_type és dst_num_type segéd változókat.
(utóbbi arra lesz jó, hogy amikor oda-vissza kell alakítanod a számokat tudd, hogy az e164 formátumú-e pl rövid szám esetén az "17cde" nem Amerika -bár hossz alapján lehet nem is illeszkedne rá, de biztos ami biztos ezeket külön kell értelmezni...).

Minden szolgáltató megadja hogy mi a hívó szám és mi a hívott szám formátuma ill hogyan várja, így ha már egységes az Asteriskeden belül vissza tudod alakítani amikor felé küldöd vagy felőle jövőt tudod arra alakítani amire kell.

( E-Medve v | 2013. 05. 16., cs – 20:52 )

Nem is tudom melyik Voip készülékkel jártam úgy, hogy bejövő híváskor +36...-nak írta ki, de a "Missed calls"-ba már 36...-ként mentette le.

( errotan v | 2013. 05. 16., cs – 21:51 )

Én perl-ben írt AGI scriptel szoktam átalakítani a hívószámokat egységessé (minden országon belüli hívószám 06-al kezdődik, külföldi 00-val). Továbbá, ha valaki helyi körzetes számot tárcsáz ki azt is "kipótolom" dialplan-el, hogy teljes hívószám (pl. 234567 beütése és 10-es körzet esetén 0610234567) látszódjon a hívásnaplóban. Szerintem nem praktikus a +36xx formátum, hiszen általában központokon "hardware"-s mellékek vannak amin nem szokott lenni dedikált "+" gomb.

( ha1dfo | 2013. 06. 09., v – 18:23 )

Pusztán elméleti válasz, avagy hogyan is néz ez ki nagyrendszereknél: minden vonalnak, kapcsolatnak (pl.: SMSC linkek) be szokták állitani a TON / NPI értékeket (type of number, numbering plan indicator, de néha még a nature of address is szóba jön), avagy abba az irányba milyen formátumban érkeznek a telefonszámok vagy GT-k, és hogyan kell konvertálni. Ez általában ISDN / International minden rendesebb helyen.
Ha mindezzel boldogak vagyunk, akkor jön ugye a másik kérdés, hogy mi van ha előfizető ad meg számokat (pl címzett mező). Ilyenkor jön képbe az olyan komponensek, mint például a 'number formatter' (magába az applikációba van beleégetve, mindenhol más a neve, máshogy működik kicsit), hogy kisakkozza, a számhosszúságból, előhívókódokból, országkódból, hogy körülbelül mi lehet a szám (természetesen ez nem 100%-osan pontos, de szerencsére törvényileg tiltva is van pár fajta tárcsázás [pl csak 7 számjegy használata]).
Amúgy át tudom érezni a problémádat, van egy ügyfél, aki az Istenér' nem szállna le az előhívós címzésről az SMSC-ivel (mindenki másnál isdn/international) - ilyenkor jönnek kreatív megoldások (például regexek).

--
"A herceg én vagyok."

rotfl, mutass rá kérlek a legközelebbi switchre, legyen voip, ss7, vagy egy jólszituált ewsd, ami beállítja a type of numbert szám alapján. Mo -on ( és még nagyon nagyon nagyon sok helyen ) a mező egyszerűen nem használt és default értéken van.
Mi az hogy a szám ISDN? A szám e164 lehet, vagy nem e164. A telefonszámokat meg nem konvertálják, hanem megjelenitik. Amiről te beszélsz az a dialing plan, amit normalizálásnak hivnak.
A number formatter -t mindenhol dialing plannek hivják... a számhosszúság pedig csak egy faktor, számitanak az első számok is bőven.

Mi az hogy a 7 számjegy használata tiltva van?:) Ne mond már, hogy megfogom a jólbevált matávos telefonomat és ha becsépelek 7 számjegyet akkor az nem fog kapcsolni? Mindenféle előhivó nélkül... Ezt hivják budapesti telefonszámnak :)

Nem a switch találja ki a TON-t, hanem mi mondjuk meg, hogy mi jön arról. És nem csak E164 van, nemrég sikerült belefutnom valami egészen egzotikus ügybe egy dél-amerikai CDMA-GSM interworking kapcsán.
A 7 számjegy legjobb tudomásom szerint bizony keményen tiltva van mobiltelefonoknál (a számhordozás miatt), egy kedves hang fogja közölni veled, hogy próbálj meg elérekni valami "körzethívót". Landline-nál lehet működik még valamiért, leginkább mobilhálózatokkal volt eddig dolgom (szerencsére?).

--
"A herceg én vagyok."

Jo, de ez a nagy magyar valosag ( a 7 szamjegy ). Ami ugye abbol adodik, hogy ha csak ezt tarcsazom, akkor a szolgaltatom normalizal ( azaz e164 -et csinal belolle ), ami auomaikusan a sajat korzetszama, es ott nem egyertelmu a megtallas.
Azmeg, hogy valaki CDMA -n szolgaltat nem predesztinalja, hogy automatikusan gyokernek kell lennie ( pedig tuti az :))

Nem a CDMA-tól gyökerek, attól teljesen függetlenül egészen érdekes dolgok vannak ott, mint például manuálisan töltött ENUM/DNS.
A 7-számjegyesdivel továbbra is vitatkoznék, mert bár azon rendszerek, amikhez közöm van alapértelmezés szerint úgy működnek, hogy ha kevés a szám, akkor elérakja a CC-t meg a "saját" NDC-t, viszont pont a ciklámenszínű cég csiporgott napokig, hogy márpedig ez ne lehessen mert a számhordozhatósági törvény miatt ezt most már nem szabad engedniük. Irodalomjegyzék: itt és itt.

--
"A herceg én vagyok."