Hi Michele,

I’ve spoken to a colleague about this issue and have a new idea now as to why 
the SUBSCRIBE message is being rejected.

After Bono receives the SUBSCRIBE from the SIP device we can see the log:

24-07-2017 10:38:25.414 UTC Verbose pjsip: tcpc0x7f094c03 TCP transport 
10.2.0.127:5058 is connecting to 10.2.0.127:5060..

10.2.0.127 is the Bono node’s IP address. So this is telling us that Bono is 
forwarding the SUBSCRIBE to itself from its trusted port 5058 (used to 
communicate with the IMS core) to its untrusted port 5060 (which SIP devices 
send their requests to). We then see in the logs Bono receiving this SUBSCRIBE 
and then rejecting it.

So the question we need to resolve now becomes why is Bono routing the 
SUBSCRIBE to itself? To answer this we need to understand how SIP messages are 
routed. Messages containing SIP methods (like INVITEs, SUBSCRIBEs, REGISTERs 
etc.) are routed based off of the Route-header. If we look at the route headers 
for one of the SUBSCRIBERs we see:

Route: 
sip:scscf.cw-aio;transport=udp;lr;orig;username=6505550751%40example.com;nonce=716970855dbe8690

Here the port of the S-CSCF (5054) has not been included in the SIP address of 
the S-CSCF. We can also see from the logs that we do not retrieve a port number 
via SRV DNS lookup:

24-07-2017 10:38:25.414 UTC Debug dnscachedresolver.cpp:686: Received DNS 
response for _sip._udp.scscf.cw-aio type SRV
24-07-2017 10:38:25.414 UTC Warning dnscachedresolver.cpp:828: Failed to 
retrieve record for _sip._udp.scscf.cw-aio: Domain name not found

This means that Bono does not know which port to forward the message to and so 
it chooses 5060 which routes the message back to itself.

The next thing to consider then is why does the Route-Header not contain the 
port number? The Route header which is to be applied to future requests for a 
subscriber is communicated to Bono by the S-CSCF in a Service-Route header 
after it successfully authenticates a subscriber. If we have a look at the 200 
OK in response to the registration we see:

Service-Route: 
sip:scscf.cw-aio;transport=udp;lr;orig;username=6505550751%40example.com;nonce=716970855dbe8690

This means that it is the S-CSCF that is causing Bono to attach a Route header 
to the SUBSCRIBE which does not contain a port number. To figure out why the 
S-CSCF is doing this could you please send me a copy of 
/etc/clearwater/shared_config and /etc/clearwater/local_config from the SPN and 
a copy of the SPN log file during a REGISTRATION and SUBSCRIBE.

Thanks,

Andrew


From: Clearwater [mailto:[email protected]] On 
Behalf Of Michele Furlanetto
Sent: Monday, July 24, 2017 3:08 PM
To: [email protected]
Subject: Re: [Project Clearwater] [Clearwater] AS Configuration and untrusted 
sources

Hi Andrew,
Thanks for your response.

In attachment you can find what you asked me.
It’s about 15 minutes of logs, beginning with the service start.
An example of message being rejected can be found at line 72104, while the 
rejection is at 72399.

I had to censor part of contents and some headers of the messages, so there may 
be some inconsistencies.


Thanks,
Michele


Il giorno 24 lug 2017, alle ore 11:53, Andrew Edmonds 
<[email protected]<mailto:[email protected]>> ha 
scritto:

Hi Michele,

Thank you for your question.

It may be the case that you need to update your firewall rules to allow traffic 
from your SIP client to reach the Application Server. However in order to 
verify this I will need the Bono logs from the time which you attempted to 
contact the AS. Could you please provide these logs?

Thanks,

Andrew

From: Clearwater [mailto:[email protected]] On 
Behalf Of Michele Furlanetto
Sent: Tuesday, July 18, 2017 12:58 PM
To: 
[email protected]<mailto:[email protected]>
Subject: [Project Clearwater] [Clearwater] AS Configuration and untrusted 
sources

Hi all,
I’ve got a problem while configuring an AIO image.

In my scenario, there are is an AS, say 
as1.service.example.com<http://as1.service.example.com/>, which should get the 
third-party registration as well as being able to be addressed directly from 
the Sip client.

While third-party registration works, I’m unable to contact the AS directly.
Looking at Bono logs, I get Info bono.cpp:1356: Rejecting request from 
untrusted source.

Here is the content of 
/usr/share/clearwater/ellis/web-content/js/app-servers.json, indented to be 
more readable
{
“SERVICE”:"
<InitialFilterCriteria>
            <Priority>0</Priority>
            <TriggerPoint>
                        <ConditionTypeCNF>0</ConditionTypeCNF>
                        <SPT>
                                    <ConditionNegated>0</ConditionNegated>
                                    <Group>0</Group>
                                    <Method>REGISTER</Method>
                                    <Extension>
                                                
<RegistrationType>0</RegistrationType>
                                                
<RegistrationType>1</RegistrationType>
                                                
<RegistrationType>2</RegistrationType>
                                    </Extension>
                        </SPT>
                        <SPT>
                                    <ConditionNegated>0</ConditionNegated>
                                    <Group>1</Group>
                                    
<RequestURI>sip:as1.service.example.com<http://service.example.com/></RequestURI>
                        </SPT>
            </TriggerPoint>
            <ApplicationServer>
                        
<ServerName>sip:as1.service.example.com<http://service.example.com/>:5071;transport=UDP</ServerName>
                        <DefaultHandling>0</DefaultHandling>
                        <Extension>
                                    <IncludeRegisterRequest/>
                        </Extension>
            </ApplicationServer>
</InitialFilterCriteria>"
}

Some other details:
- SERVICE is checked in Ellis for test users;
- as1.service.example.com<http://as1.service.example.com/> is resolved using 
/etc/hosts.


Any hint on the error(s)?
Thanks,
Michele
_______________________________________________
Clearwater mailing list
[email protected]<mailto:[email protected]>
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

Reply via email to