How to set desired contact user in replies

Hi Comminty.

Version 16.28. I know, pretty ancient and not much support anymore.

I have come across a mostly cosmetic issue.

When an initial invite is sent to the Asterisk it contains:

INVITE sip:Bob@destdomain:port;transport;line
From: Alice@fromdomain
To: Bob@destdomain
Contact: Alice@fromdomain

When Bob picks up the phone a 200 OK is sent:
200 OK
From: Alice@fromdomain
To: Bob@fromdomain
Contact sip:fromdomain:port;transport

The contact_user is empty. This is not from Bob’s phone behind Asterisk, which had sent a contact username. That is generated by Asterisk.

I have attempted to set contact_user in type=register,aor and endpoint.
I have attempted to set contact=sip:user@domain in aor

None populates the contact username in replies.

Is it possible to have the contact username properly filled in replies? Ideally with the sip username of the corresponding invite?


Note this is the endpoint section.

Also note that this was only added to Asterisk to work round broken providers. The user part of Contact, if any, should be returned unmodified and has no defined meaning for anything other than the user agent that sent the header. As such, you should treat any user name here as opaque. Whilst Asterisk doesn’t use the user name another user agent could use it for an internal reference that isn’t related to what the user sees.

Basically, you should not manipulate this for cosmetic reasons, as you may come across a system that actually uses it. You may need to set it to work round user agents that misuse or wrongly reject the domain name only form.

Hi David. I am aware this has no meaning, except to the calling CPE which displays this information :slight_smile:
Also the contact_user setting in the endpoint is related to requests, not to replies.
My problem is with the reply, 180 ringing 183 progress, 200 OK generated by asterisk as some CPE display the contact user when receiving a reply.


I don’t think any providers have tried to read things into the Contact header on 200 OK responses, so there hasn’t been a need to set a bogus user part.

Generally called numbers should be sent using P-Asserted-Identity, or Remote-Party-ID, not Contact.