Volání CSIpSimple -> Jitsi

Programy, které slouží k volání přes internet z počítače nebo chytrých mobilů.
Odpovědět
Georgius
Příspěvky: 223
Registrován: pon 22. črc 2013 16:07:46

Volání CSIpSimple -> Jitsi

Příspěvek od Georgius »

Zdravím,
v rámci experimentování s videohovory jsem zjistil, že asi nejpoužitelnější pod linuxem je Jitsi, které má ke stažení Debianní balíček a celkem funguje. Přes **linka jsem udělal hovor z Yeallink VP 530 (na rozdíl od linphone aplikace nespadla a na rozdíl od Ekigy mi příchozí hovor nerestartoval Xka). Na Yealink i zpět se mi podařilo volat i z video pluginu pro CSIpSimple. Takže jsem zkusil poslední kombinaci a to CSIpSimple a jitsi a narazil na problém, který jsem zatím nevydumal. Pluginem to není, stejně se mi chová i CSIpSimple v mobilu bez pluginu.

Když volám *linka, hovor normálně proběhne. Když zavolám na **linka tak:

a) pokud hovor inicijuje jitsi, tak se nespojí a spadne s chybou
b) pokud je to nevideohovor, tak z telefonu asi po vteřině spadne s chybou

Chyba zní: "Internal Error: Failed to parse the SDP description of the peer."

Hovor 173762102 je ten, co zafungoval, hovor s ** šel po něm a proběhl před i krátce po hovoru 173762115 - všechny hovory šly ze stejného směru CSipSimple -> Jisti. nenapadá někdoho něco ?

Na konzoli, odkud je Jisi spuštěno to vyzvrací toto (číslo ve stringu se průběžně mění):

java.lang.NumberFormatException: For input string: "5667056670"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at gov.nist.javax.sdp.parser.MediaFieldParser.mediaField(MediaFieldParser.java:68)
at gov.nist.javax.sdp.parser.MediaFieldParser.parse(MediaFieldParser.java:129)
at gov.nist.javax.sdp.parser.SDPAnnounceParser.parse(SDPAnnounceParser.java:112)
at javax.sdp.SdpFactory.createSessionDescription(SdpFactory.java:129)
at net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.parseSdpString(SdpUtils.java:1678)
at net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.processOffer(CallPeerMediaHandlerSipImpl.java:425)
at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.processReInvite(CallPeerSipImpl.java:496)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processInvite(OperationSetBasicTelephonySipImpl.java:1039)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processRequest(OperationSetBasicTelephonySipImpl.java:326)
at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.processRequest(ProtocolProviderServiceSipImpl.java:1000)
at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.processRequest(SipStackSharing.java:662)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:230)
at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:196)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1303)
at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:847)
at gov.nist.javax.sip.stack.TLSMessageChannel.processMessage(TLSMessageChannel.java:613)
at gov.nist.javax.sip.parser.PipelinedMsgParser.run(PipelinedMsgParser.java:470)
at java.lang.Thread.run(Thread.java:745)
java.text.ParseException: m=audio 5667056670 RTP/AVP 99 101
at gov.nist.javax.sdp.parser.MediaFieldParser.mediaField(MediaFieldParser.java:122)
at gov.nist.javax.sdp.parser.MediaFieldParser.parse(MediaFieldParser.java:129)
at gov.nist.javax.sdp.parser.SDPAnnounceParser.parse(SDPAnnounceParser.java:112)
at javax.sdp.SdpFactory.createSessionDescription(SdpFactory.java:129)
at net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.parseSdpString(SdpUtils.java:1678)
at net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.processOffer(CallPeerMediaHandlerSipImpl.java:425)
at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.processReInvite(CallPeerSipImpl.java:496)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processInvite(OperationSetBasicTelephonySipImpl.java:1039)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processRequest(OperationSetBasicTelephonySipImpl.java:326)
at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.processRequest(ProtocolProviderServiceSipImpl.java:1000)
at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.processRequest(SipStackSharing.java:662)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:230)
at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:196)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1303)
at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:847)
at gov.nist.javax.sip.stack.TLSMessageChannel.processMessage(TLSMessageChannel.java:613)
at gov.nist.javax.sip.parser.PipelinedMsgParser.run(PipelinedMsgParser.java:470)
at java.lang.Thread.run(Thread.java:745)
19:23:17.146 SEVERE: [915] impl.protocol.sip.CallPeerSipImpl.processReInvite().512 Error while trying to send a response
java.lang.IllegalArgumentException: Failed to parse the SDP description of the peer.
at net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.parseSdpString(SdpUtils.java:1682)
at net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.processOffer(CallPeerMediaHandlerSipImpl.java:425)
at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.processReInvite(CallPeerSipImpl.java:496)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processInvite(OperationSetBasicTelephonySipImpl.java:1039)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processRequest(OperationSetBasicTelephonySipImpl.java:326)
at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.processRequest(ProtocolProviderServiceSipImpl.java:1000)
at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.processRequest(SipStackSharing.java:662)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:230)
at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:196)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1303)
at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:847)
at gov.nist.javax.sip.stack.TLSMessageChannel.processMessage(TLSMessageChannel.java:613)
at gov.nist.javax.sip.parser.PipelinedMsgParser.run(PipelinedMsgParser.java:470)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.sdp.SdpParseException: Could not parse message
at javax.sdp.SdpFactory.createSessionDescription(SdpFactory.java:132)
at net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.parseSdpString(SdpUtils.java:1678)
... 13 more
Uživatelský avatar
xsouku04
Administrátor
Příspěvky: 8146
Registrován: pát 15. říj 2010 11:11:44
Bydliště: Brno
Kontaktovat uživatele:

Re: Volání CSIpSimple -> Jitsi

Příspěvek od xsouku04 »

Zrovna na tom také laboruji. Shodou okolností mám také na stole Yeallink VP 530.

A mám doma také na testování 2N Helios IP verso. Což je sice dvěřník, ale takový co funguje jako VoIP video telefon.

Co se týče SIP klientů, co podporují videohovory, je to docela děs a hrůza. A pod Linuxem je to ještě horší, tam jsem v podstatně neuspěl ani s jedním. A přitom jsou to většinou jen drobné nedodělky a chyby, které brání opravdovému použití. A nepřehledné a nesmyslné uživatelské rozhraní.

Ve Windows mi v některých případech fungoval dobře microsip. V jiných případech bylo video neúměrně zpožděné.

Softwarových SIP klientů existuje spousta, ale typicky za mnoho nestojí. A to po všech stránkách. Co se týče SIP kleintů, co podporují videohovory, je to ještě horší. V Linuxu nevím o žádném, co by stál za zmínku a uměl i videohovory.

Problém je, že ony nedokonalé video sip klienty se často nedomluví ani sami se sebou, natož s jiným video SIP klientem. O hardwarových to bohužel může platiti též.
Např. 2N Helios IP verso se nedomluví Yeallink VP 530 a na Yeallink VP 530 není vidět žádný obraz.
Naše proxy s tím těžko něco udělá, protože jen pakety přeposílá.

Snad jediná záchrana by pro nás mohlo být WEBRTC. S tím ale nemám zkušenost.
RadimKr
Příspěvky: 12
Registrován: stř 23. črc 2014 16:19:47

Re: Volání CSIpSimple -> Jitsi

Příspěvek od RadimKr »

Ke vší úctě k Jitsi, ale pod Linuxem to je katastrofa. Jitsi a video jaks taks funguje pod Win, ale pod linuxem to je nepouzitelne. Rozhodne to neni o tom, ze to nasadite nekde mezi BFU zakazniky. Z meho pohledu nad tim ztracite jenom cas a stejne s tim nic moc nevymyslite.
Tak nejak funguji nektere aplikace a HW phone mezi sebou z meho pohledu treba androidi LinPhone nebo treba video mezi LinPhone[android] - Jitsi[Windows].

Ano budoucnost a doufejme nemenny standard je WebRTC, kde zvuk jiz funguje i pres NAT spolehlive a je jedno zda mate iphone, androida, Windows, Linux nebo chytrou televizi. Bohuzel s videem je i zde zatim stale problem.....zatim.
Uživatelský avatar
xsouku04
Administrátor
Příspěvky: 8146
Registrován: pát 15. říj 2010 11:11:44
Bydliště: Brno
Kontaktovat uživatele:

Re: Volání CSIpSimple -> Jitsi

Příspěvek od xsouku04 »

RadimKr píše:Bohuzel s videem je i zde zatim stale problem.....zatim.
Díky za odborný komentář. Mohu se zeptat, v čem je s videem přes WEBRTC hlavní problém? Kde soudruzi, co to vymýšleli, udělali chybu?

Osobně vůbec nechápu, jak je možné kvůli poměrně jednoduché věci (přenášet zvuk a video mezi dvěma účastníky) nadělat tolik problémů a těžkostí. A celé to tak zkomplikovat, aby skoro nikdo nebyl schopen to použít.
Vždyť jsou to jen dva obyčejné RTP streamy (jeden zvukový a jeden video) v přesně definovaném kodeků, které přeposílá RTP proxy.
RadimK
Příspěvky: 70
Registrován: pát 27. pro 2013 17:29:30

Re: Volání CSIpSimple -> Jitsi

Příspěvek od RadimK »

xsouku04 píše:
Díky za odborný komentář. Mohu se zeptat, v čem je s videem přes WEBRTC hlavní problém? Kde soudruzi, co to vymýšleli, udělali chybu?

Osobně vůbec nechápu, jak je možné kvůli poměrně jednoduché věci (přenášet zvuk a video mezi dvěma účastníky) nadělat tolik problémů a těžkostí. A celé to tak zkomplikovat, aby skoro nikdo nebyl schopen to použít.
Vždyť jsou to jen dva obyčejné RTP streamy (jeden zvukový a jeden video) v přesně definovaném kodeků, které přeposílá RTP proxy.
Bohužel problému je zde několik.
První věc je ta, že u klientů musíte mít kodek VP8.....asterisk ho musí podporovat a ta WEBRTC gateway jenom překládá webrtc na SIP
Taky je tu možnost že nám to neběhá kvůli kamailio, možná tam máme někde nějakou kravinu. Nebo tam nemáme dokompilovanej nějakej modul. Protože webrtc gateway se hlásí ke kamailio a to pak teprve posílá SIP na asterisk, nejde to tam přímo.
On je probém, že s tím brutálně laborujete, neexistuje žádná dokumentace, totálně nic. Je trochu škoda že to neběhá, bylo by to docela dobrý, určitě se k tomu vrátíme jak bude čas.
Je fajn, že se podařil rozjet alespoň zvuk. Nad backendem v JS/React jsme si napsali Web Telefon na který je možné si z PSTN dovolat a zároveň si z něj i do světa zavolat. Byl to docela zážitek, když jsem byl minulý týde v Euronics, kde jsem po prodavačích chtěl otestovat SMART TV s podporou WebSocketu. Chvíli nechápali, když jsem pak řekl prodavači aby si z mobilu[O2] zavolal na nomadické číslo a jemu to tam začalo na 4 televizích zvonit, tak se mu zlehka prolomili kolena :D :D

Microsoft se svým miliardovým SKYPEM se o to taky snaží, zdá se, že zlehka pohřbívá svoji kdysi dokonalou aplikaci a jde jinou cestou, ale moc to soudruhům nejde. S videem jsou na tom úplně blbě a RTC jim chodí pouze pod EDGE :D
Odpovědět