Articles de 2013-08
asterisk SIP unregister not working
2013-08-03 15:40:17
For any reason, asterisk 11 requires a new SIP Call-ID to unregister a SIP account whereas RFC3261 SIP specification says that all REGISTERs should use the same Call-ID:
Call-ID: All registrations from a UAC SHOULD use the same Call-ID
header field value for registrations sent to a particular
registrar.
If the same client were to use different Call-ID values, a
registrar could not detect whether a delayed REGISTER request
might have arrived out of order.
Here is the paragraph in rfc3261 that proves that asterisk behavior is incorrect:
6. The registrar checks whether the request contains the Contact
header field. If not, it skips to the last step. If the
Contact header field is present, the registrar checks if there
is one Contact field value that contains the special value "*"
and an Expires field. If the request has additional Contact
fields or an expiration time other than zero, the request is
invalid, and the server MUST return a 400 (Invalid Request) and
skip the remaining steps. If not, the registrar checks whether
the Call-ID agrees with the value stored for each binding. If
not, it MUST remove the binding. If it does agree, it MUST
remove the binding only if the CSeq in the request is higher
than the value stored for that binding. Otherwise, the update
MUST be aborted and the request fails.
In my case, Call-ID is the same between register and unregister and unregister CSeq is higher than register CSeq.
If the same Call-ID is used between register and unregister, asterisk keeps returning 401 with a new challenge.
Nevertheless, apparently, asterisk accepts the same Call-ID for register-refreshes.
Opensips seems to accept different Call-ID between register and unregister, so let's go with that modification.
Peers updated accordingly.
Commentaires
For any reason, asterisk 11 requires a new SIP Call-ID to unregister a SIP account whereas RFC3261 SIP specification says that all REGISTERs should use the same Call-ID:
Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order.
Here is the paragraph in rfc3261 that proves that asterisk behavior is incorrect:
6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value "*" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails.
In my case, Call-ID is the same between register and unregister and unregister CSeq is higher than register CSeq.
If the same Call-ID is used between register and unregister, asterisk keeps returning 401 with a new challenge.
Nevertheless, apparently, asterisk accepts the same Call-ID for register-refreshes.
Opensips seems to accept different Call-ID between register and unregister, so let's go with that modification.
Peers updated accordingly.