Hi Kristian, 

No, I wasn't aware OpenSIPS handled WebSockets. Looks like it's even been supported since v1.9, which is the one we're using.

This gives us more to think about.  Thank you!

James

On Sat, Sep 28, 2013 at 4:22 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:

I'm glad it worked for you.

Are you aware that Opensips supports SIP over websockets and secure websockets natively?

On Saturday, September 28, 2013, James Mortensen wrote:

Hi Kristian,

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.  

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.

BANDWIDTH.com --udp-->  FreeSWITCH -udp-->  Opensips -udp--> OverSIP --ws--> Chrome WebRTC client.

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.

Thanks again! :)

James

On Sat, Sep 28, 2013 at 12:46 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:

James,

  There's quite a bit of detail omitted here but a few points:

- avpf=yes on your gateway definition isn't doing anything.
- Have you tried exporting media_webrtc=true before bridging back to Opensips?
- Try exporting the actual variables, not including variable_ :

<extension name="bandwidth.com inbound bridge">
    <condition field="destination_number" expression="^\+1(5035551212)$">

       <action application="answer" /> <!-- This probably shouldn't be
here either -->
       <action application="export" data="sip_auth_username=11234"/>
       <action application="export" data="sip_auth_password=password"/>
       <action application="export" data="media_webrtc=true"/>

       <action application="bridge"
data="sofia/external/ws-Opensips/11234@54.X.X.75"/>
    </condition>
  </extension>

- While you do want an "SAVPF INVITE" you really want a WebRTC SDP,
which includes much much more than just SAVPF.
- You'll probably want to do all other sorts of codec manipulation,
fixups, etc when bridging between typical SIP endpoints and WebRTC
endpoints.  Look into late negotiation and every codec
variable/setting you can find.
- You may want to re-consider the interaction and authentication
between OpenSIPS and FreeSWITCH.

  Also, what are you using OverSIP for in this scenario?

On Fri, Sep 27, 2013 at 8:26 PM, James Mortensen
<james.mortensen@synclio.com> wrote:
> Hello,
>
> I have a bandwidth.com number pointed to opensips, and a WebRTC peer
> registered with Opensips.  I'm trying to dial the 10 digit number from a
> cell phone and connect the call through FreeSWITCH to the Chrome WebRTC
> client.
>
>
> I defined opensips as a gateway, in the external profile:
>
> <include>
>    <gateway name="ws-Opensips">
>      <!-- <param name="from-user" value="fromuser"/> -->
>      <param name="from-domain" value="54.X.X.75"/>
>      <param name="proxy" value="54.X.X.75"/>
>      <param name="expire-seconds" value="600"/>
>      <param name="register" value="false"/>
>      <param name="retry_seconds" value="30"/>
>      <param name="extension" value="18257773456"/>
>      <param name="context" value="public"/>
>      <param name="avpf" value="yes"/>
>      <param name="username" value="11234"/>
>      <param name="password" value="password"/>
>    </gateway>
> </include>
>
>
> In the public dialplan context, I added in a condition to catch the INVITE
> coming in from opensips and pass it to a context I've called
> "default-inbound". See the second condition:
>
>  <extension name="from_opensips">
>     <condition field="network_addr" expression="^54\.X\.X\.75$"
> break="never"> <!--CUSTOMIZE-->
>       <action application="transfer" data="${destination_number} XML
> default"/>
>     </condition>
>     <condition field="network_addr" expression="^54\.X\.X\.111$">
> <!--CUSTOMIZE Use a third context here -->
>       <action application="transfer" data="${destination_number} XML
> default-inbound"/>
>     </condition>
>   </extension>
>
>
> Then, in the default-inbound context, I match the dialed number, answer the
> call leg from the PSTN, and then try to transfer back through opensips to
> oversip and to Chrome.  The problem is that I either end up sending back AVP
> INVITES, or Opensips refuses to authenticate the user.
>
> <extension name="

--
Sent from mobile device

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org