Mobile SIP client handling bug

Hi all

I guess there is a bug in the handling of SIP clients which frequently change their IP address (several times a day or even per minute). When running a SIP client on a mobile phone, I end with a crashed asterisk over and over again.
What it looks like then: (sip show channels)

Peer User/ANR Call ID Format Hold Last Message Expiry
194.xxx.xxx.28 (None) 179986421288@17 0x0 (nothing) No Rx: REGISTER
62.xxx.xxx.62 080070xxxx 26e5119852464af 0x8 (alaw) No
80.xxx.xxx.53 (None) 2ecfee4f3462256 0x0 (nothing) No (d) Init: OPTIONS
80.xxx.xxx.53 (None) 0b0af8b00442356 0x0 (nothing) No (d) Init: OPTIONS
62.xxx.xxx.62 080070xxxx 3ef1e21570bf5ee 0x8 (alaw) No
80.xxx.xxx.53 044508xxxx 105388567794@17 0x8 (alaw) No Rx: CANCEL
80.xxx.xxx.53 (None) 7f6c781c32ec71d 0x0 (nothing) No (d) Init: OPTIONS
80.xxx.xxx.53 (None) 408676252957@17 0x0 (nothing) No Rx: REGISTER
80.xxx.xxx.53 (None) 553108909009@17 0x0 (nothing) No Rx: REGISTER
80.xxx.xxx.53 (None) 907155120844@17 0x0 (nothing) No Rx: REGISTER
80.xxx.xxx.53 (None) 403350422913@17 0x0 (nothing) No Rx: REGISTER
80.xxx.xxx.53 (None) 103b78dd424d761 0x0 (nothing) No (d) Init: OPTIONS
80.xxx.xxx.53 (None) 459528752362@17 0x0 (nothing) No Rx: REGISTER
194.xxx.xxx.28 (None) 231713775ebf487 0x0 (nothing) No (d) Init: OPTIONS
80.xxx.xxx.53 (None) 109e75582481b09 0x0 (nothing) No (d) Init: OPTIONS
80.xxx.xxx.53 044508xxxx 028725519733@17 0x8 (alaw) No Rx: CANCEL
16 active SIP dialogs

These active SIP will remain forever, and the list will grow further as new calls are initiated or clients get new IPs.
It is then no more possible to place or receive calls from/to any attached phone. The only way to recover is a “core stop now” and restart.

I am using:

Asterisk 1.6.2.10 / .11 / 12-rc1
OS X 10.5.8
2 Clients: Sipdroid on HTC Legend, using TCP protocol. Sometimes in same NAT as asterisk, somethimes in other NAT (by the telco provider). IP changes when the mobile switches between WLAN / 3G, or when travelling in 3G network.
1 Client: SIP - analog adapter using UDP protocol. Always the same IP in same NAT as asterisk.

The asterisk is behind NAT, with required ports forwarded (5060 / RTP-range).

What I found out further: Initiate a call to a SIP client, wait until it is ringing, then disconnect it without notification to asterisk (pull out the cable…). Asterisk will then hang for several minutes!
–> From this i conclude, that there is a general problem with not reachable clients because of lost connection / changed IPs.

Let me know if you need more specific info!

Regards,

Markus

You don’t appear to be describing a crash. If you get a crash (core dump), after checking that you don’t have any old modules, and you do have a current, supported, version, you should definitely report it on the bug tracker issues.asterisk.org.

However, before reporting a bug there, you should check the registration timeouts on the phones and any limits imposed on them in Asterisk. You should also supply the output of “sip show registry” and you should obtain verbose sip set debug output (see the bug reporting guidelines on issues.asterisk.org) showing a registration cycle. In particular, you should be looking for when it is scheduling the destruction of dialogues.

Without more specific details, I can’t tell whether you are just seeing the result of setting reregistration time a lot smaller than the dialogue destruction time.

On the pulled cable issue, you need to use qualify and/or rtp timeouts, if you want Asterisk to detect lost connections. Note that it is perfectly legal to not send rtp and rtcp during silence periods, so false positives are possible with RTP timeouts. I’m not sure that a qualify failure will drop an active call.