Diego, The fix below is in the "latest" build and I've installed it on my system. As expected, the ACK sent by the browser _does_ now make it to Boghe.
Unfortunately, there is no media - it seems that Google Chrome doesn't even send media over the network and, although Boghe is sending media to it, Google Chrome seems to ignore this. I'm suspicious that these components don't interoperate - there are various posts on discuss-webrtc that suggest maybe not (e.g. https://groups.google.com/forum/?fromgroups#!topic/discuss-webrtc/CzrlBWde-s4). Do you know if this is known to work in non-Clearwater scenarios? Matt -----Original Message----- From: Matt Williams Sent: 04 June 2013 10:55 To: [email protected] Subject: RE: [Clearwater] RES: Support for WebRTC clients Diego, Just a heads-up that I've got to the bottom of the problem in which the ACK sent by the browser doesn't make it to Boghe, raised https://github.com/Metaswitch/sprout/issues/63 and am testing a fix. I hope to have it tested, reviewed, merged and released into the "latest" build today. Matt -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matt Williams Sent: 31 May 2013 23:07 To: [email protected] Subject: Re: [Clearwater] RES: Support for WebRTC clients Diego, Thanks for the update. I hadn't tested calls from sipml5 to Boghe, but I've just tried it and can _almost_ reproduce the problem you describe. In my repro, the 200 OK _does_ get back to the browser and the browser sends an ACK. However, the ACK does _not_ make it back to Boghe. It looks as though this is a problem with the Route headers, but I haven't got to the bottom of it yet - I'll have more of a look on Monday. Is it possible that you're seeing the same thing (i.e. the 200 OK reaching the browser but the ACK not getting back) or is the 200 OK definitely not reaching the browser? If the latter, are there any useful logs in bono/sprout*.log - do you see the 200 OK being sent? Please let me know. Thanks, Matt -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Diego Carvalho Domingos Sent: 31 May 2013 21:27 To: [email protected] Subject: [Clearwater] RES: Support for WebRTC clients Hi Matt, thanks for the replies and sorry for the delay in response We could register. It was a configuration issue that we found out after enabling the trace you mentioned. Thanks again. Unfortunately, we couldn't make a call between sipml5 and boghe. After calling from sipml5, boghe rings but after answering, the 200-OK does not get back to the browser. We didn't discovered why yet. Again we think there is some wrong configuration. Was you able to make a call between boghe and sipml5? And about the issue, probably we didn't face it because we tried a simpl5 to boghe call, not the opposite. Please let me know if you have any luck on sipml5 <--> boghe calls. Att, Diego Carvalho Domingos ________________________________________ De: [email protected] [[email protected]] em nome de Matt Williams [[email protected]] Enviado: quinta-feira, 30 de maio de 2013 16:57 Para: [email protected] Assunto: Re: [Clearwater] Support for WebRTC clients Diego, Did you have any luck finding out why the registration wasn't succeeding? The issue in which sprout crashes when making an outbound call with Boghe (https://github.com/Metaswitch/sprout/issues/45) is now fixed. It won't be in the "stable" release until the middle of next week, but the fix is in the "latest" release, if you need it sooner. Please let me know how you get on. Thanks, Matt From: Matt Williams Sent: 28 May 2013 18:37 To: [email protected] Subject: RE: [Clearwater] Support for WebRTC clients Diego, I've just had a quick play with Boghe and can successfully REGISTER. The diagnostics outlined below would be useful to identify why your deployment behaves differently. However, I hit an issue (https://github.com/Metaswitch/sprout/issues/45) in which sprout crashes when making an outbound call because the Privacy header is not as expected. We're looking into this, but just a heads-up in case you get past the registration issue and then hit this issue yourself. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Williams Sent: 28 May 2013 16:43 To: [email protected]<mailto:[email protected]> Subject: Re: [Clearwater] Support for WebRTC clients Diego, It's good to hear you've successfully made a sipml5-sipml5 call. On the issue you're seeing with registration, please can you capture the SIP message that's being sent? The easiest way to do this is to turn up the log level on bono by * logging into the bono node * writing 'log_level=5' to /etc/clearwater/user_settings * restarting bono. Hopefully we'll then be able to tell where bono is trying to send the SIP message (and why). I think it should be possible to make calls between sipml5 and boghe (although we haven't tried it) - I wasn't sure whether it supported AVPF, but it sounds like it does. Please let me know how you get on. Thanks, Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Diego Carvalho Sent: 28 May 2013 15:50 To: [email protected]<mailto:[email protected]> Subject: Re: [Clearwater] Support for WebRTC clients Hi Matt, We've successfully set clearwater and made a sipml5 -> sipml5 call. According to sipml5 documentation, it is possible to call some softphones that support all webrtc mandatory features. They call those softphones rich clients. As you can see in this link: https://code.google.com/p/sipml5/wiki/Calling_SIP_clients They have a rich client called boghe and since they say it is possible to call from sipml5 to boghe (through webrtc2sip), theoretically, it also would be possible make this call through clearwater. The problem here is that I can't sing in using one of my clearwater accounts. On boghe I set the proxy-CSCF to point to Bono and I see the following error on Bono's logs (/var/log/bono/): sprout<date>.txt 28-05-2013 13:44:25.319 Warning pjsip: tsx0x7fa41c081 Failed to send Request msg REGISTER/cseq=17232 (tdta0x7fa41c07a710)! err=70018 (gethostbyname() has returned error (PJ_ERESOLVE)) log<date>.txt 28-05-2013 13:44:25.319 Call-Disconnected: CALL_ID=e5426435-f9cb-5064-cdad-241062817746 REASON=408 Do you know what is causing this error? Thanks in advance. _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
