[Freeswitch-users] Sending SAVPF INVITE to Opensips

Mon Sep 30 18:44:42 MSD 2013

Yes, FreeSWITCH supports webSockets natively, but if you're setting up a
cluster of servers then it helps to have a proxy to act as a SIP
registration endpoint.  We also have some Asterisk servers handling legacy
clients, and OpenSIPS acts as a proxy for them as well.

James

James

*"Every Call, Every Time!"*

How did I do?

[image: Happy] <https://secure.teamhively.com/welcome/rate/735/3>[image:
Satisfied] <https://secure.teamhively.com/welcome/rate/735/2>[image:
Unhappy] <https://secure.teamhively.com/welcome/rate/735/1>

Click on a face to provide feedback on my
performance!<https://secure.teamhively.com/welcome/rate/735>

Synclio Extension:*  110627*
Phone: * 866-707-4590*
Skype: *No!* *Call me on Synclio! :)*

On Mon, Sep 30, 2013 at 5:19 AM, Michael Jerris <mike at jerris.com> wrote:

> Were you aware that FreeSWITCH also supports websockets natively?
>
> On Sep 29, 2013, at 1:01 PM, James Mortensen <james.mortensen at synclio.com>
> wrote:
>
> 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 at 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 at 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 at 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 at 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=" <http://bandwidth.com/>
>>>
>>>
>>
>> --
>> Sent from mobile device
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130930/47001cdc/attachment.html 