Podpora volání přímo z webového prohlížeče

[Cameron Howe]

Děkuji za odpověď,
To moje testování sahá už asi taky roky zpátky, nejsem firma, jen si s tím hraji (ale možnost nechat to testovat nějakou menší firmou teoreticky je, kdyby to fungovalo), a kódů bylo více, můžete klidně otestovat s tím sipml5, co tady máte, jinde mám toho také klon, ale má děsný kód, teď mám aktuálně něco narychlo postaveno na JsSIP, ale vše dopadlo stejně: nikdy žádný hovor zpět na browser netrefil (volání z browseru bylo naopak vždy v pořádku), a po větším experimentování nyní to vypadá, že je to pravděpodobně tím nastavením ws SIP serveru u Vás - a napadlo mne totéž, že si asi budu muset zřídit vlastní ws SIP server (teda se to nejdříve naučit )
Mohu sesbírat podrobnosti, ale INVITE na browser nepřijde, i když (podle všeho zkoumání) vše vypadá, jak by mělo.
Nevím, jaký server aktuálně používáte, ale s pomocí AI jsme skončili u rad typu...
Asterisk/FreePBX (PJSIP): Ensure rewrite_contact=yes and force_rport=yes are set for that transport/endpoint. This tells Asterisk to ignore what the browser says its IP is and just send data back to where the packet actually came from.
Kamailio: Ensure you are using the nathelper module and calling fix_nated_register() and add_contact_alias().
...aby packety trefovaly na otevřený websocket, na mé straně už nějak nebylo co testovat.
S registrací ani zavíráním ws problém není - případně dejte vědět, co byste chtěli sesbírat (komunikace po ws, registrace SIP zařízení co je ve web rozhraní, ...?) - to hlavní, co vůbec nepřichází, neseberu.
lokální IP unknown (web zařízení) - asi pro browser (chrome) nedopadne jinak
protokol zobrazuje UDP - asi také OK, víc než otevřený websocket nevyřeším, zbytek je na serveru
V podstatě by stačilo vědět, jestli se jakkoli přes ten ws SIP server dovoláte na browser (s tím aktuálním nastavením Vašeho serveru, bez ohledu na klienta).
Přeji hezký večer a děkuji za pomoc.

P.S.
Jinak marně čekám na odpověď, říkám si, že určitě máte lepší věci na práci, a ona tu dávno je! Ale možná to má nějakou spojitost s tím, že ten dotaz musel být odeslán skrz web proxy (moje IP je u Vaší 3rd party střídavě na blacklistu, za mne nevinně, a nejde mi proto vůbec odeslat dotaz do fóra, ale moc s tím nenadělám, neb na to hádám běží půlka vesnice, spíš celá), a koukám na datum
čtv 01. led 1970 14:03:06 - což bude asi ten důvod, proč mi nepřišlo upozornění na odpověď?
 
 

[xsouku04]

Příchozí hovory na wss by neměl být problém zprovoznit. Možnost volat přímo z webových stránek je určitě velká výhoda.
Problematické nám přišli spíše implementace webrtc SIP klientů, tedy aby fungovaly spolehlivě vždy a všude. Ale určitě to jde vyřešit. Jen jsme k tomu neměli dostatek času a také se moc nevyznáme v javascriptu na kterém je to založeno. Nyní je výhoda, že je možné se radit s umělou inteligencí.

Pro převod z wss na běžný sip používám sip proxy kamailio. Ale to není pro běžného uživatele vhodné, protože se hodně složitě konfiguruje. Kamailio je vhodné spíše pro větší operátory (dneska i mobilní), protože zvládne hodně velkou zátěž.

Pro začátečníka je určitě přívětivější zkusit třeba Asterisk.


Jinak to že fórum blokuje občas ip adresy regulerních zákazníků víme. Bohužel ale ochranu vypnout nemůžeme, protože jinak boti spamerů, co generují texty pomocí umělé inteligence jednou naplno.
 

[kovik]

Dobrý den,
provedl jsem několik úprav. Příchozí hovor mi nyní přes námi hostované SIPML5 dorazí, ale prosím upravte registraci tak, aby bylo v polích Public Identity* i Realm* uvedeno sip2.odorik.cz (místo sip.odorik.cz).

[Cameron Howe]

Dobrý den, omlouvám se za pomalou reakci, moc nebyl čas, i když tu mám okna otevřená - každopádně Vám moc děkuji, a potvrzuji, že to funguje!
Teď "pouze" musím dostavět ten interface na JsSIP (napoprvé není nic lepšího, než nemít čudl pro přijetí hovoru, protože se "nikdo" zatím tak daleko nedostal...), ale dovolat se na browser je výjimečný zážitek

Vše vypadá a zní OK oběma směry, ale musím více otestovat.

Pro webRTC v chrome je skvělá diagnostika na chrome://webrtc-internals
- grafy a statistiky na všech možných vrstvách pro debug, od aplikace až po lítající packety.

Později se snad dostanu i k SIP message chatu, třeba i k videu, ale to asi nebude tak rychlé.
Ještě jednou díky za zprovoznění a zatím přeji hezký den
 

[Cameron Howe]

Dobrý den,
Mám vyzkoušené i SIP MESSAGEs - zatím to vypadá, že korektně odchází (SIP/2.0 202 Accepted) a doručí se na Zoiper (pokud je registrován na stejném serveru - sip2), opačným směrem nic nedorazí (na browser wss).
Dalo by se tak posílat JSONy s linkem, aby si to druhá strana podle typu narenderovala, třeba jako obrázek, nebo og pro web link v chatu, atp. (mimo plain text chat), např., jak to dělají jiné aplikace.

[xsouku04]

Dobrý den,
Mám vyzkoušené i SIP MESSAGEs - zatím to vypadá, že korektně odchází (SIP/2.0 202 Accepted) a doručí se na Zoiper (pokud je registrován na stejném serveru - sip2), opačným směrem nic nedorazí (na browser wss).
Dalo by se tak posílat JSONy s linkem, aby si to druhá strana podle typu narenderovala, třeba jako obrázek, nebo og pro web link v chatu, atp. (mimo plain text chat), např., jak to dělají jiné aplikace.

 

Ty messege by určitě šlo opravit. Ale je to důležité?

[Cameron Howe]

Dobrý den,
jen to reportuji, nevím, co je důležité.
Testování mám vyřešené - směrování se dá dopomoci spuštěním nějakého non-wss SIP klienta, pak routing na wss funguje také.
Když spustím Zoiper vedle obou JsSIPů, tak mám fungující chat - kupodivu to není nic neobvyklého, někdo takto řeší směrování na SIP serveru (přes headless UDP SIP client), když jej nemůže ovlivnit. 
Jestli je to praktické - většina lidí při nějakém vysvětlování po telefonu posílá odkazy e-mailem.
V kamailio.cfg MESSAGE bloku by mělo jít pouze o t_relay() (snad), něco jako toto:

Kód: Vybrat vše

if (is_method("MESSAGE")) {
    setflag(FLT_DLG); # Track the transaction
    if (!lookup("location")) {
        sl_send_reply("404", "Not Found");
        exit;
    }
    t_relay(); # This is critical for WSS!
}

Smím se ještě rovnou zeptat, jak je to s videem přes wss? 
Při re-INVITE pro přidání video tracku během audio hovoru se dostanu jen k okamžitému ukončení hovoru 
BYE cause=500; text="Media Renegotiation Failed" (i po hraní si s bundle nastavením či odstraněním, rezervováním video media na JsSIPu (rtcOfferConstraints: { offerToReceiveVideo: true }), až myslím po přepis portů - nic nepomohlo, pokusů bylo více)
a to nejjednodušší (video call od počátku), vyzkoušeno zatím nemám (protože mi nějak přišlo praktičtější přidávat k hovoru video, když je ho potřeba)
- tak by mne zajímalo jestli je video přes wss SIP server vůbec povolené, Media Renegotiation / re-INVITE zakázaný, či jak je to s bundle / porty (ať se nesnažím, jestli to nemá řešení).
Určitě jsou i praktičtější a důležitější věci (mne napadají asi jen dvě, ale jsou v jiných vláknech, mohu je zkusit oživit, k re-konsideraci).
Omlouvám se Vám za dotazy - za případnou odpověď každopádně děkuji a přeji Vám krásný víkend
 
 
 

[kovik]

Dobrý den,

ano, videohovory jsou u Odoriku možné, ale jen v rámci sítě Odorik – tedy při volání na šestimístná čísla linek (např. 666666). Na veřejná telefonní čísla (PSTN) tímto způsobem volat nelze a video se takto nepřenáší.

Pro videohovor použijte tyto prefixy:

***XXXXXX – média (hlas i video) jdou přímo mezi koncovými zařízeními (nejúspornější / nejpřímější varianta), ale musí fungovat přímé spojení (NAT/LAN).

**XXXXXX – média jdou přes RTP proxy, která je pouze přeposílá (bez transkódování), takže lze použít libovolné audio/video kodeky, na kterých se domluví obě strany.

*XXXXXX – hovor jde přes ústřednu; videokodeky se v tomto režimu nepoužívají / nejsou podporované, proto videohovor nefunguje.

[Cameron Howe]

Dobrý den, děkuji za rychlou odpověď, tak to se omlouvám, odzkoušeno bylo bez těch hvězdiček navíc, jen s jednou - jako volání v síti z linky na linku.
Vzpomínám, že to někde napsané určitě je, bohužel mi to při testování nedošlo