[Freeswitch-users] Sending SAVPF INVITE to Opensips

James Mortensen james.mortensen at synclio.com
Sun Sep 29 21:01:37 MSD 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130929/a5e0d5e7/attachment.html 


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list