not able to make a call on extension using external sip profile - freeswitch

I have just installed freeswitch on my system.Right now i am able to register sample extension(s) with external sip profiles
for example :
1000#x.x.x.x:5080
1001#x.x.x.x:5080
now i am dialing 1001 from extension 1000 then freeswitch console its showing me user not registered but i am already registered with 1001 extension.
As per my knowledge when i am dial 1001 then its try to call on internal profile that's why its showing user is not registered but from which place i have to change like call goes on my 1001 extension
any suggestions ? any ideas ?
Thanks in advance.

You can configure sip gateway.
Configuring a sip gateway allows you to connect with outside carriers or other SIP machines.
Gateways are associated with SIP profiles because FreeSWITCH needs to know which IP and port to send traffic to and from in relation to the carrier.
First, you'll need to add a gateway to your SIP profile. Let's assume you're using the default FreeSWITCH configuration. In this case, we'll create a gateway that is attached to the default external profile.
Create a file in the conf/sip_profiles/external/ directory named after your gateway
Add the following content (note that even if you are not registering, a username and password is required) but replace the highlighted items with your own provider:
<gateway name="providerA">
<param name="realm" value="sip.domain.com"/>
<param name="username" value="testuser"/>
<param name="password" value="test"/>
<param name="register" value="true"/>
</gateway>
You will access the gateway by using the bridge application with sofia/gateway/
providerA/number , such as sofia/gateway/providerA/4158867999 . You
can do this in any dialplan you are using. In this example, edit your dialplan (typically
the default dialplan in conf/dialplan/default.xml ) and add code to utilize
the gateway:
action application="bridge" data="sofia/gateway/providerA/$1"
Issue a reloadxml command in your FreeSWITCH CLI after making the
mentioned changes.

Related

Why does FreeSWITCH need to open non-secure port for SIPS/SRTP to work?

I configure the FreeSwitch's external profile with <param name="tls-only" value="false"/> and successfully setup a soft-phone client to make a fully secure connection to the FreeSwitch server (with signals over SIPS and voices over SRPT).
If I change to <param name="tls-only" value="true"/> or disable firewall access to the non-secured port then I can not make a dial from the soft-phone to the FreeSwitch. Consequently, I think that the non-secured port needs to open for the SIPS to work does not make sense.
Please, help me to figure it out. Thanks in advance!

Freeswitch -- Having TLS conversation but when a call starts, INVITE is send without encrypted

Good morning,
I’m trying to configure SRTP with TLS on Freeswitch. I already have SRTP, and I can establish a conversation with TLS, but when I make a call, it says “encrypted alert” and the TLS conversation stops sending the INVITE in TCP. I have been looking for some solutions and it states that the problema may be that the certificate is not properly configured or that TLS is not properly configured. It is imposible that the certificate has any problems because I currently get TLS untill the call starts.
Here it is the configuration on my profile:
<param name='rtp_secure_media' value='mandatory: AES_CM_128_HMAC_SHA1_80'/>
<param name='bind-params" value="tls"/>
<param name='tls-version' value='tlsv1'/>
<param name='register-transport' value='tls'/>
<param name="register" value="false"/>
<param name="transport" value="tls"/>
<param name="tls" value="$${internal_ssl_enable}"/>
<param name="tls-only" value="true"/>
<param name="tls-bind-params" value="transport=tls"/>
<param name="tls-sip-port" value="$${internal_tls_port}"/>
<param name="tls-cert-dir" value="/usr/local/freeswitch/conf"/>
<param name="tls-verify-date" value="true"/>
<param name="tls-verify-policy" value="none"/>
<param name="tls-version" value="$${sip_tls_version}"/>
<param name="tls-ciphers" value="$${sip_tls_ciphers}"/>
<param name="contact-params" value="tport=tls"/>
<param name="ws-binding" value="XX.XX.XX.XX:5061"/>
Also, I would like to make another observation: when I configure the bridge has transport=TLS ( ) in the dialplan, the debug says “TLS not supported by profile”
Thank you for taking the time to deal with my queries
Kind regards.
i had no experience on tls for freeswitch, but for the projects i had, we usually deploy opensips or kamailio ahead of freeswitch as a SIP proxy, which can bring sip over tls functionality easily in the whole topology structure.
the network looks like this:
freeswitch (group) opensips/kamalio other equipment or service
| ----(sip)----> | -------(sip over tls)------> |
| <======================(srtp)==========================> |
Keep the simplicity in freeswitch, and let the proxy handles all the protocols.
Actually opensips/kamailio can handle multiple protocols than tls, it can bring the flexiblity in your topology.

Exposing Web API in Service Fabric

I'm having trouble accessing my Web Api that has been deployed to my Service Fabric cluster. I've followed the new Stateless Web Api template and have added the http endpoint seen below. I also made modifications that to the OwinCommunication as depicted here.
<Resources>
<Endpoints>
<Endpoint Name="ServiceEndpoint" Type="Input" Protocol="http" Port="8080" />
</Endpoints>
</Resources>
When creating my cluster I added a custom endpoint of 80 to my Node Type.
The client connection endpoint to my cluster is: mycluster.eastus.cloudapp.azure.com:19000
Also, I have a load balancing rule that maps port 80 to backend port 8080 over TCP. The probe associated is on port 80, and I have tried both protocols (http and tcp), but neither seem to work.
Locally, I can access an endpoint on my Web Api by calling http://localhost:8080/health/ping, and get back "pong". When I attempt to access it in service fabric cluster, a file is downloaded. The URL I use to access it in the cloud is http://mycluster.eastus.cloudapp.azure.com:19000/health/ping. I've tried other ports (19080, 80, 8080) but they either hang or give me a 400.
My questions regarding exposing a Web Api in a service fabric cluster are:
Should the probe be http or tcp?
Should the probe backend port be set to the web api port (e.g. 8080)?
Is my URL/port correct for accessing my api?
Why is a binary file being downloaded? This happens in all browsers, and the content being displayed in postman and fiddler.
Found the answer to my question after a number of heuristics. If my Web Api endpoint is set to port 8080 then I need the following:
Probe for port 8080 on TCP
A load balancing rule with port 80 and backend port 8080
Access the Web Api over the following URL: http://mycluster.eastus.cloudapp.azure.com/health/ping
As for #4, this is still a mystery.
http://mycluster.eastus.cloudapp.azure.com:19000/health/ping
This is wrong.
It should be http://mycluster.eastus.cloudapp.azure.com:8080/health/ping
At least this what the documentation says. So it should work without touching the load balancer.

How do I configure opennms to monitor a specific service/process that is not defined out of the box in opennms?

There is no class defined corresponding to that service in opennms. The service is running on a remote host. The current protocols supported out of the box are:
Citrix
DHCP
DNS
Domino IIOP
FTP
HTTP
HTTPS
ICMP
IMAP
JBOSS
JDBC
JDBC Stored Procedure
JSR160
K5
LDAP
Microsoft Exchange
MX4J
Notes HTTP
NSClient (Nagios Agent)
NRPE (Nagios Remote Plugin Executor)
NTP
POP3
Radius
SMB
SMTP
SNMP
SSH
TCP
Is there a way to detect a service not in this list?
Adding the detector to the provisioning group will get the port listed as a service on a nodes particular interface. But to get it "monitored" you also need to add a matching poller. Here is a sample for generic DNS port 53 test.
provision group detector within the detectors section or via UI as Pete indicated:
<detector name="TCP-DNS-53" class="org.opennms.netmgt.provision.detector.simple.TcpDetector">
<parameter key="port" value="53"/>
</detector>
Matching poller-configuration.xml to get it monitored. i.e. events if the node stops responding to the port.
<!-- within the services section -->
<service name="TCP-DNS-53" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="3"/>
<parameter key="timeout" value="3000"/>
<parameter key="port" value="53"/>
<parameter key="banner" value="*"/>
</service>
Then a monitor definition near the bottom.
<monitor service="TCP-DNS-53" class-name="org.opennms.netmgt.poller.monitors.TcpMonitor"/>
The detector, service names and monitor service all have to be identical.
"Admin" -> "Node provisioning" -> "Manage Provisioning Requisitions" -> "Edit Default Foreign Source Definition" -> "Add detector" -> give it a name, select TCP -> "add parameter" -> "key": port, "value": port_used_by_service
You can check OpenNMS documentation (there's an example adding Telnet):
http://www.opennms.org/wiki/Provisiond

How Free Switch Profiles and Bridges work

What is the meaning of internal profile or external profile in Free Switch?
Also I don't know the meaning of -
application="bridge".
I also cannot understand
data="${sofia_contact($${gwuser}#$${domain})}"
or
data="sofia/internal/${destnumber}#192.168.10.33:5062"
It will be really helpful if someone could give me a proper explanation, or at least, point me to a right direction.
"internal" and "external" are names of sip profiles. Those are usually defined in the default configuration of freeswitch. They are sample configurations optimized for internal or external access, you can define other sip profiles with a configuration according to your needs.
application="bridge" is an application that bridges an incoming call to an other external or internal destination.
data="sofia/internal/${destnumber}#192.168.10.33:5062" means you want to use the sofia sipstack, the sip profile with the name "internal" with the content of the variable "destnumber" to ip 192.168.10.3 on port 5062.
Application bridge connects two channels(end-points) together.
sofia_* is the open source SIP protocol implementation developed by Nokia guys.
So, $${gwuser} is variable which contains the name of the user to call in SIP address notation: name#domain.
${domain} is the domain name.
sofia/internal/<adress> means that will be used internal sip number which is handled by local freeswitch PBX.
I think you should clarify a bit how freeswitch (mod_sofia) consider locally registered endpoints vs gateways:
http://wiki.freeswitch.org/wiki/Mod_sofia

Resources