Asterisk Authorization Header

Hi Support,

I’m not able to register to callcentric. On checking the headers, I see uri=“”

The “sip:sip” should not be there. But not sure where it is coming from.

From: <>;tag=as57b9b35c
To: <>
Call-ID: 1e97c4e62c9bbfe175f98ceb029d04be@
User-Agent: Asterisk PBX
Authorization: Digest username="1777236XXXX", realm="", algorithm=MD5, uri="", nonce="0f8d77ed42ae4882369cf2403ff7f1a0", response="5354e6008da66424ba242d843aedfd2f"
Expires: 120
Contact: <sip:s@>
Content-Length: 0

Is the registration failing due to it? How can it be corrected? Please help.

You haven’t provided the full register exchange and you haven’t provide the contents of your sip.conf.

This is my callcentric trunk config and work like charm



You don’t need insecure=invite if you have remotesecret. You may not even need insecure=port.

David 55 When is that you really need use the port,invite option. i see that many people don’t really understand the real usage of this option.

You need insecure=invite when the the peer will either never try to authenticate to you on an invite, or will try to authenticate to you using a secret which differs from the value of your secret setting. This typically happens with ITSPs who generally never try to authenticate. remotesecret makes this usage largely redundant, because you will never request authentication if you don’t have secret set and remotesecret covers the case where you need to supply authentication.

insecure=port means that you will accept invites from a different port number than the the one you got from the registration, or the one that you configured to statically send to. That might happen because of NAT, or because of the use of proxies. However, as with anything that reduces security, you should demonstrate a real need before using it.

Most of the cookbook uses of insecure seem to arise from ITSPs. Before remotesecret, they typically needed insecure=invite, but probably thought there was less likelihood of customer dissatisfaction if they made the customer as insecure as possible, so used very. I think the name, very, was coined to warn against excessive use, but failed in this. I think that requiring port,invite was then done to make people think about what they really needed, but, instead, people just translated very into port,invite, without thinking.