I went a little forward, removing the line relative to as1.service.example.com 
<http://as1.service.example.com/> in file /etc/hosts and adding 

srv-host=_sip._udp.scscf.cw-aio,scscf.cw-aio,5054
srv-host=_sip._udp.as1.service.example.com,example.com,5071

to /etc/dnsmasq.conf.

now the SUBSCRIBEs (and other messages) are delivered to as1, but I’ve lost the 
working third-party registration.

After fixing this, the next step for me will be adding another AS, as2, which 
will dialog only with as1.
The simplest think I could try is adding 
srv-host=_sip._udp.as2.service.example.com,example.com,5072
but is not enough. What configuration I’m missing?

Thank you,
Michele


> Il giorno 26 lug 2017, alle ore 11:27, Michele Furlanetto 
> <[email protected]> ha scritto:
> 
> Hi Andrew,
> 
> As I said, I didn’t configure any DNS service to support our AS, 
> all I did in this way was adding the lines to /etc/hosts
> 
> 10.2.0.91 as1.service.example.com <http://participant.mcptt.example.com/>
> 10.2.0.127 example.com <http://example.com/>
> 
> In attachment you can find the local_config and shared_config files.
> 
> Referring the previous message, my SIP client does use the same port for both 
> REGISTER and SUBSCRIBE.
> 
> Thank you for your support,
> Michele
> 
> <local and shared configs.zip>
> 
> 
>> Il giorno 25 lug 2017, alle ore 15:40, Andrew Edmonds 
>> <[email protected] <mailto:[email protected]>> ha 
>> scritto:
>> 
>> 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
>>  
>> <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
>>  
>> <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
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

Reply via email to