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" /> 
<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-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"> 
> <action application="transfer" data="${destination_number} XML
> default"/>
> </condition>
> <condition field="network_addr" expression="^54\.X\.X\.111$">
> 
> <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="