Alcatel 4018 - "481 Call Does Not Exist" on re-REGISTER
Hi! I've setup an Alcatel 4018 in SIP-Mode to register with FreeSWITCH. The initial registration after startup works fine - the phone sends a REGISTER -> FreeSWITCH answers with 401 -> UA sends REGISTER including authorization-data -> 200 OK But after a while the phone's registration expires, as it sends subsequent REGISTERs _with_ authorization-data right away, which is answered by FreeSWITCH with "481 Call Does Not Exist". I'm not exactly sure if the behaviour of the intitial REGISTER is required(Send authorization-data after 401 has been received) or if the proxy should understand a REGISTER including authorization data. If the latter is true, is there a parameter in FreeSWITCH to allow this behaviour? I've attached traces of both communications, the initial successful registration is "register_alcatel_success.dump", the failed registration is the trace in "register_alcatel_fail.dump" Best regards Christian
On 14 March 2011 11:59, Christian Benke <benkokakao@gmail.com> wrote:
I'm not exactly sure if the behaviour of the intitial REGISTER is required(Send authorization-data after 401 has been received) or if the proxy should understand a REGISTER including authorization data. If the latter is true, is there a parameter in FreeSWITCH to allow this behaviour?
Sorry, i left out some information. The traces are from two different sessions, i restarted the phone in between, so that's why the nonce has changed. I'll have to verify if the phone is actually reusing the initial nonce on the re-REGISTER in the same session.
I'll have to verify if the phone is actually reusing the initial nonce on the re-REGISTER in the same session.
See the attached full trace(I've removed some superfluous and identical OPTIONS and REGISTERs to make the file smaller), the phone is in fact reusing the first nonce forever. Is this a behaviour i could cover with FreeSWITCH? Unfortunately there's no parameter in the phone's config i could change(At least no documented parameter). Best regards, Christian
I hope my initial information is not the cause why this thread was not picked up! I still wonder if there is some way to configure FS to catch this unusual behaviour - otherwise i'll have to go back to the usual - reading the rfc and confirming that this is in fact broken behaviour - to get rid of the issue. Cheers, Christian
Change the cseq number (increment by 1) when you re-register. See if that fixes it. On Wed, Mar 16, 2011 at 10:10 AM, Christian Benke <benkokakao@gmail.com>wrote:
I hope my initial information is not the cause why this thread was not picked up!
I still wonder if there is some way to configure FS to catch this unusual behaviour - otherwise i'll have to go back to the usual - reading the rfc and confirming that this is in fact broken behaviour - to get rid of the issue.
Cheers, Christian
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- M. Ranganathan
On 16 March 2011 16:18, M. Ranganathan <mranga@gmail.com> wrote:
Change the cseq number (increment by 1) when you re-register. See if that fixes it.
The phone is in fact incrementing the CSeq already, so no, unfortunately this does not help(And i actually would not have any option to change it if it didn't). So this is what i found in the RFCs: http://www.ietf.org/rfc/rfc3261.txt 22.4.8. references RFC 2617(HTTP Authentication: Basic and Digest Access Authentication) http://www.ietf.org/rfc/rfc2617.txt 3.2.1 says: An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp for GET requests. and 4.3 Limited Use Nonce Values The Digest scheme uses a server-specified nonce to seed the generation of the request-digest value (as specified in section 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the server is free to construct the nonce such that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks (see 4.5). This makes a lot of sense of course, so i have plenty arguments now to ditch this phone(Alcatel 4018) as it is not behaving correctly(Unless i find a newer firmware). Regards, Christian
participants (2)
-
Christian Benke
-
M. Ranganathan