Another problem with international SIP trunk access

306 views
Skip to first unread message

Paul Kramer

unread,
Apr 24, 2012, 10:58:50 PM4/24/12
to 2600h...@googlegroups.com
Hello, I've been following the thread at  https://groups.google.com/forum/?fromgroups#!topic/2600hz-dev/9P0wiGAsQ-Y with interest in regards to setting up access to a SIP trunk to make outgoing calls. At the moment after adding the catch_all call flow, there are only two _design documents in my offnet database. I decided to try the "/opt/whistle/whistle/utils/command_bridge/command_bridge stepswitch_maintenance reload_resources" command mentioned in the attached thread but received the following error:

[root@centos /]# /opt/whistle/whistle/utils/command_bridge/command_bridge stepswitch_maintenance reload_resources
Connection to service failed!
Failed to connect to service 'whistl...@hostname.com' with cookie 'd85318a70105f9e9cdb6493f42cd47bcfa8af69202f3e547'
  Possible fixes:
    * Ensure the whistle service you are trying to connect to is running on the host
    * Ensure that you are using the same cookie as the whistle node, "./command_bridge -c <cookie>"
    * Verify that the hostname being used is a whistle node

Can anyone point me in the right direction?


James Aimonetti

unread,
Apr 25, 2012, 12:21:46 AM4/25/12
to 2600h...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First, running the reload_resources will do nothing if there are no
resource docs in the DB. If you only have design docs in your offnet
DB, you have no resources with which to make offnet calls. A sample
resource document looks something like:

{
"_id": "4063c60c6771f239561a4af34a01e696",
"_rev": "8-2e59d8e5af246be75b36d44de5123900",
"pvt_type": "resource",
"pvt_created": 63471586790,
"pvt_modified": 63471586790,
"name": "Your Carrier - Friendly Name",
"enabled": true,
"flags": [
],
"weight_cost": 50,
"rules": [
"^\\+1(\\d{10})$"
],
"gateways": [
{
"server": "carrier.hostname.or.ip",
"realm": "carrier.hostname.or.ip",
"username": "maybe_a_username",
"password": "maybe_a_password",
"prefix": "",
"suffix": "",
"codecs": [
"PCMU"
],
"progress_timeout": 8,
"enabled": true
}
]
}

Change accordingly.

As for the command_bridge suggestions:

1) ps -ef | grep whistle_apps
Will let you know if the whapps VM is running (hint: it should be;
if not, use whistle_apps/start.sh or whistle_apps/start-dev.sh to get
an interactive session going)

2) Check the cookie value in your output below against the '-setcookie
XYZ' in whistle_apps/conf/vm.args, and if they differ, use '-c
cookie_from_your_vm.args_file'

3) Ensure running 'hostname' returns what you expect (a fully
qualified domain), and that that matches whistl...@hostname.com.

Hope that helps you get going...

On 04/24/2012 07:58 PM, Paul Kramer wrote:
> Hello, I've been following the thread at
> https://groups.google.com/forum/?fromgroups#!topic/2600hz-dev/9P0wiGAsQ-Y
> with interest in regards to setting up access to a SIP trunk to
> make outgoing calls. At the moment after adding the catch_all call
> flow, there are only two _design documents in my offnet database. I
> decided to try the
> "/opt/whistle/whistle/utils/command_bridge/command_bridge
> stepswitch_maintenance reload_resources" command mentioned in the
> attached thread but received the following error:
>

> *[root@centos /]#
> /opt/whistle/whistle/utils/command_bridge/command_bridge
> stepswitch_maintenance reload_resources* *Connection to service
> failed!* *Failed to connect to service 'whistl...@hostname.com'
> with cookie 'd85318a70105f9e9cdb6493f42cd47bcfa8af69202f3e547'* *
> Possible fixes:* * * Ensure the whistle service you are trying
> to connect to is running on the host* * * Ensure that you are


> using the same cookie as the whistle node, "./command_bridge -c

> <cookie>"* * * Verify that the hostname being used is a whistle
> node*


>
> Can anyone point me in the right direction?
>
>
>


- --
James Aimonetti
Distributed Systems Engineer / DJ MC_

2600hz | http://2600hz.com
sip:ja...@2600hz.com
tel: 415.886.7905
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPl3vaAAoJENc77s1OYoGg65EIAJqyJzNlxOqEHfGdez67wW/s
+sBX5VaoZ7yiCuWN/neUmMQuPH07h2ujVovVieHVa6P4nhH8oPYtewkoFn0p3n90
ecg+XO6jlWvYfvvdREldMU7OfPvYYsqG5lPchgy3YQf+pss4IkcFGjfhfVatIaV6
lryd1V0croH7P4XvNQfe/O6TIkgy0paEp5LyBOxWiLezeGm1TdTGR0oFEL4l1zXR
Vn57P3MZ9PORhR74tjhzNvOUoCSgJSjJQeTbK1vF9HZPOzD4O2nyIvi2yqPvYK3L
SMCBYzWk64wwgXCSp/08vOI/oWXPnYGyy8PQhXBba/sPqpIf+Du3j7SX7r3W6pM=
=hU+y
-----END PGP SIGNATURE-----

Paul Kramer

unread,
Apr 25, 2012, 11:02:39 AM4/25/12
to 2600h...@googlegroups.com
I've created the document and verified that whistle_apps was running, the cookie was the same in both locations and that the hostname is an accurate FQDN. Unfortunately I'm still getting the same error when running /opt/whistle/whistle/utils/command_bridge/command_bridge stepswitch_maintenance reload_resources.

Paul Kramer

unread,
May 16, 2012, 8:12:43 AM5/16/12
to 2600h...@googlegroups.com
Unfortunately after deploying another server, I'm still encountering the same issue - no offnet database documents are being created after creating trunks in Winkstart. I also receive "Error: 400" when attempting to create the catch all route for outgoing calls. Is this a problem others are experiencing?

Darren Schreiber

unread,
May 16, 2012, 10:38:03 AM5/16/12
to 2600h...@googlegroups.com
Can you verify the sysconf whapp is running and/or restart it?

Also what do you mean "After deploying another server" - is this deploying an all-in-one dev server or a new, entire 7 server cluster?

--
Darren Schreiber
CEO / Co-Founder


 visit: www.2600hz.com
 tel: 415-886-7901

Paul Kramer

unread,
May 17, 2012, 8:52:49 AM5/17/12
to 2600h...@googlegroups.com
I deployed another single server to try and lockdown the commands needed to get a server up and running. After reading the 1.52 command notes, it looks like the catch all route has been deprecated and is implied with the creation of a carrier. I ran a wireshark capture on my Whistle server and established that the server was in fact trying to contact my SIP trunk provider, however the requests are timing out - i'm guessing because my ITSP requires SIP registration before a trunk can be offered for outbound calls.

Here is an example of the outbound gateway i've setup in /opt/freeswitch/conf/sip_profiles/external.xml:

  <gateway name="vitelity-inbound">
    <param name="username" value="****yourusername"/>
    <param name="password" value="****yourpassword"/>
    <param name="realm" value="vitel-inbound"/>
    <param name="extension" value="1000"/>
    <param name="proxy" value="****inboundurl"/>
    <param name="register-proxy" value="****inboundurl"/>
  </gateway>
</include>

The wireshark trace isn't capturing any registration activity from the Whistle server to the ITSP: do I need to make any changes in the Whistle dialplan to support this scenario?

Thanks,

Paul

Darren Schreiber

unread,
May 18, 2012, 5:54:21 PM5/18/12
to 2600h...@googlegroups.com
Registrations must still be done via the FreeSWITCH XML if your upstream provider requires registration. Frankly most wholesale providers use IP-based auth which is most secure so we coded for that. But it seems a lot of people want to register.

Please add the info to /etc/freeswitch/gateways/*.xml (make a name like "vitelity.xml". Our stock configs look in there.

Paul Kramer

unread,
May 19, 2012, 3:48:21 AM5/19/12
to 2600h...@googlegroups.com
Are you sure the xml shouldn't be saved in /opt/freeswitch/conf/sip_profiles/? In the past this is the location I've used for SIP registrations. The directory /etc/freeswitch didn't exist; after creating the directory and xml file, the trunk didn't attempt to register (proved by a packet capture).

Most comercial ITSPs in Australia use IP authetication for their SIP trunks, however the provider I'm testing with is not business grade hence the need to register.

James Aimonetti

unread,
May 19, 2012, 11:46:56 AM5/19/12
to 2600h...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think Darren meant /opt/freeswitch for the configs...

On 05/19/2012 12:48 AM, Paul Kramer wrote:
> Are you sure the xml shouldn't be saved in
> /opt/freeswitch/conf/sip_profiles/? In the past this is the
> location I've used for SIP registrations. The directory
> /etc/freeswitch didn't exist; after creating the directory and xml
> file, the trunk didn't attempt to register (proved by a packet
> capture).
>
> Most comercial ITSPs in Australia use IP authetication for their
> SIP trunks, however the provider I'm testing with is not business
> grade hence the need to register.
>
> On Saturday, 19 May 2012 07:54:21 UTC+10, Darren Schreiber wrote:
>>
>> Registrations must still be done via the FreeSWITCH XML if your
>> upstream provider requires registration. Frankly most wholesale
>> providers use IP-based auth which is most secure so we coded for
>> that. But it seems a lot of people want to register.
>>
>> Please add the info to /etc/freeswitch/gateways/*.xml (make a
>> name like "vitelity.xml". Our stock configs look in there.
>>
>> -- Darren Schreiber CEO / Co-Founder
>>
>>
>> * visit: *www.2600hz.com * sip*:dar...@2600hz.com * tel:
>> *415-886-7901
>>> -- Darren Schreiber CEO / Co-Founder
>>>
>>>
>>> * visit: *www.2600hz.com * sip*:dar...@2600hz.com * tel:
>>> *415-886-7901
>>>>> *[root@centos /]#
>>>>> /opt/whistle/whistle/utils/command_bridge/command_bridge
>>>>> stepswitch_maintenance reload_resources* *Connection to
>>>>> service failed!* *Failed to connect to service
>>>>> 'whistl...@hostname.com' with cookie
>>>>> 'd85318a70105f9e9cdb6493f42cd47bcfa8af69202f3e547'* *
>>>>> Possible fixes:* * * Ensure the whistle service you are
>>>>> trying to connect to is running on the host* * * Ensure
>>>>> that you are using the same cookie as the whistle node,
>>>>> "./command_bridge -c <cookie>"* * * Verify that the
>>>>> hostname being used is a whistle node*
>>>>>
>>>>> Can anyone point me in the right direction?
>>>>>
>>>>>
>>>>>


- --
James Aimonetti
Distributed Systems Engineer / DJ MC_

2600hz | http://2600hz.com
sip:ja...@2600hz.com
tel: 415.886.7905
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPt8BwAAoJENc77s1OYoGgwPkIAIbNm7K+kKqkaEH5soSE+2wr
/xGpCL2ZhDgIOvOx0jNKUprjVgDGfehSEErd4VvyUfa4I6MUn8Cx5IiK14CBh3U0
GuzOE1Kpic0fSPk1N9wXgot2U9hAVF0d//hoUSZ/4XmP18bMF6xe+/uOq9jM+58q
MSgLfJv02aeTO8wlPgfpw/AjJSqONH9Dvg/Q9xJ1vmDjrvSxwtCHqK/4lxs6o3dz
AcVwRFxL5BOCe6lVckkltULomHQgRoxma5D85iHNj4uSFXhsNni1YgCJvtuGTh8U
Dpzw2t31O1Do8PARVSWc1Yh7ecdLAi8oQ6lirrmM2PavwMFhyYHDA0uRP1iLLT4=
=GLDF
-----END PGP SIGNATURE-----

Darren Schreiber

unread,
May 19, 2012, 12:24:09 PM5/19/12
to 2600h...@googlegroups.com
We have modified the default FreeSWITCH configs to use a directory that was NOT part of the FreeSWITCH config structure by default. That way, when you install a new RPM, it doesn't clobber your existing config files.

If you look in the bottom of the existing opt/freeswitch/conf/sip_profiles/internal.xml you will see this line:
            <X-PRE-PROCESS cmd="include" data="/etc/freeswitch/gateways/*.xml"/>

That is what allows your individual gateways in /etc/freeswitch/gateways to be included, and never overwritten.

I'm open to other ideas but that's what we've got for now.

Darren Schreiber

unread,
May 19, 2012, 12:24:59 PM5/19/12
to 2600h...@googlegroups.com
Nope, I meant /etc/freeswitch/gateways/ :-)

I intentionally put them OUTSIDE the /opt/freeswitch/ world in case you
need to reinstall the RPM completely.

Paul Kramer

unread,
Jun 7, 2012, 9:19:48 AM6/7/12
to 2600h...@googlegroups.com
Ahh good thinking... I have the external.xml gateway file in the /opt Freeswitch location for now and it seems to be registering (fs_cli proves this). There is now a problem in that an external call is offered to the SIP trunk and then after five seconds, cancelled by Freeswitch. It seems something is missing in the original invite. Would it be OK if I sent you the trace Darren?

Darren Schreiber

unread,
Jun 11, 2012, 11:50:38 PM6/11/12
to 2600h...@googlegroups.com
Please scrub the FS Log and then paste the log to the list or as a pastebin (you can make the pastebin expire after a few days). We'll take a look.

--
Darren Schreiber
CEO / Co-Founder


Reply all
Reply to author
Forward
0 new messages