Opened 8 years ago
Last modified 7 years ago
#307 closed улучшение
Возобновление регистрации — at Version 18
| Reported by: | san | Owned by: | dimag |
|---|---|---|---|
| Priority: | critical | Milestone: | 2 очередь |
| Component: | ПО MC04-Dispatcher. Пульт диспетчера/техника | Keywords: | network disconnection |
| Cc: | alx |
Description (last modified by )
При пропадании связи с сервером мой пользователь потерял регистрацию, при возобновлении связи регистрацию он получил только после срабатывания таймаута перерегистрации.
Нужно чтобы пользователь получал регистрацию сразу, как только возможно.
Добавлено alx:
Период перерегистрации (то есть период, с которым UAC обновляет регистрацию, посылая сообщения REGISTER) должен быть меньше периода регистрации (величины, указанной в заголовке Expires). Разница между ними должна быть достаточной для того чтобы произвести обновление регистрации даже в плохих условиях связи. Разумной величиной мне видится что-то типа 30 секунд.
Change History (18)
comment:1 by , 8 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 8 years ago
| Keywords: | network disconnection added |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:3 by , 8 years ago
Дима, объясните, пожалуйста, суть данного бага (в комментарии к коммиту написано "ошибка 307", что, лично для меня, никак суть сделанного не поясняет).
Саша, я не понял описание проблемы.
Если, как ты пишешь, при потерянной связи пользователь потерял регистрацию, значит период регистрации истек, и, следовательно, таймер перерегистрации истек тем более, так как он заведомо меньше периода регистрации. Следовательно, на момент восстановления связи таймер перерегистрации уже истек.
С другой стороны, регистрация не может протухнуть до истечения таймера перерегистрации, так как ее период заведомо больше. В таком случае я не вижу никакого смысла обновлять регистрацию до истечения таймера перерегистрации независимо от того, было пропадание связи или нет...
comment:4 by , 8 years ago
| Cc: | added |
|---|
follow-ups: 6 10 comment:5 by , 8 years ago
Попробую уточнить:
- Я выдернул сеть у пользователя на время превышающее период регистрации
- регистрация протухла
- вернул сеть - програма детектировала возобновления связи с сервером, но регистрацию не получила.
- Я показал проблему Диме и Дима сказал что регистрация будет примерно через период регистрации, и действительно, через некоторое время регистрация появилась.(отсюда и формулировка тикета)
comment:6 by , 8 years ago
Replying to san:
- Я показал проблему Диме и Дима сказал что регистрация будет примерно через период регистрации,
Дима, как так получилось, что период перерегистрации истек позднее самой регистрации? Таким макаром ведь регистрация будет протухать даже без нарушения связи...
comment:7 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Так как ответа не последовало, считаю описанное явление багом и переоткрываю тикет.
comment:8 by , 8 years ago
Дима, опиши пожалуйста как исправил ситуацию и по какому алгоритму запускается таймер перерегистрации и на какое время
follow-ups: 11 13 comment:9 by , 8 years ago
В r342 и поздних при восстановление соединения происходит принудительная перергистрация SIP-клиента.
comment:10 by , 8 years ago
Replying to san:
Попробую уточнить:
- Я выдернул сеть у пользователя на время превышающее период регистрации
- регистрация протухла
- вернул сеть - програма детектировала возобновления связи с сервером, но регистрацию не получила.
- Я показал проблему Диме и Дима сказал что регистрация будет примерно через период регистрации, и действительно, через некоторое время регистрация появилась.(отсюда и формулировка тикета)
Вы очевидно использовали более старую версию чем r342.
comment:11 by , 8 years ago
comment:12 by , 8 years ago
SIP клиенту можно послать запрос на немедленную отправку серверу сообщения об обновления регистрации - это принудительная перерегистрация.
По истечению определенного промежутка времени, SIP-клиент автоматически посылает сообщение об обновление регистрации - это непринудительная регистрация.
comment:13 by , 8 years ago
Replying to dimag:
В r342 и поздних при восстановление соединения происходит принудительная перергистрация SIP-клиента.
Для чего это делается?
Смотрите comment:3. Если таймер перерегистрации еще не истек, то и на сервере регистрация еще не должна протухнуть, поэтому и возобновлять ее "принудительно" не вижу смысла. Если же таймер перерегистрации может истечь позже чем таймер регистрации, то у нас и без потери соединения с сетью будет теряться регистрация. Поэтому я и настаиваю на том чтобы разобраться в этом вопросе.
comment:14 by , 8 years ago
Дима, пожалуйста, если хотите ответить на мой (или чей-либо еще) комментарий, добавляйте свой комментарий, а не исправляйте чужой. Во-первых, этим Вы вводите людей в заблуждение относительно моего мнения (я слов "При внезапном разрыве и соединения и его восстановлении, если пройдёт достаточно времени..." не писал), во-вторых, после вашего исправления получилось, что я сам себе отвечаю на свой вопрос, что выглядит странно, в-третьих, я не вижу, что Вы мне что-то ответили (так как новых комментариев не появилось).
При внезапном разрыве и соединения и его восстановлении, если пройдёт достаточно времени, FreeSwitch переводит пользователя программы в состояние нет соединения,
А без внезапного разрыва и соединения этого разве не происходит?
follow-up: 16 comment:15 by , 8 years ago
Данный тикет появился по следующей причине. Если программу отключить от сети минут 5, на время превышающее период перерегистрации, то при подключение программы к сети, программа будет незарегистрированной на сервере, пока не будет сгенерированно сообщение о перерегистрации и программа не получит сообщение sophia::register. Для того, чтобы этого не происходило, я принудительно перерегистрирую программу после восстановления соединения.
Вот в чём суть вопроса.
comment:16 by , 8 years ago
Replying to dimag:
пока не будет сгенерированно сообщение о перерегистрации и программа не получит сообщение sophia::register.
Правильно ли я понял, что написанное с ваших слов в п. 4 этого комментария, а также в описании тикета, неверно - к моменту, когда пользователь потерял регистрацию, таймер перерегистрации уже истек? Каков период таймера перерегистрации по отношению к периоду регистрации - он больше, он меньше, они равны...?
follow-up: 18 comment:17 by , 8 years ago
Таймер регистрации и период регистрации это одно и тоже - период регистрации.
С периодичностью заданной этим периодом посылаются следующие сообщения и конце послыается сообщение sophia::resister, как на логе внизу.
12:24:49.277 pjsua_core.c .TX 474 bytes Request msg REGISTER/cseq=38759 (tdta00248BF0) to UDP 192.168.0.63:5060:
REGISTER sip:192.168.0.63 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.81:50241;rport;branch=z9hG4bKPje1a3016c8f6c4ed283aae7584c218c8e
Max-Forwards: 70
From: <sip:2@192.168.0.63>;tag=6a76611d4a4e4840aa4efcfb409e27b4
To: <sip:2@192.168.0.63>
Call-ID: 035ee579a24144ffbb6544c093386dde
CSeq: 38759 REGISTER
Contact: <sip:2@192.168.0.81:50241;ob>
Expires: 20
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
--end msg--
12:24:49.277 pjsua_core.c .RX 662 bytes Response msg 401/REGISTER/cseq=38759 (rdata04C830AC) from UDP 192.168.0.63:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.81:50241;rport=50241;branch=z9hG4bKPje1a3016c8f6c4ed283aae7584c218c8e
From: <sip:2@192.168.0.63>;tag=6a76611d4a4e4840aa4efcfb409e27b4
To: <sip:2@192.168.0.63>;tag=j0862jZcgZ2Zr
Call-ID: 035ee579a24144ffbb6544c093386dde
CSeq: 38759 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.6.10+git~20160824T215404Z~726448d962~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
WWW-Authenticate: Digest realm="192.168.0.63", nonce="5d079fb1-d2dd-41f7-a658-5d3314e8cfd7", algorithm=MD5, qop="auth"
Content-Length: 0
--end msg--
12:24:49.277 pjsua_core.c ....TX 728 bytes Request msg REGISTER/cseq=38760 (tdta00248BF0) to UDP 192.168.0.63:5060:
REGISTER sip:192.168.0.63 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.81:50241;rport;branch=z9hG4bKPj151851c1d0634d4e9c3e6a3490bf777e
Max-Forwards: 70
From: <sip:2@192.168.0.63>;tag=6a76611d4a4e4840aa4efcfb409e27b4
To: <sip:2@192.168.0.63>
Call-ID: 035ee579a24144ffbb6544c093386dde
CSeq: 38760 REGISTER
Contact: <sip:2@192.168.0.81:50241;ob>
Expires: 20
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Authorization: Digest username="2", realm="192.168.0.63", nonce="5d079fb1-d2dd-41f7-a658-5d3314e8cfd7", uri="sip:192.168.0.63", resp
onse="b191a2746d7c1ee6366f3174fda846d0", algorithm=MD5, cnonce="9b14ebb1c26e4a16a726e7d4637026da", qop=auth, nc=00000001
Content-Length: 0
--end msg--
12:24:49.277 pjsua_core.c .RX 620 bytes Response msg 200/REGISTER/cseq=38760 (rdata04C830AC) from UDP 192.168.0.63:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.81:50241;rport=50241;branch=z9hG4bKPj151851c1d0634d4e9c3e6a3490bf777e
From: <sip:2@192.168.0.63>;tag=6a76611d4a4e4840aa4efcfb409e27b4
To: <sip:2@192.168.0.63>;tag=K91Z4DggD8rjm
Call-ID: 035ee579a24144ffbb6544c093386dde
CSeq: 38760 REGISTER
Contact: <sip:2@192.168.0.81:50241;ob>;expires=20
Date: Fri, 16 Sep 2016 07:24:46 GMT
User-Agent: FreeSWITCH-mod_sofia/1.6.10+git~20160824T215404Z~726448d962~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Length: 0
--end msg--
12:24:49.277 pjsua_acc.c ....SIP outbound status for acc 0 is not active
12:24:49.287 pjsua_acc.c ....sip:2@192.168.0.63: registration success, status=200 (OK), will re-register in 20 seconds
12:24:49.287 pjsua_acc.c ....Keep-alive timer started for acc 0, destination:192.168.0.63:5060, interval:15s
CUSTOM - sofia::register - 2
comment:18 by , 8 years ago
| Description: | modified (diff) |
|---|
Replying to dimag:
Таймер регистрации и период регистрации это одно и тоже - период регистрации.
С периодичностью заданной этим периодом посылаются следующие сообщения
Это неправильное поведение. Сообщение REGISTER должно посылаться не с периодом регистрации, а с меньшим, чем период регистрации, периодом (в комментариях выше я называл его периодом перерегистрации), иначе могут возникать пропуски входящих вызовов из-за того, что UAC не успел обновить регистрацию до истечения ее периода. Добавил это требование в описание тикета.
r342