Asterisk - codec konverzió

VoIP

Sziasztok!

Próbálkozom a chan_dongle-vel hívást kezelni 3G stick segítségével.

Úgy tűnik, minden jól működik, amíg ulaw codecet használó készülékről próbálom.
A mobilomon viszont ilbc-t használok, mert ezt a készülék is támogatja és sávszélesség igénye is kevés.

Tehát, ha a mobilról próbálkozom hívást indítani vagy fogadni a chan_dongle-n keresztül, furcsa zajok kerülnek a hangcsatornába.
...vagyis néha jó és hallom mindkét felet, néha pedig rákeveredik ez a zaj hosszú másodpercekre is, szünet nélkül. Ekkor is hallani a két beszélőt, de nem túl élvezetes a dolog...

Ezt a hangot viszont soha nem a mobilon hallom, hanem a másik oldal hallja csak (kimenő és bejövő hívás esetén is).

Nem tudom, mi okozza, de lévén a másik codecet használó készülékkel nincs gond, úgy sejtem, valahol a codec konverziónál lehet gond... azt nem próbáltam kideríteni, a chan_dongle milyen módon oldja ezt meg.

--------------------

Tehát: Létezik olyan megoldás, amivel el tudom érni, hogy a chan_dongle irányába ulaw codec legyen mindenképpen, más codec esetén pedig a konverziót erről az állapotról indítsa?
Valamiféle fake sip client pl...

Tehát kb. úgy, mintha beállítanék külön egy Asterisket a chan_dongle miatt és ezzel kommunikálnék ulaw codec segítségével.

Megoldható ez vajon?

Az Asterisk verziója mától 10-es nálam, de a felvétel még 1.6-on készült. A helyzet amúgy változatlan, csak 10-eshez még nincs hivatalos chan_dongle, csak némi patch, amivel egyébként működik.

Remélem, nem voltam túl zagyva...
Esetleg valakinek van erre ötlete?

  • 2599 megtekintés

( E-Medve v | 2012. 01. 02., h – 07:55 )

Az ilbc transzkódolásnál nekem is voltak érdekes tapasztalataim. A gsm kodek nem játszik? Hasonlóan alacsony sávszélességet igényel, mint az ilbc és szinte alig venni észre az alaw és a gsm közti különbséget.

( wpeople v | 2012. 01. 02., h – 08:58 )

kipróbálnám megjáratni egy chan_local-on

( hrgy84 | 2012. 01. 02., h – 14:22 )

Tilts le az ulaw-on kivul minden letezo kodeket, akkor a csatorna magatol kiforcolja az ulawot. Ha masra nem, tartalek tervnek meg mindig jo.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Persze, bár tartalék tervnek egy másik Asterisk, esetleg valami localhoston futó SIP forwarder is jó lenne talán (előbbi biztosan), de ez egyelőre csak teszt nálam.

A mobilomra viszont nem akartam kényszeríteni az ulaw-ot... sőt, le van tiltva, mert képes azt választani, én pedig mobilnetről is használnám is így nem túl jó a hatásfoka... vagy lehet úgy kényszeríteni ulaw-ot, hogy a mobilon ilbc-t kényszerítek, ő meg elvégzi nekem a konverziót?

...mert a konverzió egyébként jól működik (ulaw irányban biztosan), csak valahogy a chan_dongle rendetlenkedik vele.

( nagysa v | 2012. 01. 02., h – 16:53 )

Az asterisk két üzemmódban tud működni:

A: codec pass-through
B: codec translation

Ezt általában automatikusan meg is teszi.

Nézd meg a "CLI> core show translation" paranccsal, hogy a tied tudja e forgatni
ulaw-ból ilbc-re! És ha igen milyen késleltetéssel?

A sip.conf-ban a client-nél (vagy trunk) ki tudod kényszeríteni a szükséges codec használatát.
l.:
Disallow All
Allow ilibc

u.i.:
Nekem 1.6-os működik és nem is tudja forgatni az ilibc codec-et semmire.
Persze a /usr/lib/asterisk/modules/ könyvtárban nincs is ilibc.so file.
Két sip mellék között is tudod tesztelni (ha a készülékek támogatják a kért codec-et) a sip.conf beállítással, hogy működik e?

Tudja forgatni az ilbc-t.
Amikor elkezdtem használni, először nem értettem, miért nem tudok vele semmit csinálni az echo teszten kívül, de bevezető szöveget ott sem kaptam (át kellett volna fordítania /transcode/). :)

Bele kellett fordítani az Asterisk-be a támogatást (contrib résznél külön letölthető) és amúgy használat közben elég fürge is szerintem.
Előtte speex-et használtam egy darabig, de annak nagyobb volt a késleltetése és szerintem ezzel jobb minőséget tudok elérni adott sávszélességigény mellett. Gondom nem volt vele ezidáig.

A sip.conf-ban a telefonnak ki van kényszerítve az ilbc, de az a baj, hogy a dongle nem SIP trunk.
Ennek van egy külön dongle.conf konfigurációja, de itt codecet nem sikerült megadni.
Mondjuk jogos lehet, de nem tudom, hogyan kommunikálnak a külső modulok az Asteriskkel... tehát chan_dongle (chan_datacard), chan_mobile, chan_dahdi és effélékre gondolok.

Két SIP mellék között tökéletesen működik az ulaw - ilbc transcode. Sőt, külső SIP szolgáltatóval is ulaw codecen megy a beszélgetés, ezt abszolút problémamentesen tudom használni mobilról ilbc-n akár kimenő, akár bejövő hívásról van szó.

A táblázat: 

           gsm  ulaw  alaw  g726 adpcm  slin lpc10 speex speex16  ilbc g726aal2  g722 slin16 testlaw speex32 slin12 slin24 slin32 slin44 slin48 slin96 slin192
      gsm     - 15000 15000 15000 15000  9000 15000 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
     ulaw 15000     -  9150 15000 15000  9000 15000 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
     alaw 15000  9150     - 15000 15000  9000 15000 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
     g726 15000 15000 15000     - 15000  9000 15000 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
    adpcm 15000 15000 15000 15000     -  9000 15000 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
     slin  6000  6000  6000  6000  6000     -  6000  6000   14000  6000     6000  8250   8000    6000   14000   8000   8000   8000   8000   8000   8000    8000
    lpc10 15000 15000 15000 15000 15000  9000     - 15000   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
    speex 15000 15000 15000 15000 15000  9000 15000     -   23000 15000    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
  speex16 23500 23500 23500 23500 23500 17500 23500 23500       - 23500    23500 15000   9000   23500   23000  17500  17000  17000  17000  17000  17000   17000
     ilbc 15000 15000 15000 15000 15000  9000 15000 15000   23000     -    15000 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
 g726aal2 15000 15000 15000 15000 15000  9000 15000 15000   23000 15000        - 17250  17000   15000   23000  17000  17000  17000  17000  17000  17000   17000
     g722 15600 15600 15600 15600 15600  9600 15600 15600   15000 15600    15600     -   9000   15600   23000  17500  17000  17000  17000  17000  17000   17000
   slin16 14500 14500 14500 14500 14500  8500 14500 14500    6000 14500    14500  6000      -   14500   14000   8500   8000   8000   8000   8000   8000    8000
  testlaw 15000 15000 15000 15000 15000  9000 15000 15000   23000 15000    15000 17250  17000       -   23000  17000  17000  17000  17000  17000  17000   17000
  speex32 23500 23500 23500 23500 23500 17500 23500 23500   23500 23500    23500 23500  17500   23500       -  17500  17500   9000  17000  17000  17000   17000
   slin12 14500 14500 14500 14500 14500  8500 14500 14500   14000 14500    14500 14000   8000   14500   14000      -   8000   8000   8000   8000   8000    8000
   slin24 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500   14000   8500      -   8000   8000   8000   8000    8000
   slin32 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500    6000   8500   8500      -   8000   8000   8000    8000
   slin44 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500   14500   8500   8500   8500      -   8000   8000    8000
   slin48 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500   14500   8500   8500   8500   8500      -   8000    8000
   slin96 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500   14500   8500   8500   8500   8500   8500      -    8000
  slin192 14500 14500 14500 14500 14500  8500 14500 14500   14500 14500    14500 14500   8500   14500   14500   8500   8500   8500   8500   8500   8500       -

Amúgy Asterisk 1.6-ról 10-re váltva meglepődtem, de annak ellenére, hogy ezúttal kiválasztottam a "G711_NEW_ALGORITHM" opciót /1.6-nál nem volt kiválasztva/ "slower, but cleaner" jeligére (+ a reduced branching-et is, de nem tudom, ezzel mit értem el), a késleltetési idő határozottan csökkent.
...vagy az echo testet gyorsították, ugyanis ott tűnt fel a különbség (: ...de az ilbc - ulaw beszélgetés késleltetése is határozottan javult érzésem szerint, egyszerre hallgatva a két készüléken.

Ezt nem vártam a frissítéstől, de határozottan tetszik... :)

1) milyen ez a hardware, ahol ilyen késleltetés hallható? vmi embedded cucc?
2) igen, az SIP/DAHDI/IAX között van transcode, úgy tűnik nekem, h a chan_dongle-ból ez kimaradt...

btw, mivel elvileg minden egy codedc-re konvertálódik, majd onnan tovább, így a chan_local-al elvileg jónak kéne lenni, hiszen:
chan_dongle vs chan_local = tetszőleges codec (amit dongle szeret)
chan_sip vs chan_local = tetszőleges codec SIP felé, és a konverzió működik

1) ...hát szerintem nem ez hallható, ezt csak írja... :)
Nem embedded, egy Athlon 64-es CPU (LE-1640) és leterhelve sincs... ez kb. úgy hülyeség a maga másfél másodpercével, ahogy van.
Talán a tizede, ha igaz... azt elhiszem.

2) Lehet, hogy kimarad belőle, bár lehet vele telefonálni, tehát valami azért működik... csak annyi a szépséghibája, hogy bizonytalan időközönként bizonytalan ideig kerreg nekem...

Ezt a chan_localt megnézem még egyszer, lehet, valamit félreértettem, ill. másra gondoltam.
Ha így meg lehet adni neki mindent, akkor annak márpedig működnie kell. :)

Szerk.:
...na várjunk... tehát az átkódolási idő ezredmásodpercekben mérve egy másodpercnyi adat átkódolásakor...
...15 000ms = 15s?
Hogy is van ez? Ez így nagyon nincs a helyén... vagy nálam gurult el valami? :D
Ha ennyinek gondolja, az bődületes nagy hülyeség... kivárni nem lehetne... de még a 1,5s sem igazán lenne egészséges.

> chan_dongle vs chan_local = tetszőleges codec (amit dongle szeret)
> chan_sip vs chan_local = tetszőleges codec SIP felé, és a konverzió működik

Ezt te hogy csinálnád meg?
Keresgéltem, de nem látom, hol tudom megadni, a chan_local-nál milyen codecet használjon... vagy még mindig rossz helyen keresgélem.

A chan_local az, amivel pl. át tudok ugrani (hívni) másik context adott mellékére pl. Dial(local/mellék@context) formában az extensions.conf-ban, igaz?
Hogy lesz ebből saját codec neki?

Esetleg be lehet állítani codec használatot valamely paraméterrel az exten sorai között?

Szerk.: Hmm, ezt most találtam... (SIP_CODEC sor érdekes) ezzel vajon összezavarom vagy szót fogad és azt használja? :) 

exten => s,n(G729),NoOp(Setting Codec for Trunk)
exten => s,n,set(SIP_CODEC=g729)
exten => s,n,MacroExit()

Szerk2.: Ezt hiába írom be akár a mobil bejövő, akár a chan_local által meghívott extension-hez, nem változtat semmin (mármint SIP_CODEC=ulaw paraméterrel).

[off] Persze, már csak a Dial is utal a hívásra. :) ...de nem oda ugrik? :D [/off]

Az a baj, hogy a codecben megegyezik, mert elvileg tudja és össze is tudja kapcsolni a kettőt, de az eredmény mégsem kielégítő, mert valahol hiba csúszik a gépezetbe és elkezd kattogni... amúgy semmi baja nem lenne, ha szimplán csak a kattogás maradna el...

"SIP_Codec-ről még nem is hallottam, valamint nem is látom értelmét ismerve a mechanizmust... (a két peer egyezik meg egymással)"

Persze, de én már azt keresném, milyen belső mechanizmus van az Asterisken belül, amivel ezt ki lehet kerülni.
Semmi gond nem lenne ezzel, ha létre lehetne hozni egy "local link" usert és azon átvezetni. :)
Mindenesetre érdemes lesz kipróbálni, egyáltalán mennyire jelentkezik, ha egy másik Asterisken átvezetem... akár csak annyira, hogy hívjon át rá és az adja vissza a hívást egy másik mellékre.