I’ve set up an outbound registration with pjsip.
The process seems to be the following:
Asterisk sends a register request with “Expires: 0”. Probably to get rid of old registrations.
Then it sends the same register request with “Expires: 3600”. After authentication it gets registered. Fine!
But then it keeps sending register request with “Expires: 3600” every 80 seconds.
Is this some sort of keep alive or hole punching? How can I remove that behaviour?
That’s the registration part:
type = registration
transport = transport_home
outbound_auth = easybell_auth
server_uri = sip:sip.easybell.de:5064
client_uri = sip:[number]@sip.easybell.de
contact_user = [number]
I couldn’t find any variable in the documentation with a default of 80 seconds.
Thanks in advance!
You have to look at 200 OK from provider if contain a Expires: 80
Thanks! That’s it!
Sorry, I wasn’t aware, that there are two ways of transmitting expiration times: header field and/or contact parameter.
So the registrar does the registration, but the contact expires within 90 seconds. And Asterisk keeps registering with a header field value of 3600.
There is probably something wrong with the contact given.
I don’t think there is anything wrong with the Contact header. It is simply reflecting your ITSP’s policy.
Without checking, I assume that the expiry in the request says when the UAC intends to refresh the registration and that in the Contact, when the UAS requires it to do so.
That is correct - the expiration in a Contact or REGISTER Is what the client has requested, but the server is free to override that and provide back a different value which the client then has to re-register within. Exactly what is happening here, and perfectly fine.
Thanks for your replies.
Sorry, I haven’t dealt with “standalone” sip providers so far. My experience so far were dsl providers with sip service (next generation network). And they usually don’t allow nomadic registration. Probably that’s why they are usually keen on long intervals between registrations to lower the network traffic. (Just a guess.)
But if easybell offers 90 seconds, that’s fine with me. This way, there is no need to do any udp hole punching attempts, since the Linux conntrack module should recognize the registration traffic as “established” udp traffic (timeout for those is 180 seconds, as far as I can remember). Right?