Hi! I need to establish calls between WebRTC and usual SIP clients (exactly, sipml/jssip and linphone-android). I used configs from https://github.com/caruizdiaz/kamailio-ws and latest git master HEAD of both kamailio and rtpengine. I got calls from webrtc to android working correctly (but only with Firefox browser), even with video. But in other directions i have some issues because of lack of RTP delivery or RTP timeouts. I have some logs to show you regarding this: https://gist.github.com/krieger-od/27c6f3e4924f5e21352e (works), https://gist.github.com/krieger-od/196bcfbd331d621427ef (doesn't work). I would really love to get some quick help from anyone. For direct manual fixing, I can give a couple of hundreds of bucks.
Looking forward impatiently for reply from anyone having something to say.
On 12/18/14 12:11, Andrey Utkin wrote:
Hi! I need to establish calls between WebRTC and usual SIP clients (exactly, sipml/jssip and linphone-android). I used configs from https://github.com/caruizdiaz/kamailio-ws and latest git master HEAD of both kamailio and rtpengine. I got calls from webrtc to android working correctly (but only with Firefox browser), even with video. But in other directions i have some issues because of lack of RTP delivery or RTP timeouts. I have some logs to show you regarding this: https://gist.github.com/krieger-od/27c6f3e4924f5e21352e (works), https://gist.github.com/krieger-od/196bcfbd331d621427ef (doesn't work). I would really love to get some quick help from anyone. For direct manual fixing, I can give a couple of hundreds of bucks.
Looking forward impatiently for reply from anyone having something to say.
Write error on RTP socket usually indicates an incorrect network setup, for example trying to use a source address for IP packets which isn't bound to any local network interface (especially if you're sitting behind NAT), or local iptables rules rejecting outgoing IP packets, or missing IP routes to the destination. Perhaps post your network setup and the CLI arguments to rtpengine you're using.
cheers
2014-12-18 19:30 GMT+02:00 Richard Fuchs rfuchs@sipwise.com:
Write error on RTP socket usually indicates an incorrect network setup, for example trying to use a source address for IP packets which isn't bound to any local network interface (especially if you're sitting behind NAT), or local iptables rules rejecting outgoing IP packets, or missing IP routes to the destination. Perhaps post your network setup and the CLI arguments to rtpengine you're using.
I use VPS from DigitalOcean. Likely no NAT. Only one public IP, and one domain name used (whdd.org). Exactly the same situation was with Amazon VPS behind amazonish NAT. My configs are here: https://github.com/krieger-od/webrtc_kamailio_etc (only kamailio.cfg and modules.cfg are used, kamailio*.cfg are not). Also there you can check command line used to run rtpengine. To put it there, it is /home/krieger/rtpengine/daemon/rtpengine --interface=188.226.241.236 --listen-ng=127.0.0.1:22222 -m 30000 -M 35000 --foreground --log-stderr
On 12/18/14 12:55, Andrey Utkin wrote:
2014-12-18 19:30 GMT+02:00 Richard Fuchs rfuchs@sipwise.com:
Write error on RTP socket usually indicates an incorrect network setup, for example trying to use a source address for IP packets which isn't bound to any local network interface (especially if you're sitting behind NAT), or local iptables rules rejecting outgoing IP packets, or missing IP routes to the destination. Perhaps post your network setup and the CLI arguments to rtpengine you're using.
I use VPS from DigitalOcean. Likely no NAT. Only one public IP, and one domain name used (whdd.org). Exactly the same situation was with Amazon VPS behind amazonish NAT. My configs are here: https://github.com/krieger-od/webrtc_kamailio_etc (only kamailio.cfg and modules.cfg are used, kamailio*.cfg are not). Also there you can check command line used to run rtpengine. To put it there, it is /home/krieger/rtpengine/daemon/rtpengine --interface=188.226.241.236 --listen-ng=127.0.0.1:22222 -m 30000 -M 35000 --foreground --log-stderr
Amazon NAT is exactly why I've mentioned it, because on an Amazon system, if you don't use the --interface option correctly ($INT_IP!$EXT_IP notation), you get exactly these kinds of write errors that show in your log.
But these configs and this CLI line don't match the logs you posted earlier. Is it also write errors you're getting with those?
cheers
2014-12-18 20:05 GMT+02:00 Richard Fuchs rfuchs@sipwise.com:
Amazon NAT is exactly why I've mentioned it, because on an Amazon system, if you don't use the --interface option correctly ($INT_IP!$EXT_IP notation), you get exactly these kinds of write errors that show in your log.
Thank you, will try with such notation on amazon host now.
But these configs and this CLI line don't match the logs you posted earlier. Is it also write errors you're getting with those?
Will provide you shortly with logs from DigitalOcean VPS instance, configs for which i've published on github.
2014-12-18 20:09 GMT+02:00 Andrey Utkin andrey.krieger.utkin@gmail.com:
2014-12-18 20:05 GMT+02:00 Richard Fuchs rfuchs@sipwise.com:
Amazon NAT is exactly why I've mentioned it, because on an Amazon system, if you don't use the --interface option correctly ($INT_IP!$EXT_IP notation), you get exactly these kinds of write errors that show in your log.
Thank you, will try with such notation on amazon host now.
This alone haven't helped with Amazon instance. Will make tests from DigitalOcean instance and provide you with logs.
This works: call from sipml to linphone android: rtpengine: https://gist.github.com/krieger-od/bf8503fe7643c0571b58 kamailio: https://gist.github.com/krieger-od/c119d64af6edcde3fc46 ngrep: https://gist.github.com/krieger-od/cb5829be7a55a7acf9d3
This doesn't work: few seconds after answer, there's no media from remote subscriber, then linphone android agent hangs up; sipml hangs pretending being in call. rtpengine: https://gist.github.com/krieger-od/9eb120199ec99d1adcb4 kamailio: https://gist.github.com/krieger-od/26060c8d1d657458d9d2 ngrep: https://gist.github.com/krieger-od/d677864fcab8c508adde
2014-12-18 20:38 GMT+02:00 Andrey Utkin andrey.krieger.utkin@gmail.com:
This works: call from sipml to linphone android: rtpengine: https://gist.github.com/krieger-od/bf8503fe7643c0571b58 kamailio: https://gist.github.com/krieger-od/c119d64af6edcde3fc46 ngrep: https://gist.github.com/krieger-od/cb5829be7a55a7acf9d3
This doesn't work: few seconds after answer, there's no media from remote subscriber, then linphone android agent hangs up; sipml hangs pretending being in call. rtpengine: https://gist.github.com/krieger-od/9eb120199ec99d1adcb4 kamailio: https://gist.github.com/krieger-od/26060c8d1d657458d9d2 ngrep: https://gist.github.com/krieger-od/d677864fcab8c508adde
Doesn't work in different way: jssip web agent calls to android linphone: call is connected, but android doesn't see peer's video, and jssip doesn't have peer's audio: rtpengine: https://gist.github.com/krieger-od/cd63ef99d06212b30379 kamailio: https://gist.github.com/krieger-od/55c4b5785c5821315955 ngrep: https://gist.github.com/krieger-od/650575c0f96285d78d17
Also I encounter such issue: even in the working scenario, the hangup of one peer doesn't make the call end for another peer. rtpengine: https://gist.github.com/krieger-od/1cfe84b53dc0d29cfb90 kamailio: https://gist.github.com/krieger-od/11c6bbf7dad15382e81b ngrep: https://gist.github.com/krieger-od/ec6c21c6f9dde1400578
Also, this deploy of http://vmwrtc.intersog.com/sipml5/call.htm works ok, and official one http://sipml5.org/call.htm?svn=222 has more issues.
On 12/18/14 13:38, Andrey Utkin wrote:
This works: call from sipml to linphone android: rtpengine: https://gist.github.com/krieger-od/bf8503fe7643c0571b58 kamailio: https://gist.github.com/krieger-od/c119d64af6edcde3fc46 ngrep: https://gist.github.com/krieger-od/cb5829be7a55a7acf9d3
This doesn't work: few seconds after answer, there's no media from remote subscriber, then linphone android agent hangs up; sipml hangs pretending being in call. rtpengine: https://gist.github.com/krieger-od/9eb120199ec99d1adcb4 kamailio: https://gist.github.com/krieger-od/26060c8d1d657458d9d2 ngrep: https://gist.github.com/krieger-od/d677864fcab8c508adde
Couple of things to try here...
In the second case, Firefox kept sending answers (200 OK) for no good reason. Check Firefox's debug log / JS console / whatever if there's any error or warnings messages.
Try running rtpengine with the --dtls-passive switch, even though that shouldn't make a difference after ICE went through (which it does).
Add rtcp-mux=demux to your rtpengine flags in your Kamailio config, should be safe to use everywhere.
It's curious that Firefox was using RTP/SAVPF as protocol in one call and UDP/TLS/RTP/SAVPF in another. I don't suspect that this would cause a problem, but it's worth trying to specify the protocol not as RTP/SAVPF but rather as transport-protocol=UDP/TLS/RTP/SAVPF. Note that in the case of answers, you don't need to specify any protocol at all.
In the third case, the audio stream was setup as a=sendonly, explaining the one-way audio. Probably caused by Firefox not being able to access the playback device.
Last but not least, try a different browser, either a newer version of Firefox (it's up to v34 I see), or Chrome.
As for the call teardown, it's Kamailio's responsibility (through the config) to let rtpengine know that the call has been terminated, for example when handling the BYE method. Otherwise you'll see timeouts in rtpengine. Even though the BYE should still be relayed to the other SIP end, causing the call to be hung up there.
cheers
Richard Fuchs writes:
In the third case, the audio stream was setup as a=sendonly, explaining the one-way audio. Probably caused by Firefox not being able to access the playback device.
as i reported in another message, i have also lately noticed in my tests that firefox sends invite with a=sendonly attribute. still don't know why, because the same firefox can play audio without problems using the html <audio> tag.
-- juha
-
Andrey Utkin -
Juha Heinanen -
Richard Fuchs