Sending SAVPF INVITE to Opensips
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="bandwidth.com inbound bridge"> <condition field="destination_number" expression="^\+1(5035551212)$"> <action application="answer" /> <action application="set" data="variable_sip_auth_username=11234"/> <action application="set" data="variable_sip_auth_password=password"/> <action application="bridge" data="sofia/external/ws-Opensips/11234@54.X.X.75"/> </condition> </extension> As you can see, I've hard-coded my peer, 11234, in the configuration. This is a registered user on Opensips. How can I get FreeSWITCH to send the SAVPF INVITE through to Opensips for the WebRTC portion of the call leg? I apologize if this is covered somewhere, but I've been wracking my brain on this for days and am not getting anywhere. The Opensips configuration I have works with existing Asterisk 11 servers, and I'm hoping I can just simply plug in FreeSWITCH servers seamlessly into the mix. Thank you! James
in your ws-Opensips gateway definition, you have "register" set to "false" If you change it to "true", FreeSWITCH will authenticate on that gateway. is that what you try to achieve? ________________________________ From: James Mortensen <james.mortensen@synclio.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Sent: Saturday, September 28, 2013 2:26 AM Subject: [Freeswitch-users] Sending SAVPF INVITE to Opensips 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="bandwidth.com inbound bridge"> <condition field="destination_number" expression="^\+1(5035551212)$"> <action application="answer" /> <action application="set" data="variable_sip_auth_username=11234"/> <action application="set" data="variable_sip_auth_password=password"/> <action application="bridge" data="sofia/external/ws-Opensips/11234@54.X.X.75"/> </condition> </extension> As you can see, I've hard-coded my peer, 11234, in the configuration. This is a registered user on Opensips. How can I get FreeSWITCH to send the SAVPF INVITE through to Opensips for the WebRTC portion of the call leg? I apologize if this is covered somewhere, but I've been wracking my brain on this for days and am not getting anywhere. The Opensips configuration I have works with existing Asterisk 11 servers, and I'm hoping I can just simply plug in FreeSWITCH servers seamlessly into the mix. Thank you! James _________________________________________________________________________ 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
Hi Stanislav, Opensips doesn't register our media servers, it just passed traffic through it and is all based on IP address. What I'm trying to do is get FreeSWITCH to take an AVP INVITE from Bandwidth.com, answer that call leg, then send an SAVPF INVITE to Opensips then to OverSIP and finally to a Chrome client. Instead, it's sending an AVP INVITE. Hence, the INVITE reaches my Chrome client endpoint, but Chrome responds, rightly so, with a 488 Not Acceptable Here because Chrome only supports SAVPF profiles. In Asterisk, in the gateway configuration, I would put avpf=yes to tell Asterisk to send the INVITE with SAVPF, but on FreeSWITCH, since WebRTC is so new, and since I'm only about a week into my experiences with FreeSWITCH, the documentation for this is tough to find. Hope this helps clarify, and thanks for responding. James On Sat, Sep 28, 2013 at 3:29 AM, Stanislav Sinyagin <ssinyagin@yahoo.com>wrote:
in your ws-Opensips gateway definition, you have "register" set to "false" If you change it to "true", FreeSWITCH will authenticate on that gateway.
is that what you try to achieve?
------------------------------ *From:* James Mortensen <james.mortensen@synclio.com> *To:* FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Sent:* Saturday, September 28, 2013 2:26 AM *Subject:* [Freeswitch-users] Sending SAVPF INVITE to Opensips
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="bandwidth.com inbound bridge"> <condition field="destination_number" expression="^\+1(5035551212)$"> <action application="answer" /> <action application="set" data="variable_sip_auth_username=11234"/> <action application="set" data="variable_sip_auth_password=password"/> <action application="bridge" data="sofia/external/ws-Opensips/11234@54.X.X.75"/>
</condition> </extension>
As you can see, I've hard-coded my peer, 11234, in the configuration. This is a registered user on Opensips.
How can I get FreeSWITCH to send the SAVPF INVITE through to Opensips for the WebRTC portion of the call leg? I apologize if this is covered somewhere, but I've been wracking my brain on this for days and am not getting anywhere.
The Opensips configuration I have works with existing Asterisk 11 servers, and I'm hoping I can just simply plug in FreeSWITCH servers seamlessly into the mix.
Thank you!
James
_________________________________________________________________________ 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
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="bandwidth.com inbound bridge"> <condition field="destination_number" expression="^\+1(5035551212)$"> <action application="answer" /> <action application="set" data="variable_sip_auth_username=11234"/> <action application="set" data="variable_sip_auth_password=password"/> <action application="bridge" data="sofia/external/ws-Opensips/11234@54.X.X.75"/>
</condition> </extension>
As you can see, I've hard-coded my peer, 11234, in the configuration. This is a registered user on Opensips.
How can I get FreeSWITCH to send the SAVPF INVITE through to Opensips for the WebRTC portion of the call leg? I apologize if this is covered somewhere, but I've been wracking my brain on this for days and am not getting anywhere.
The Opensips configuration I have works with existing Asterisk 11 servers, and I'm hoping I can just simply plug in FreeSWITCH servers seamlessly into the mix.
Thank you!
James
_________________________________________________________________________ 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
-- Kristian Kielhofner
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="bandwidth.com inbound bridge"> <condition field="destination_number" expression="^\+1(5035551212)$"> <action application="answer" /> <action application="set" data="variable_sip_auth_username=11234"/> <action application="set" data="variable_sip_auth_password=password"/> <action application="bridge" data="sofia/external/ws-Opensips/11234@54.X.X.75"/>
</condition> </extension>
As you can see, I've hard-coded my peer, 11234, in the configuration. This is a registered user on Opensips.
How can I get FreeSWITCH to send the SAVPF INVITE through to Opensips for the WebRTC portion of the call leg? I apologize if this is covered somewhere, but I've been wracking my brain on this for days and am not getting anywhere.
The Opensips configuration I have works with existing Asterisk 11 servers, and I'm hoping I can just simply plug in FreeSWITCH servers seamlessly into the mix.
Thank you!
James
_________________________________________________________________________ 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
-- Kristian Kielhofner
_________________________________________________________________________ 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
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=" <http://bandwidth.com>
-- Sent from mobile device
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=" <http://bandwidth.com>
-- 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
Were you aware that FreeSWITCH also supports websockets natively? On Sep 29, 2013, at 1:01 PM, James Mortensen <james.mortensen@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@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
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@jerris.com> wrote:
Were you aware that FreeSWITCH also supports websockets natively?
On Sep 29, 2013, at 1:01 PM, James Mortensen <james.mortensen@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@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=" <http://bandwidth.com/>
-- 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
_________________________________________________________________________ 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
Oh yeah, that too :)! On Mon, Sep 30, 2013 at 8:19 AM, Michael Jerris <mike@jerris.com> wrote:
Were you aware that FreeSWITCH also supports websockets natively?
On Sep 29, 2013, at 1:01 PM, James Mortensen <james.mortensen@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@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
_________________________________________________________________________ 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
-- Kristian Kielhofner
Were you aware that FreeSWITCH also supports websockets natively? On Sep 29, 2013, at 1:01 PM, James Mortensen <james.mortensen@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@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
I do not know if anyone has come accross this, I have someone hacking into an SPA8000, no ideal how, and relaying 011xx.t calls out to my freeswitch. I have of course disabled access of the gateway to the freeswitch but do need to turn it up again. I have seen a report to cisco on this problem but no ideal where it comes from. Anythoughts or ideas would be appreciated. my syslog from the spa8000 looks like this Darcy Primrose
I wanted to follow up on Kristian's question about OpenSIPS and WebSocket support. According to what I've read, OpenSIPS only supports WS/WSS Via header parsing but doesn't actually have a WebSocket module to accept WebSocket connections. According to the OpenSIPS documentation as well as the release notes, one must front-end OpenSIPS with OverSIP. http://www.opensips.org/Documentation/Tutorials-WebSocket Hope this helps! 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=" <http://bandwidth.com>
-- 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
participants (5)
-
fs
-
James Mortensen
-
Kristian Kielhofner
-
Michael Jerris
-
Stanislav Sinyagin