[asterisk-bugs] [JIRA] (ASTERISK-29665) pjproject silently drops registration requests using RFC 8898 syntax

[Sean Bright (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Bright updated ASTERISK-29665:
-----------------------------------

    Description: 
If a user agent tries to register using the OAuth-based token mechanism specified in [RFC 8898|https://www.rfc-editor.org/rfc/rfc8898.html], sip_transport.c logs error #2616 and discards the registration request, instead of returning a 407 Proxy Authentication Required error. The user agent, receiving no response from the server, repeatedly resends the registration request, with frequency as set in the user agent's configuration.

This came about when a service provider set in the OBi2182 that was previously used for Google Voice was changed to SIP and loaded with the registration data for the Asterisk server. The phone, instead of erasing the previous auth token when the service provider is changed, tries sending the old token to the Asterisk server. Presumedly, once the phone receives an error from the server it will then discard the token and try to re-register with an allowed authentication mechanism, but receiving no response, it just assumes the server is down and forever tries to register. Until the server or client software is fixed, the service provider slot is rendered permanently unavailable for SIP connections.

  was:
If a user agent tries to register using the OAuth-based token mechanism specified in [RFC 8898|https://www.rfc-editor.org/rfc/rfc8898.pdf], sip_transport.c logs error #2616 and discards the registration request, instead of returning a 407 Proxy Authentication Required error. The user agent, receiving no response from the server, repeatedly resends the registration request, with frequency as set in the user agent's configuration.

This came about when a service provider set in the OBi2182 that was previously used for Google Voice was changed to SIP and loaded with the registration data for the Asterisk server. The phone, instead of erasing the previous auth token when the service provider is changed, tries sending the old token to the Asterisk server. Presumedly, once the phone receives an error from the server it will then discard the token and try to re-register with an allowed authentication mechanism, but receiving no response, it just assumes the server is down and forever tries to register. Until the server or client software is fixed, the service provider slot is rendered permanently unavailable for SIP connections.


> pjproject silently drops registration requests using RFC 8898 syntax
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-29665
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29665
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip
>    Affects Versions: 18.6.0
>         Environment: FreePBX 15.0.17.55, OBi2182 phone running firmware version 6.2.3 (Build: 5330.1311)
>            Reporter: Robert Lenoil
>         Attachments: asterisk-29665.log.txt, asterisk log.html
>
>
> If a user agent tries to register using the OAuth-based token mechanism specified in [RFC 8898|https://www.rfc-editor.org/rfc/rfc8898.html], sip_transport.c logs error #2616 and discards the registration request, instead of returning a 407 Proxy Authentication Required error. The user agent, receiving no response from the server, repeatedly resends the registration request, with frequency as set in the user agent's configuration.
> This came about when a service provider set in the OBi2182 that was previously used for Google Voice was changed to SIP and loaded with the registration data for the Asterisk server. The phone, instead of erasing the previous auth token when the service provider is changed, tries sending the old token to the Asterisk server. Presumedly, once the phone receives an error from the server it will then discard the token and try to re-register with an allowed authentication mechanism, but receiving no response, it just assumes the server is down and forever tries to register. Until the server or client software is fixed, the service provider slot is rendered permanently unavailable for SIP connections.



--
This message was sent by Atlassian JIRA
(v6.2#6252)