SIP Invite fields getting swapped?

Asterisk Asterisk Support
1

Has anyone seen a case where the to and from fields of an SIP invite packet are getting swapped in Asterisk 11.2.1? I started using CallCentric SIP this week to supplement my current Sotel SIP provider (both for Trunking). When doing a test call to my Asterisk PBX, I see an error message:

[May 8 21:20:35] NOTICE[1024][C-00000000]: chan_sip.c:25081 handle_request_invite: Sending fake auth rejection for device “CALIFORNIA CALL” <sip:1NXXNXXXXX@(CallCentric’s IP Address)>;tag=3577062035-626165

Where ‘device “CALIFORNIA CALL” <sip:1NXXNXXXXXX@(CallCentric’s IP Address)>’ is actually the data that is contained in the “from” field of the Invite packet.

Here is the data from the sniffed packet:

“INVITE sip:***********@(My Router’s IP Address):5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.170:5060;branch=z9hG4bK-649527bc7907bb013a25f9bcfba4dd92
f: “CALIFORNIA CALL” <sip:1NXXNXXXXXX@(CallCentric’s IP Address)>;tag=3577062280-620808
t: <sip:(My CallCentric DID Extension)@ss.callcentric.com>
…”
(Trucated for clarity by me).

Here is my sip.conf for CallCentric with passwords and IP’s removed:

[CallCentric-Trunk]
type=peer
host=callcentric.com
fromdomain=callcentric.com
deny=0.0.0.0/0.0.0.0
permit=(CallCentric’s First Public Subnet)/255.255.255.0
permit=(CallCentric’s Second Public Subnet)/255.255.255.0
nat=force_rport,comedia
srvlookup=yes
dtmfmods=rfc2833
insecure=invite,port
canreinvite=no
disallow=all
allow=ulaw
allow=g729
context=*
defaultuser=*
fromuser=*
authuser=*
secret=*

Is there a way to push out the full SIP authentication attempt info to a file for debugging/logging from within Asterisk? Any ideas?

2

That is intended behaviour, for a failed authentication.

That configuration will only accept incoming calls from 161.58.244.246, the address to which concentric.com resolves. If they originate from other addresses, you will need to define peers for each address, or use allowguest, with careful attention to your firewall settings.

Uncomment full in logger.conf, then do:

logger reload
core set verbose 5
core set debug 5
sip set debug on

Also, canreinvite is a deprecated parameter name, and insecure=…,port is rarely a necessary relaxation of security. remotesecret is a better solution to the problem that ITSPs try to solve by suggesting insecure=…

3

Interesting: “That is intended behaviour, for a failed authentication”

I never would have though that scrambling invite packet data was a normal response for anything… Hmm - I would have expected a message “authentication failure for <sip:(actual SIP account)@(Remote IP Address)>” if there was an authentication failure for a SIP account…

You have the “concentric” I presume that was a typo - I am asking about CallCentric.com which resolves out to:

204.11.192.10

Not sure where you got the 161… IP address. What you seem to be saying is that there is a collision with the “host” and “fromdomain”, and the:

deny=0.0.0.0/255.255.255.0 (-all subnets)
permit=204.11.192.0/255.255.255.0 (+subnet 204.11.192.xxx)
permit=66.193.176.0/255.255.255.0 (+subnet 66.193.176.xxx)

lines… With callcentric.com resolving to 204.11.192.10, that should be correctly filtered to the permit=204.11.192.0/255.255.255.0 subnet range. But if what you are saying is true, having the:

host=callcentric.com
fromdomain=callcentric.com

lines is making Asterisk ignore all of the subsequent “deny”/“permit” lines. Is that what you’re saying (just trying to be crystal clear here… because the documentation made zero mention of this anywhere…).

As per your remotesecret suggestion, I read in the source that the default behavior was to use “secret” (outbound password) if remotesecret (inbound password) was not set… Is that broken or no longer the case? I ask because the other SIP account I have with Sotel is set the same way and it works without.

Follow-Up Note: I commented out the host and from domain lines in the sip.conf and the calls are now completing correctly. I think this is a change in the documentation that should be immediately reviewed and added - it pertains directly to security (since you had suggested using “allowguest” which I would have stopped using CallCentric before turning on!!)

The error message would be better output as:

[May 8 21:20:35] NOTICE[1024][C-00000000]: chan_sip.c:25081 handle_request_invite: Sending fake auth rejection for device <sip:(DIDNUMBER)@(CallCentric’s IP Address)>;tag=3577062035-626165 - Source IP did not match rules:
host=callcentric.com
fromdomain=callcentric.com
permit=204.11.192.0/255.255.255.0
permit=66.193.176.0/255.255.255.0

This would have made it easier to track down the point of failure.

4

Sorry about misreading the host name.

On a peer entry, only the address that host maps to will be recognized as a source address. Your specifying a range of permitted addresses suggests that they may use more than one source address. The permit lines will not be ignored, but you will only notice their effect on a non-dynamic peer entry if they exclude the address specified by host. It is more likely, in this case, that the source address does not match the host parameter.

fromdomain is only relevant for outbound calls, and is mainly used when the ITSP authentication scheme is based on the From header, rather than using that for the upstream caller ID.

Your complaint about swapping addresses appears to represent a misunderstanding by you of the error message. It is the from address that would be used to identify the a user or friend, not the to address, which is never used to identify the peer. The intent of the message was clearly to output the information from the from address, not that from the to address.

The parsing of the SIP headers is done with the intent of extracting the required information from valid headers, and a valid configuration, and with correctly rejecting invalid requests, not with the intent of providing a detailed analysis of configuration errors. However, under normal circumstances, you would be welcome to provide replacement source code to produce a more helpful message. This would have to be based on all the circumstances that could produce that message, not just your particular example. The code will not generally have the source form of the configuration file easily to hand when it produces it.

However, the whole of the SIP handling code is going to be replaced in Asterisk 12, and any such contribution would be a feature request with patch, and would have to be against the trunk version, i.e. version 12. As backporting it would not be easy, it would be unlikely to help current users.

The difference between secret and remotesecret is that secret is (also) used to authenticate in the inbound direction. As most ITSPs won’t do that, you then have to weaken the security by using insecure. If you use remotesecret without secret, Asterisk will not try to check the password, that the ITSP will never provide, on inbound calls. The name of the “insecure” option is chosen to make it clear that it is doing something potentially undesirable.