Hi Ellie,
Thanks very much for help and sorry for the bono logs, maybe I've cut some 
important information. 
After a change I did in the bgcf.json, I've solved the problem. The INVITE 
massage was doing a loop between bono and sproute nodes. I've found a similar 
problem reported by Schahzad Zafar in this list (Subject: SIP truking). If I 
understood it correctly, the route value in bgcf.json must match with the 
public_hostname value in /etc/clearwater/config, so the bono/IBCF node can know 
that it has to route the message to external network, and not back to sprout. 
Now I'm able to make and receive calls.

I've found a problem with the ENUM server I've installed in sprout node. 
Apparently it was causing some conflict with another Clearwater component, 
probably dnsmasq. So for now I'm  using the ENUM file, as you said.

Lucas.

-----Mensagem original-----
De: Eleanor Merry [mailto:[email protected]] 
Enviada em: terça-feira, 29 de abril de 2014 13:12
Para: Lucas Simionato Bueno; '[email protected]'
Assunto: RE: [Clearwater] Gateway authentication for SIP trunking

Hi Lucas, 

>From the attached logs, it looks like:

 - An INVITE has come in from your X-Lite client to Bono (reqURI is "INVITE 
sip:[email protected] SIP/2.0") 
 - Bono looks at the top route header 
("<sip:sprout.184.73.8.45:5054;transport=TCP;lr;orig>") and sends the message 
to Sprout. 
 - Sprout then does an ENUM lookup for 8004284322, and rewrites the domain to 
75.101.186.30 (including in the RegURI). 
 - Sprout then does BGCF routing, finds an entry for the domain 75.101.186.30, 
and so tries to route the message to "184.73.8.45:5058" (e.g. Route: 
<sip:184.73.8.45:5058;transport=TCP;lr>)
 - There's then nothing in the attached Bono logs that suggests the INVITE 
actually gets routed there. 

Are there any later Bono logs? Also, what version of Sprout/Bono are you 
running ("dpkg-query -W <sprout/bono>")?

One thing from looking through the logs is that it looks like you have an 
external (184.73.8.45) and internal IP address (10.152.135.126) for your Bono 
node. Is this correct?
If so, are your port rules set up so that Bono will accept connections on its 
*external* IP address to port 5058? (Note that Bono should only open port 5058 
to other Bono nodes and the Sprout nodes). 
 
I'd need to see some more Sprout logs during a call to try and debug the 
incoming call issue. 

For your other questions: 

1. It's fine (and expected) that you have Bono and IBCF on the same node. 
2. You can set up an ENUM server on any node, so long as you set it in 
enum_server in the /etc/clearwater/config file on Sprout. Sprout will then send 
DNS queries to the ENUM server. This is the recommended method for ENUM lookups 
in Clearwater.
Alternatively, you can set up an ENUM file (like you have in 
/etc/clearwater/enum.json), and set this in enum_file in the 
/etc/clearwater/config file on Sprout. In this case, Sprout will use the 
entries in this file directly, and won't do DNS queries. 

Ellie 

-----Original Message-----
From: Lucas Simionato Bueno [mailto:[email protected]] 
Sent: 28 April 2014 20:24
To: Eleanor Merry; '[email protected]'
Subject: RES: [Clearwater] Gateway authentication for SIP trunking

Hi Ellie,

Thanks for the response.
I'm trying to set up my Clearwater deployment to allow SIP clients registered 
to make/receive calls to/from numbers in PSTN. For it I have a SIP trunk 
provider that needs authentication to make outgoing calls. 
For now I'm using Freeswitch as proxy between the SIP provider and Clearwater, 
but I'm having some trouble with the calls yet.
For incoming calls I have a number that reaches my SIP provider --> Freeswitch 
--> Clearwater registered user. My X-lite client rings when I dial this number 
using google phone for example, but when I answer the call, apparently the 
reverse path described above doesn't happen, so the call stay in an 
inconsistent state (google phone keeps ringing but X-lite already answered the 
call) .

For outgoing calls, when I dial some number in the X-lite client, the INVITE 
doesn't reach Freeswitch. Maybe this is related with the incoming call problem.

My configuration files:

/etc/clearwater/bgcf.json:
{
    "routes" : [
       {
           "name" : "outside net",
           "domain" : "75.101.186.30",
           "route"  : ["184.73.8.45:5058"]
       }
    ]
}

/etc/clearwater/enum.json:
{
    "number_blocks" : [
        {
           "name" : "Internal numbers",
           "prefix" : "650555",
           "regex" : "!(^.*$)!sip:\\[email protected]!"
        },

        {
            "name" : "External numbers",
            "prefix" : "",
            "regex" : "!(^.*$)!sip:\\[email protected]!"
        }
    ]
}

FREESWITCH              75.101.186.30
BONO/IBCF               184.73.8.45
SPROUT          174.129.92.239

I've added the Freeswitch IP to trusted hosts in bono -> user_settings.
I've attached some sprout and bono logs too. I've seen a lot of CANCEL messages 
in the logs, indicating a loop maybe.

I have some questions about bono/IBCF and ENUM.
I am using the same node for both bono and IBCF, is it a problem?
I realized that sprout was not making ENUM lookups, even with the configuration 
file set. I've installed a bind9 in the sprout node, as I described in 
(https://github.com/Metaswitch/clearwater-docs/wiki/ENUM), and now sprout makes 
the ENUM lookup correctly. Is it necessary to create another node for an ENUM 
server?

Thanks,
Lucas.


-----Mensagem original-----
De: Eleanor Merry [mailto:[email protected]] 
Enviada em: segunda-feira, 28 de abril de 2014 14:38
Para: Eleanor Merry; Lucas Simionato Bueno; 
'[email protected]'
Assunto: RE: [Clearwater] Gateway authentication for SIP trunking

Hi Lucas, 

Sorry, I meant to add this in my original email...

Do you have a need for this support in a particular timeframe? If so, can you 
let us know what you need it for?

Thanks,
Ellie

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Eleanor 
Merry
Sent: 28 April 2014 18:11
To: Daitan Labs - Lucas Simionato Bueno; 
'[email protected]'
Subject: Re: [Clearwater] Gateway authentication for SIP trunking

Hi Lucas, 

We don't support this. Sprout implicitly trusts requests coming over a 
configured SIP trunk (as these should never be registers, if sprout does 
receive a register over a sip trunk it will reject it with a 405). 

Also, thanks for pointing out the missing cookbook! We'll update the wiki 
instructions to include it.

Ellie

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Lucas 
Simionato Bueno
Sent: 25 April 2014 17:19
To: '[email protected]'
Subject: [Clearwater] Gateway authentication for SIP trunking

Hi,

I was configuring a SIP trunk in my Clearwater deployment, but reading the wiki 
I didn't find anything regarding to gateways authentication. Are there some 
configuration in Clearwater that I can do to connect directly to another SIP 
server with authentication, or it is only possible using some additional proxy?

Other thing that I had some trouble during the Clearwater installation, using 
the automated install 
(https://github.com/Metaswitch/clearwater-docs/wiki/Automated%20Install), was 
that when I tried to issue the command:

knife deployment resize -E <name> --ralf-count 1 -V

I was getting an error, interrupting the deployment. After see the logs, I 
found the problem (missing cookbook chef-solo-search), maybe something that 
could be added in the wiki 
(https://github.com/Metaswitch/clearwater-docs/wiki/Installing%20a%20Chef%20client),
 in the Upload Clearwater definitions to Chef server topic:


knife cookbook upload chef-solo-search

Thanks in advance,
Lucas.
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/listinfo/clearwater
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/listinfo/clearwater
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/listinfo/clearwater

Reply via email to