<div dir="ltr">Hi Kristian, <div><br></div><div>No, I wasn't aware <span style="color:rgb(102,102,102);font-family:'Trebuchet MS',sans-serif,Verdana,Arial;font-size:13px;line-height:21.578125px">OpenSIPS</span> handled WebSockets. Looks like it's even been supported since v1.9, which is the one we're using.</div>
<div><br></div><div>This gives us more to think about. Thank you!</div><div><br></div><div class="gmail_extra"><div><div dir="ltr"><div><br></div><div>James<br></div><div><br><div><br></div></div></div></div><br><div class="gmail_quote">
On Sat, Sep 28, 2013 at 4:22 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com" target="_blank">kris@kriskinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm glad it worked for you.<div><br></div><div>Are you aware that Opensips supports SIP over websockets and secure websockets <span></span>natively?<div><div class="h5"><br><br>On Saturday, September 28, 2013, James Mortensen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Kristian,<div><br></div><div>You're right, what I want is a WebRTC SDP, which FreeSWITCH is clearly capable of generating as it does this with the default configuration by default if port 5066 is enabled for the ws-binding parameter. </div>
<div><br></div><div>To answer your question, OverSIP sits in front of Opensips between the Chrome client and Opensips. Chrome can only register with a SIP endpoint using websockets, so OverSIP listens on a TCP/WS port and passes the SIP messages to Opensips.</div>
<div><br></div><div>BANDWIDTH.com --udp--> FreeSWITCH -udp--> Opensips -udp--> OverSIP --ws--> Chrome WebRTC client.</div><div><br></div><div>It looks like what I was missing was the <action application="export" data="media_webrtc=true"/> and using application export instead of set. I was able to get an inbound call routed to my Chrome client, answer it, and experience two way audio.</div>
<div><br></div><div><br></div><div>Thanks again! :)</div><div><br></div><div class="gmail_extra"><div><div dir="ltr"><div><br></div><div>James<br></div><div><br><div><br></div></div></div></div><br><div>
On Sat, Sep 28, 2013 at 12:46 PM, Kristian Kielhofner <span dir="ltr"><<a>kris@kriskinc.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
James,<br>
<br>
There's quite a bit of detail omitted here but a few points:<br>
<br>
- avpf=yes on your gateway definition isn't doing anything.<br>
- Have you tried exporting media_webrtc=true before bridging back to Opensips?<br>
- Try exporting the actual variables, not including variable_ :<br>
<div><br>
<extension name="<a href="http://bandwidth.com" target="_blank">bandwidth.com</a> inbound bridge"><br>
<condition field="destination_number" expression="^\+1(5035551212)$"><br>
</div> <action application="answer" /> <!-- This probably shouldn't be<br>
here either --><br>
<action application="export" data="sip_auth_username=11234"/><br>
<action application="export" data="sip_auth_password=password"/><br>
<action application="export" data="media_webrtc=true"/><br>
<div> <action application="bridge"<br>
data="sofia/external/ws-Opensips/11234@54.X.X.75"/><br>
</condition><br>
</extension><br>
<br>
</div>- While you do want an "SAVPF INVITE" you really want a WebRTC SDP,<br>
which includes much much more than just SAVPF.<br>
- You'll probably want to do all other sorts of codec manipulation,<br>
fixups, etc when bridging between typical SIP endpoints and WebRTC<br>
endpoints. Look into late negotiation and every codec<br>
variable/setting you can find.<br>
- You may want to re-consider the interaction and authentication<br>
between OpenSIPS and FreeSWITCH.<br>
<br>
Also, what are you using OverSIP for in this scenario?<br>
<div><div><br>
<br>
On Fri, Sep 27, 2013 at 8:26 PM, James Mortensen<br>
<<a>james.mortensen@synclio.com</a>> wrote:<br>
> Hello,<br>
><br>
> I have a <a href="http://bandwidth.com" target="_blank">bandwidth.com</a> number pointed to opensips, and a WebRTC peer<br>
> registered with Opensips. I'm trying to dial the 10 digit number from a<br>
> cell phone and connect the call through FreeSWITCH to the Chrome WebRTC<br>
> client.<br>
><br>
><br>
> I defined opensips as a gateway, in the external profile:<br>
><br>
> <include><br>
> <gateway name="ws-Opensips"><br>
> <!-- <param name="from-user" value="fromuser"/> --><br>
> <param name="from-domain" value="54.X.X.75"/><br>
> <param name="proxy" value="54.X.X.75"/><br>
> <param name="expire-seconds" value="600"/><br>
> <param name="register" value="false"/><br>
> <param name="retry_seconds" value="30"/><br>
> <param name="extension" value="18257773456"/><br>
> <param name="context" value="public"/><br>
> <param name="avpf" value="yes"/><br>
> <param name="username" value="11234"/><br>
> <param name="password" value="password"/><br>
> </gateway><br>
> </include><br>
><br>
><br>
> In the public dialplan context, I added in a condition to catch the INVITE<br>
> coming in from opensips and pass it to a context I've called<br>
> "default-inbound". See the second condition:<br>
><br>
> <extension name="from_opensips"><br>
> <condition field="network_addr" expression="^54\.X\.X\.75$"<br>
> break="never"> <!--CUSTOMIZE--><br>
> <action application="transfer" data="${destination_number} XML<br>
> default"/><br>
> </condition><br>
> <condition field="network_addr" expression="^54\.X\.X\.111$"><br>
> <!--CUSTOMIZE Use a third context here --><br>
> <action application="transfer" data="${destination_number} XML<br>
> default-inbound"/><br>
> </condition><br>
> </extension><br>
><br>
><br>
> Then, in the default-inbound context, I match the dialed number, answer the<br>
> call leg from the PSTN, and then try to transfer back through opensips to<br>
> oversip and to Chrome. The problem is that I either end up sending back AVP<br>
> INVITES, or Opensips refuses to authenticate the user.<br>
><br>
> <extension name="<a href="http://bandwidth.com" target="_blank"></a></div></div></blockquote></div></div></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Sent from mobile device<br>
</font></span><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div>