Hi All,
We are using a DID provided by a telco provider. While placing a call we are not sending an authorisation header in the initial invite packet because of which the telco is replying with forbidden instead of 401 unauthorised.
Is there a possibility that we can send the authorisation in our initial invite packet ? Does asterisk provide this functionality ? if yes can you please suggest us the configuration we need to do to achieve this.
You can’t, as that’s not how SIP works. A SIP client sends a SIP request, the remote side then challenges it (with information that is used to then authenticate), and then the SIP client sends the SIP request again with authentication.
Have you inquired with the provider as to why they are not challenging you for authentication? It’s entirely possible your configuration is incorrect, so they don’t know the user account.
Hi!
@satyammongia, if you are using user+password to place calls try use remotesecret (available for chan_sip).
Some companies accept our first Invite when sent with credentials/digest.
Paste some SIP DEBUG will help
remotesecret doesn’t affect the protocol used for outgoing requests. What it does is allow you you specify different secrets in each direction, or to have a secret only in the outgoing one without needing the hack of using insecure=invite.
Whilst is possible to send credentials on the first invite, when using the, normal, digest method, there has to be a preceding exchange in which 401 was sent, as that is the only way to know the correct nonce value. You can only resolve that if the service provider accepts an unauthenticated INVITE (or one with the wrong nonce) and sends a 401 with the correct nonce.
Nonces are periodically changed, so you can only avoid the two stage process if they new request follows soon after the one that resulted in the 401.