Don't know if this is a Feature request, but maybe. I'm trying to use SS for all my calls independently of the source or target and everything goes great (honestly). But, I've found a problem trying to make SIP URI calls. Most of the cases I have no Audio/Video.
As read in this Forum, this problem is caused by NAT and our incapacity of managing/handling UDP ports. Understood. Therefore, the only solution is handling this call through a 3rd Party Proxy. But, how to send a SIP URI call through a Provider in SS?
Sip uri call to : voicecall@conference.com
Req.URI.User: voicecall
Req.URI.Host: conference.com
My Provider: Callcentric
If I try sys.Dial("Callcentric") SS wil execute a call to voicecall@callcentric not to my original SIP URI.
I know that I'm not forced to use SS for SIP URI Calls. My Bria client is able to execute directly this call but I've got unhappily surprised that some other SIP clients apps are not able to do it. I need a solution that works everywhere anytime and I prefer to do it through SS.
How to Proxy a SIP URI Call to avoid NO Audio
Re: How to Proxy a SIP URI Call to avoid NO Audio
Using Callcentric Via SipSorcery through Some ATA's or Some Voip Phones Have Problems with One Way Audio.
The Best Thing You can Do for Fixing your Problem is Use IpKall instead CallCentric.
The Best Thing You can Do for Fixing your Problem is Use IpKall instead CallCentric.
Re: How to Proxy a SIP URI Call to avoid NO Audio
What you're encountering is the biggest flaw with the design of SIP or more correctly the SIP/RTP combination. The designers of SIP put NAT in the too hard basket when they were writing the protocol and consequently everyone that has set up SIP infrastructure on the internet has had to deal with it ever since. For a slightly more in depth discussion see http://www.sipsorcery.com/mainsite/Help/SIPAudio.
As to the solution TURN was supposed to be the answer but I only know of one public TURN server and it's experimental and I couldn't get it to work. Subsequently the focus shifted to ICE which is more like a conglomeration of protocols that attempt to find a compatible set of sockets that the two endpoints of a SIP call can exchange their RTP media on. Significantly if the ICE exchange fails then the last resort is to use TURN which is pretty useless for the reason listed previously.
If you're attempting SIP URI calls to other SIP clients directly rather than going through a provider than ICE is actually your best option at present. A number of SIP softphones support ICE and the Bria softphone does, you can check whether it's activated on the Topology tab of each SIP account in the Bria SIP account configuration. If the destination end of the call is also using ICE then there's a chance you'll be able to find a compatible set of media sockets that will get through both your NATs. Failing that you could set up port forwarding rules on your router to always allow a certain RTP port range to be used by your softphone. That's a bit of fiddling around though and you need to have a pretty good idea what you are doing.
As to the solution TURN was supposed to be the answer but I only know of one public TURN server and it's experimental and I couldn't get it to work. Subsequently the focus shifted to ICE which is more like a conglomeration of protocols that attempt to find a compatible set of sockets that the two endpoints of a SIP call can exchange their RTP media on. Significantly if the ICE exchange fails then the last resort is to use TURN which is pretty useless for the reason listed previously.
If you're attempting SIP URI calls to other SIP clients directly rather than going through a provider than ICE is actually your best option at present. A number of SIP softphones support ICE and the Bria softphone does, you can check whether it's activated on the Topology tab of each SIP account in the Bria SIP account configuration. If the destination end of the call is also using ICE then there's a chance you'll be able to find a compatible set of media sockets that will get through both your NATs. Failing that you could set up port forwarding rules on your router to always allow a certain RTP port range to be used by your softphone. That's a bit of fiddling around though and you need to have a pretty good idea what you are doing.
Re: How to Proxy a SIP URI Call to avoid NO Audio
Thanks DoDo. But I have no problems with Callcentric and I've only use it as example. I just need to do a SIP URI call through ANY Provider.
Thanks Aaron. Quite complicated as I really do not know what's in the other side. These are 3rd Party Services with no detailed info on their infrastructure.
But, back to my main question: How to make a SIP URI call through a Provider? I'm able to do it if I connect my SIP client directly to the Provider but, is there a way to do it through SS?
Thanks Aaron. Quite complicated as I really do not know what's in the other side. These are 3rd Party Services with no detailed info on their infrastructure.
But, back to my main question: How to make a SIP URI call through a Provider? I'm able to do it if I connect my SIP client directly to the Provider but, is there a way to do it through SS?
Re: How to Proxy a SIP URI Call to avoid NO Audio
Nope, not unless the Provider in question has explicit support for 3rd party URI dialling. I've never come across one that does and it would be the email equivalent of an open relay i.e. open to abuse by spammers.
Re: How to Proxy a SIP URI Call to avoid NO Audio
Finally, I've found a solution using Callcentric (this time yes they are).
Using Speed Dial feature in Callcentric Phone Book, I've created a list of SIP URI Call Services like:
*7501 voicebridge@provider1.com
*7502 voicebridge@provider2.com
Then, I've include them all *75XX in my SS outgoing Dialplan. Now I need only to remember those shortcode for calling my services.
Another important advantage is that I can use this short codes from anywhere. Using Callback/Calltru/etc, I'm able to call a SIP URI even from my mobile phone just by dialing shortcodes.
Using Speed Dial feature in Callcentric Phone Book, I've created a list of SIP URI Call Services like:
*7501 voicebridge@provider1.com
*7502 voicebridge@provider2.com
Then, I've include them all *75XX in my SS outgoing Dialplan. Now I need only to remember those shortcode for calling my services.
Another important advantage is that I can use this short codes from anywhere. Using Callback/Calltru/etc, I'm able to call a SIP URI even from my mobile phone just by dialing shortcodes.