SIP registration


Is there anyway to register a SIP client to Asterisk using the first registration pkt sent by the SIP client?

I normally see the following

SIP client ------register----> Asterisk
SIP client <—401/unauthorised- Asterisk
SIP client -----register-----> Asterisk
SIP client <—200 OK------- Asterisk

This is not a problem per say if there is not much delay in the link between SIP client and Asterisk. But if the link has more delay ( >600ms ), the SIP client is not able to register to the SIP server.


Don’t use passwords or fix the problem at the client end by getting it to volunteer the password on the first request. (Some, stronger, authentication schemes require a random challenge, so cannot be done without a double exchange.)


Can you tell me how to configure a Grandstream HT-502 to send the password in the first registration pkt ?

In a high latency network what I have seen is that the client sends the first registration pkt and then it waits for a while to get the response from Asterisk , before it gets response from Asterisk it sends the registration again assuming that the first reg. packet got lost. So it kind of goes to a race condition and finally gets unauthorised from Asterisk.

Perhaps Asterisk can be configured with some timers to avoid this…

I don’t have a Grandstream, and this is a Grandstream question, rather than an Asterisk 1.

User agents are not supposed to retry failed registers too aggressively. Again this is a Grandstream issue.

RFC 3261, 10.2.7 (UAC means the Grandstream, here):

[quote] If the transaction layer returns a timeout error because the REGISTER
yielded no response, the UAC SHOULD NOT immediately re-attempt a
registration to the same registrar.

  An immediate re-attempt is likely to also timeout.  Waiting some
  reasonable time interval for the conditions causing the timeout to
  be corrected reduces unnecessary load on the network.  No specific
  interval is mandated.[/quote]

I played with T1 timer in HT-502, but did not help.

Is there any way to have only INVITE authenticated but not the REGISTER, something like

insecure=REGISTER ?

One might as well not register at all in that case, as you would only be using the IP address to verify that outgoing calls were going to the real provider.

The clients gets dynamic IPs ( public or private )

In that case, disabling authentication on registration would allow anyone to hijack your outgoing calls.