I am not expert in asterisk but know few things in asterisk. I want to learn more about the asterisk. On my device, I am using asterisk 13 and operating system OpenWRT(Linux distro).
After googling and researching, I was able to configure my sip configuration but was not able to understand all of them or find related documents.
Can somebody please explain me the parameters such as: insecure, qualify, canreinvite, nat, keepalive, trustrpid, sendrpid, alwaysauthreject, srvlookup?
Please do not use insecure without understanding it!
Insecure=invite causes Asterisk to accept incoming calls without authenticating the caller. This was often necessary before the introduction of remotesecret, as ITSPs expect you to authenticate yourself, but don’t authenticate themselves to you.
insecure=port allow calls from the “wrong” port number, and should only be used if really required (e.g. TCP)
I’m not convinced that canreinvite=nonat means anything, as canreinvite was replaced by dierctmedia, I think, before nonat was added.
nat = yes is deprecated. It is roughly equivalent to nat=force_rport, comedia, and causes Asterisk to behave as though the rport option had been used, and causes it to wait for incoming media, and then send outgoing media to the same address., rather than the one in the SDP.
tos_* probably do nothing as ISPs don’t honour them.
Could you explain what is wrong with the descriptions in sip.conf.sample.
keepalive is too new for me, but is probably about ensuring there is always activity.
trustrpid means use the Remote-Party-ID or P-Asserted-Identity headers, if present, to get caller ID and receive connected party updates.
sendrpid causes Asterisk to send Remote-Party-Id, or P-Asserted-Identity, as selected by the option, and enables the sending of Re-INVITEs when the connected party changes.
alwaysauthreject causes Asterisk to behave in a way in which an attacker finds it difficult to know what they got wrong. I think it means send 401, even though you already know that the attacker is bogus, but I’m not sure.
svrlookup has something to do with DNS SVR records, but I’ve never used those.
These are off the top of my head. sip.conf.samples may give better explanations.
If I remove “insecure=invite”, incoming is not working, so I thought I am doing something wrong with those properties. But, if I add"insecure=invite" it works fine.
As I said, ITSP’s don’t authenticate themselves.
However, in my view, replacing secret by remotesecret is a clearer way of doing the same thing; it just wasn’t available when most cookbooks were written.
It means it does not send 401 in response to an INVITE from the party that has that insecure option in their sip.conf entry, even though they do have a secret, or md5secret, in that same entry.
remotesecret is a newer option that causes Asterisk to use the value only for outgoing authentication. It may be combined with secret to have different secrets in each direction. insecure=invite is an older option that disables authentication in the inbount direction, only for INVITEs, not REGISTERs.
And what exactly falls under outgoing authentication?
Asterisk registering to a voice service provider as well as sending a modified invite after being challenged to authenticate by a 401 unauthorized?
As I understand it, the insecure=invite is there to prevent your server to challenge the ITSPs with a 401.
Does remotesecret have the same effect, cause I see it’s recommended as an alternative?
What is the benefit of being able to use different secrets in each direction with remotesecret?
If you use remotesecret, and not secret it will not challenge for authentication on any transaction, including REGISTER. That is typically the right thing for ITSPs.
So the difference between insecure=invite and remotesecret would then be that remotesecret will not challenge on any transaction, whereas insecure=invite will not challenge only on Invites (but would challenge on Register e.g.).
Probably, but the real reason is that remotesecret is a new feature. In practice, insecure=invite is only used with host=dynamic, so inbound REGISTER would never happen.