OT: Jak vznikají většiny [WAS: Kde sehnat tahový potenciometr]

[Pavel Troller]

Zdravím,
>
> Takze pouzivatelia TB, plugin LookOut je to prave riesenie, ak nechcete, 
> aby sa vacsina musela prisposobovat mensine.

Tady vůbec nejde o většinu nebo menšinu. Tady jde o dodržování standardů.
Jsem asi neznalý. Prosím, odkažte mne na dokument jakékoliv uznávané 
standardizační organizace (IETF, ITU, ISO, ETSI, ANSI...), kde je popsán
standard ms/tnef aneb struktura přílohy winmail.dat.

  Bohužel jsem na tuto problematiku od minulého týdne docela citlivý, jinak
bych to nechal plavat - nějaký potenciometr mi může být ukradený. Ale u nás
ve firmě se stala taková příhoda, kterou vám sem napíšu a ze které se ještě
jen těžko vzpamatovávám.

  Jeden VIP zákazník (opravdu VIP - tvoří několik procent naší měsíční
tržby) si instaloval ve své firmě pokročilé komunikační prostředí od jisté
firmy - inu, asi uhodnete, jakou mám na mysli, je to ta, z jejíž dílny je
i ten diskutovaný formát přílohy. My jako operátor jsme byli vyzváni, abychom
mu poskytli SIP trunk. A ono už se to instaluje týden a ještě to nefunguje. 
  1) 95% či více operátorů či obecně uživatelů SIPu používá pro komunikaci
IP protokol UDP. Je to prostě industry standard. Nicméně, tento produkt může
komunikovat výhradně na TCP. Poněvadž naše operátorská SIP platforma TCP
podporuje jen pro zabezpečená spojení (TLS, SIPS), nastal docela problém.
Naštěstí máme v cestě mezi zákazníkem a námi SBC (Session Border Controller,
v podstatě velmi specializovaný firewall pro VoIP), které umí překlad. Tož
jsme spustili překlad UDP/TCP a zpět. Jenže ... 
  2) Z nějakého důvodu ta potvora vytvoří více TCP spojení a pak posílá
různé části dialogů různých hovorů po různých spojeních. To SBC má docela
problémy to dát dohromady tak, aby to dávalo smysl i na té UDP straně. Kolega
to ladil asi 2 dny a 3x musel volat na placenou podporu dodavatele SBC.
Myslíte si, že to tím skončilo ? Zdaleka ne...
  3) Když už alespoň pakety chodily, jak měly, přišlo na řadu zkoušení volání.
Další zádrhel - nebyl slyšet vyzváněcí tón. Jednoduchý trace to vysvětlil -
RFC 3261 (SIP) a RFC 3960 (Early Media and Ringing Tone Generation in SIP)
jasně specifikují, jak se má zakládat mediální relace potřebná pro přenos
vyzváněcího tónu a jiných médií před přihlášením - ve zprávě 183 Session 
Progress. Nicméně, výše uvedený systém posílá média (SDP část zprávy) ve
zprávě 180 Ringing, kde to nikdo nečeká. Naopak, výše uvedená RFC přímo
předpokládají, že v této zprávě média nebudou. SBC dostává opět zabrat -
je to stavový automat a je teoreticky schopné vyřešit i tento problém - ale
pomalu bude tím zákazníkem tak zatíženo, že už nestihne dělat nic pro nikoho
dalšího. Navíc implementace těchto nestandardů stojí dny práce vývojáře, který
by měl dělat ve své pracovní době spoustu jiných věcí a ještě jsme osočování,
proč nám to tak dlouho trvá.
  Kolega už ztrácel nervy a při jednom z hovorů s velice rozezleným zákazníkem
se ho zeptal, zda to jeho zařízení má alespoň jeden certifikát kompatibility
s jakýmkoliv uznávaným VoIP systémem. Odpověď z druhé strany nám všem vyrazila
dech: Cože? Já mám být kompatibilní s vámi? No to si snad děláte legraci!
VY budete kompatibilní SE MNOU! Ještě buďte rádi, že po vás nechceme papír, že
ty vaše krámy jsou certifikovány pro použití s naším novým, krásným, perfektním
systémem! 
  Mno... Tak to jenom jedna ilustratinví příhoda, jak vznikají většiny :-(.
  My v práci musíme držet hubu a krok... Ale po mně doma ve volných chvílích
toto opravdu nechtějte :-).

Zdraví Pavel.