#443 closed баг (invalid)
Неудачный вызов со стороны окончания FxO
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description
Из окончания FXO VE-01 с помощью функции "Вызывать URI" пользователь пытается вызывать абонента 4390 (который "живёт" в аппаратуре Eltex SMG3016). Однако, со слов пользователя, в момент попытки вызова "происходит разъединение".
Я попросил пользователя прислать дамп обмена сип сообщениями, однако в дампе следов вызова я не обнаружил.
Лог с платы VE-01 в момент происшествия пользователь обещал прислать позже.
10.62.113.132 - VE-01
10.62.40.24 - Eltex SMG3016
Версия прошивки VE-01 - 88.
Дамп Sip и конфиг платы прилагаю.
Attachments (2)
Change History (32)
by , 8 weeks ago
| Attachment: | FXO на 4390.txt added |
|---|
by , 8 weeks ago
| Attachment: | config-ИА_МОГЭС_12__МС04_6-24-09-2024.xml added |
|---|
comment:1 by , 8 weeks ago
| Milestone: | 2 очередь → 1 очередь |
|---|
comment:2 by , 8 weeks ago
comment:4 by , 8 weeks ago
Пользователь прислал лог
Sep 26 10:56:41 syslogd started: BusyBox v1.18.5 Sep 26 10:56:46 sip_ua[391]: fxo.cpp:272: ts 30: dialing 4390 Sep 26 10:56:46 sip_ua[391]: user_agent.cpp:3892: --> ua_dial_out() -> sip:4390@10.62.113.132... Sep 26 10:56:46 sip_ua[473]: repro.cpp:608: doSessionAccounting(): Session Created 'branch=z9hG4bK1051143813' Sep 26 10:56:46 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 9 (4xx received for Call!): cid=903, did=0, tid=8 73, rid=0, sid=0, nid=0 Sep 26 10:56:46 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Calling: Call disconnected, ts=30, flags=0000, data=903 Sep 26 10:56:46 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 26 10:56:46 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 26 10:56:46 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Drop Line: CAS event, ts=30, flags=0000, data=5 Sep 26 10:56:53 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Idle: CAS event, ts=30, flags=0000, data=13 Sep 26 10:56:54 sip_ua[391]: fxo.cpp:272: ts 30: dialing 4390 Sep 26 10:56:54 sip_ua[391]: user_agent.cpp:3892: --> ua_dial_out() -> sip:4390@10.62.113.132... Sep 26 10:56:54 sip_ua[473]: repro.cpp:608: doSessionAccounting(): Session Created 'branch=z9hG4bK1923655612' Sep 26 10:56:54 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 9 (4xx received for Call!): cid=904, did=0, tid=8 74, rid=0, sid=0, nid=0 Sep 26 10:56:54 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Calling: Call disconnected, ts=30, flags=0000, data=904 Sep 26 10:56:54 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 26 10:56:54 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 26 10:56:54 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Drop Line: CAS event, ts=30, flags=0000, data=5 Sep 26 10:57:05 syslogd exiting
comment:5 by , 8 weeks ago
p.s. дамп и лог записаны пользователем в двух разных экспериментах, со слов пользователя и в обоих экспериментах он делал одно и тоже и результат получил одинаковый.
comment:6 by , 8 weeks ago
На начальной странице проекта есть полезный текст о том, как сделать хороший баг-рипорт. Рекомендую перечитать. Если очень коротко, то хороший баг-рипорт состоит из трех основных частей: что делали, что ожидали получить, и что получили вместо ожидаемого. К сожалению, в описании тикета есть только два из трех основных компонентов - что делали и что получили в результате. Так как тип тикета установлен в "баг", я догадываюсь, что ожидали какой-то другой результат. Однако этого в описании тикета нет, поэтому я так и не понял, в чем же по твоему мнению заключается баг. Изложенного в описании тикета для такого вывода по-моему недостаточно.
Уточни, пожалуйста, что (и почему) ты ожидал получить вместо фактически полученного результата.
follow-up: 8 comment:7 by , 8 weeks ago
Уточни, пожалуйста, какое состояние имеет сигнальный канал PRI (канал 64).
follow-up: 9 comment:8 by , 8 weeks ago
Replying to alx:
Уточни, пожалуйста, какое состояние имеет сигнальный канал PRI (канал 64) на момент эксперимента.
comment:9 by , 8 weeks ago
Replying to alx:
Уточни, пожалуйста, какое состояние имел сигнальный канал PRI (канал 64) на момент эксперимента. И были ли в транке свободные разговорные каналы.
Вопрос снимается. Я не заметил сразу, что там есть маршрут "МС04->IA_SMG3016_1", направляющий вызов 4390@10.62.113.132 на 4390@10.62.113.132. Я думал, что вызов идет в PRI...
follow-up: 11 comment:10 by , 8 weeks ago
Уточни, пожалуйста, что (и почему) ты ожидал получить вместо фактически полученного результата
Я надеялся что это понятно из названия тикета, пользователь ожидал получить "удачный" вызов :)
Пользователь ожидал что FXO произведёт вызов на 4390@10.62.40.24 и далее состоится разговор.
comment:11 by , 8 weeks ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Replying to san:
Я надеялся что это понятно из названия тикета, пользователь ожидал получить "удачный" вызов :)
Если бы тикет создал пользователь, то и разговор я, наверное, строил бы по-другому, и вопросы задавал немного другие. Но автор тикета - мой коллега, высококлассный специалист в области связи и коммуникаций. Поэтому я ожидал от него более глубокого анализа ситуации и более точных формулировок.
Приведу немного утрированный пример. Элис звонит Бобу, ожидая, что разговор состоится. Но Боб в это время разговаривает с Тэдом, и поэтому Элис, вопреки своим ожиданиям, получает "Занято". Означает ли это, что аппаратуры связи Элис сломана, ведь ожидания Элис не оправдались? :) Очевидно, что нет - бывают случаи, когда разговор не может состояться по объективным причинам, не зависящим от аппаратуры Элис...
Вот поэтому я и ожидал, что если ты считаешь, что в плате VE-01 имеет место баг (тип тикета - "баг"), у тебя есть для этого более веские основания чем не оправдавшееся ожидание пользователя-домохозяйки. :)
Пользователь ожидал что FXO произведёт вызов на 4390@10.62.40.24 и далее состоится разговор.
Ну, при такой формулировке я могу только закрыть тикет как invalid. :)
Как мы видим в приложенном к тикету файле, плата VE-01 с адреса 10.62.113.132 инициирует соединение с хостом 10.62.40.24 (Eltex SMG3016), отправляя пакет SYN. Однако в ответ на него от Eltex SMG3016 вместо ожидаемого SYN+ACK приходит RESET (то есть отказ от установки соединения). Вывод - проблема находится на стороне Eltex SMG3016. Оснований предполагать наличие бага в плате VE-01 я не вижу.
follow-up: 13 comment:12 by , 8 weeks ago
Если бы тикет создал пользователь
В данном случае я просто создал тикет за пользователя,передав сюда его слова и файлы, мотороллер не мой.
отправляя пакет SYN. Однако в ответ на него от Eltex SMG3016 вместо ожидаемого SYN+ACK приходит RESET
А можешь процитировать эти сообщения из файла?
comment:13 by , 8 weeks ago
Replying to san:
В данном случае я просто создал тикет за пользователя,передав сюда его слова и файлы, мотороллер не мой.
В поле "Сообщил" (Reported by) тикета я вижу твой логин, поэтому и все прочие слова (тип тикета, описание тикета) считаю исходящими от тебя. Если ты при этом действуешь не по собственной инициативе, а по чьей-то еще просьбе - это твои личные обстоятальства. В описании тикета об этом не сказано...
отправляя пакет SYN. Однако в ответ на него от Eltex SMG3016 вместо ожидаемого SYN+ACK приходит RESET
А можешь процитировать эти сообщения из файла?
Конечно. Это два самых первых сообщения:
08:48:03.593886 IP (tos 0x0, ttl 64, id 38094, offset 0, flags [DF], proto TCP (6), length 52)
10.62.113.132.56252 > 10.62.40.24.5060: Flags [S], cksum 0x3cda (correct), seq 1524966126, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0
08:48:03.594621 IP (tos 0x0, ttl 61, id 58085, offset 0, flags [DF], proto TCP (6), length 40)
10.62.40.24.5060 > 10.62.113.132.56252: Flags [R.], cksum 0x8d56 (correct), seq 548136545, ack 1524966127, win 0, length 0
follow-up: 15 comment:14 by , 8 weeks ago
Ага, спасибо, не разглядел tcp пакеты с флагами.
Подозреваю, что проблема пользователя в том, что в этом окончании FXO настроен транспорт TCP, с которым Eltex не хочет работать. В остальных окончаниях установлен транспорт UDP.
В поле "Сообщил" (Reported by) тикета я вижу твой логин
Я посмотрел конфиг, не увидел там ничего плохого, попробовал сделать вызов на своей плате - всё работает, глянул дамп пользователя(не заметив там TCP пакетов)и не увидел там вызова.
Дальше я просто транслировал то что сообщил пользователь в тикет, оставляя формулировки, специально, чтобы случайно не переврать слова пользователя.
Насколько я вижу, ты понял описание тикета правильно и нашёл проблему. Кажется, всё хорошо)
comment:15 by , 8 weeks ago
Replying to san:
Подозреваю, что проблема пользователя в том, что в этом окончании FXO настроен транспорт TCP, с которым Eltex не хочет работать. В остальных окончаниях установлен транспорт UDP.
Вообще-то установка в настройках канального окончания транспорта UDP не гарантирует, что сообщение будет отправляться по UDP, и поэтому большого значения не имеет. UAS в любом случае должен быть готов принять сообщение по TCP (если он принимает их по UDP). Тот факт, что Eltex SMG3016 отказывается установить соединение TCP, говорит о том, что либо в нем что- неправильно настроено (например забыли открыть TCP порт 5060 в файрволе), либо либо это баг в Eltex SMG3016.
В поле "Сообщил" (Reported by) тикета я вижу твой логин
Я посмотрел конфиг, не увидел там ничего плохого, попробовал сделать вызов на своей плате - всё работает, глянул дамп пользователя(не заметив там TCP пакетов)и не увидел там вызова.
А, в описании тикета написано "следов вызова я не обнаружил" - наверное это должно было навести меня на мысль о том, что ты случайно их проглядел. Но я сам сначала проглядел маршрут SIP, перенаправляющий вызов, и поэтому думал, что вызов должен идти в PRI (поэтому и задавал вопросы о нем, и исходники PRI изучал, и вообще потратил на этот ложный след много времени). Я еще тогда подумал: "конечно не обнаружил, ведь пользователь не указал -i lo, поэтому tcpdump прицепился к внешнему интерфейсу, и сообщения-то чисто внутренние"... А когда обнаружил маршрут, то уже забыл про не найденные тобой следы... :)
Было бы лучше сразу подробнее описывать, что ожидалось. Например как-то так: ожидалось, что окончание FXO отправит INVITE на URI 4390@10.62.113.132, который в прокси маршрутом SIP будет изменен на 4390@10.62.40.24 и выйдет из платы во внешнюю сеть, но в дампе этого сообщения не обнаружено...
Насколько я вижу, ты понял описание тикета правильно и нашёл проблемму. Кажется, всё хорошо)
Так я же нашел совсем не ту проблему, которая заявлялась тобой в тикете! В тикете заявлялось, что в VE-01 обнаружен баг (то есть что VE-01 ведет себя неправильно). Я свидетельств наличия бага в VE-01 не нашел.
comment:16 by , 8 weeks ago
Было бы лучше сразу подробнее описывать, что ожидалось. Например как-то так: ожидалось, что окончание FXO отправит INVITE на URI 4390@10.62.113.132, который в прокси маршрутом SIP будет изменен на 4390@10.62.40.24 и выйдет из платы во внешнюю сеть, но в дампе этого сообщения не обнаружено...
Согласен. От пользователя мне досталась информация что "вызов не успешен". А прочитав конфиг и проведя эксперимент, я забыл уточнить, т.к. для меня это было уже очевидно)
Так я же нашел совсем не ту проблему, которая заявлялась тобой в тикете! В тикете заявлялось, что в VE-01 обнаружен баг (то есть что VE-01 ведет себя неправильно). Я свидетельств наличия бага в VE-01 не нашел.
А тут всё правильно, пользователь считал что это баг в плате VE-01(ну то есть у него всё работало когда-то, а теперь перестало и связал он это с обновлением платы), а ты аргументированно показал что вины платы VE-01 тут нет.
comment:17 by , 8 weeks ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
Переоткрою тикет, т.к. пользователь по прежнему ждёт от нас помощи, более подходящего типа чем баг я не вижу(может быть стоит какой-то отдельный тип тикетов завести где разбирать проблемы пользователей).
Пользователь установил в окончании транспорт UDP, вызов по прежнему "не проходит".
Прикладываю новый дамп Sip и лог.
Sep 27 11:35:29 syslogd started: BusyBox v1.18.5 Sep 27 11:35:35 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=5 Sep 27 11:35:38 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=13 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=23, state=Idle: CAS event, ts=23, flags=0000, data=5 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=17, state=Idle: CAS event, ts=17, flags=0000, data=11 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=19, state=Idle: CAS event, ts=19, flags=0000, data=5 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=20, state=Idle: CAS event, ts=20, flags=0000, data=13 Sep 27 11:35:39 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=9 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=17, state=Idle: CAS event, ts=17, flags=0000, data=5 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=19, state=Idle: CAS event, ts=19, flags=0000, data=13 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=20, state=Idle: CAS event, ts=20, flags=0000, data=5 Sep 27 11:35:39 sip_ua[391]: fxs.cpp:431: ---> ts=23, state=Idle: CAS event, ts=23, flags=0000, data=1 Sep 27 11:35:39 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=13 Sep 27 11:35:40 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=5 Sep 27 11:35:43 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=13 Sep 27 11:35:44 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=5 Sep 27 11:35:47 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data=13 Sep 27 11:35:47 sip_ua[391]: fxo.cpp:272: ts 30: dialing 4390 Sep 27 11:35:47 sip_ua[391]: user_agent.cpp:3892: --> ua_dial_out() -> sip:4390@10.62.113.132... Sep 27 11:35:47 sip_ua[473]: repro.cpp:608: doSessionAccounting(): Session Created 'branch=z9hG4bK1148600048' Sep 27 11:35:47 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 9 (4xx received for Call!): cid=968, did=0, tid=1051, rid=0, sid=0, nid=0 Sep 27 11:35:47 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Calling: Call disconnected, ts=30, flags=0000, data=968 Sep 27 11:35:47 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 27 11:35:47 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 27 11:35:48 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Drop Line: CAS event, ts=30, flags=0000, data=5 Sep 27 11:36:29 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 22 (Call Context is released!): cid=968, did=0, tid=0, rid=0, sid=0, nid=0 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=17, state=Idle: CAS event, ts=17, flags=0000, data=11 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=19, state=Idle: CAS event, ts=19, flags=0000, data=5 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=20, state=Idle: CAS event, ts=20, flags=0000, data=13 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=23, state=Idle: CAS event, ts=23, flags=0000, data=5 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=17, state=Idle: CAS event, ts=17, flags=0000, data=5 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=19, state=Idle: CAS event, ts=19, flags=0000, data=13 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=20, state=Idle: CAS event, ts=20, flags=0000, data=5 Sep 27 11:37:00 sip_ua[391]: fxs.cpp:431: ---> ts=23, state=Idle: CAS event, ts=23, flags=0000, data=1 Sep 27 11:37:00 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Idle: CAS event, ts=30, flags=0000, data=9 Sep 27 11:37:00 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Idle: CAS event, ts=30, flags=0000, data=5
root@comcerto:~# tcpdump -v -s1514 port 5060 and host 10.62.40.24
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
11:31:03.288218 IP (tos 0x0, ttl 61, id 24461, offset 0, flags [DF], proto UDP (17), length 386)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 358
OPTIONS sip:4920@10.62.113.132:5060 SIP/2.0
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-1-402-1718644525060-12252
Max-Forwards: 70
To: <sip:4920@10.62.40.24>
From: <sip:u402@10.62.40.24>;tag=1-402
Call-ID: 1-402-1718644525060-1-402
CSeq: 2 OPTIONS
Contact: <sip:10.62.40.24:5060>
Accept: multipart/mixed, application/SDP
Content-Length: 0
11:31:03.316170 IP (tos 0x0, ttl 61, id 24473, offset 0, flags [DF], proto UDP (17), length 353)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 325
OPTIONS sip:10.62.113.132:5060 SIP/2.0
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-40334
Max-Forwards: 70
To: <sip:10.62.113.132>
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 302508 OPTIONS
Contact: <sip:10.62.40.24:5060>
Accept: multipart/mixed, application/SDP
Content-Length: 0
11:31:03.322876 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 326)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 298
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-1-402-1718644525060-12252
To: <sip:4920@10.62.40.24>
From: <sip:u402@10.62.40.24>;tag=1-402
Call-ID: 1-402-1718644525060-1-402
CSeq: 2 OPTIONS
Server: repro 1.12.0
User-Agent: smg_pa_sip 3.20.3.5
Content-Length: 0
11:31:03.328897 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 284)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 256
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-40334
Contact: <sip:10.62.113.132:5060>
To: <sip:10.62.113.132>;tag=f6115612
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 302508 OPTIONS
Content-Length: 0
11:31:33.316379 IP (tos 0x0, ttl 61, id 41940, offset 0, flags [DF], proto UDP (17), length 353)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 325
OPTIONS sip:10.62.113.132:5060 SIP/2.0
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-41334
Max-Forwards: 70
To: <sip:10.62.113.132>
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 302509 OPTIONS
Contact: <sip:10.62.40.24:5060>
Accept: multipart/mixed, application/SDP
Content-Length: 0
11:31:33.325469 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 284)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 256
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-41334
Contact: <sip:10.62.113.132:5060>
To: <sip:10.62.113.132>;tag=5eac7e55
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 302509 OPTIONS
Content-Length: 0
comment:18 by , 8 weeks ago
Я снова не увидел вызова в дампе и попросил пользователя прислать лог и дамп одного и того же вызова.
Вот они:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
07:58:50.141341 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 582)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 554
OPTIONS sip:4998@10.62.40.24 SIP/2.0
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d11cac4ece30 306e;rport
Via: SIP/2.0/UDP 10.62.4.17:5060;branch=z9hG4bK7e7da0b8;rport=5060
Max-Forwards: 69
Contact: <sip:10.62.4.17;transport=UDP>
To: <sip:4998@10.62.113.132>
From: "pbx"<sip:4998@10.62.4.17>;tag=as5bfac73
Call-ID: 6842a0a649d38b9277d3811e4cc16e1a@10.62.4.17
CSeq: 102 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Date: Mon, 30 Sep 2024 08:08:50 GMT
User-Agent: VINTEO 2.0.0
Content-Length: 0
07:58:50.144805 IP (tos 0x0, ttl 61, id 35610, offset 0, flags [DF], proto UDP (17 ), length 689)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 661
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d11cac4ece30 306e;received=10.62.113.132;rport=5060
Via: SIP/2.0/UDP 10.62.4.17:5060;branch=z9hG4bK7e7da0b8;rport=5060
From: "pbx"<sip:4998@10.62.4.17>;tag=as5bfac73
To: <sip:4998@10.62.113.132>
Call-ID: 6842a0a649d38b9277d3811e4cc16e1a@10.62.4.17
CSeq: 102 OPTIONS
Supported: 100rel, replaces
Allow: INVITE, ACK, BYE, CANCEL, PRACK, REGISTER, INFO, REFER, NOTIFY, OPT IONS, UPDATE
Content-Type: application/sdp
User-Agent: smg_pa_sip 3.22.3.8
Content-Length: 108
v=0
o=- 1 1 IN IP4 10.62.40.24
s=SMG SIP session
c=IN IP4 10.62.40.24
t=0 0
m=audio 0 RTP/AVP 8 0 101
07:58:53.958811 IP (tos 0x0, ttl 61, id 38622, offset 0, flags [DF], proto UDP (17 ), length 354)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 326
OPTIONS sip:10.62.113.132:5060 SIP/2.0
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-985304
Max-Forwards: 70
To: <sip:10.62.113.132>
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 310727 OPTIONS
Contact: <sip:10.62.40.24:5060>
Accept: multipart/mixed, application/SDP
Content-Length: 0
07:58:53.967239 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 285)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 257
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-985304
Contact: <sip:10.62.113.132:5060>
To: <sip:10.62.113.132>;tag=a5bf4470
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 310727 OPTIONS
Content-Length: 0
07:59:00.054679 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 1448)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 1420
INVITE sip:4390@10.62.40.24 SIP/2.0
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---050687364ac0 fa1e;rport
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1880198138
Max-Forwards: 69
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
Contact: <sip:7031@127.0.0.1:6060>
To: <sip:4390@10.62.113.132>
From: <sip:7031@10.62.113.132>;tag=145387868
Call-ID: 1814179202
CSeq: 20 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRA CK, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, timer, 100rel
User-Agent: eXosip/5.3.0
Allow-Events: conference
X-Endpoint-Type: FXO
Content-Length: 750
v=0
o=gateway 0 24 IN IP4 10.62.113.132
s=conversation
c=IN IP4 10.62.113.132
t=0 0
m=audio 10060 RTP/SAVP 8 0 4 18 101 13 98
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ybpzB1P4vdeaV4vaLyKvFTZCrh0mymyX d9ee0XXa
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:pcGgWQrU2VHqxD3aN5EsmMDz9P2lkBz0 rnUUidAO
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=rtpmap:98 PCMA/8000
a=gpmd:98 vbd=yes
m=audio 10060 RTP/AVP 8 0 4 18 101 13 98
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=rtpmap:98 PCMA/8000
a=gpmd:98 vbd=yes
07:59:00.058869 IP (tos 0x0, ttl 61, id 39119, offset 0, flags [DF], proto UDP (17 ), length 456)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 428
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---050687364ac0 fa1e;received=10.62.113.132;rport=5060
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1880198138
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
From: <sip:7031@10.62.113.132>;tag=145387868
To: <sip:4390@10.62.113.132>
Call-ID: 1814179202
CSeq: 20 INVITE
User-Agent: smg_pa_sip 3.22.3.8
Content-Length: 0
07:59:00.062985 IP (tos 0x0, ttl 61, id 39121, offset 0, flags [DF], proto UDP (17 ), length 614)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 586
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---050687364ac0 fa1e;received=10.62.113.132;rport=5060
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1880198138
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
From: <sip:7031@10.62.113.132>;tag=145387868
To: "4390" <sip:4390@10.62.113.132>;tag=i331p0D1058D0t3r86441
Call-ID: 1814179202
CSeq: 20 INVITE
X-UniqueTag: 1100014b66fa5a44adb22d6be97bd001
Reason: Q.850;cause=65;text="Bearer capability not implemented"
User-Agent: smg_pa_sip 3.22.3.8
Content-Length: 0
07:59:00.075218 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 331)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 303
ACK sip:4390@10.62.40.24 SIP/2.0
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---050687364ac0 fa1e;rport
Max-Forwards: 70
To: "4390" <sip:4390@10.62.113.132>;tag=i331p0D1058D0t3r86441
From: <sip:7031@10.62.113.132>;tag=145387868
Call-ID: 1814179202
CSeq: 20 ACK
Content-Length: 0
07:59:16.203932 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 1449)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 1421
INVITE sip:4390@10.62.40.24 SIP/2.0
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d890f8787b42 8e33;rport
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK2026117162
Max-Forwards: 69
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
Contact: <sip:7031@127.0.0.1:6060>
To: <sip:4390@10.62.113.132>
From: <sip:7031@10.62.113.132>;tag=1477643992
Call-ID: 1831317458
CSeq: 20 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRA CK, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, timer, 100rel
User-Agent: eXosip/5.3.0
Allow-Events: conference
X-Endpoint-Type: FXO
Content-Length: 750
v=0
o=gateway 0 25 IN IP4 10.62.113.132
s=conversation
c=IN IP4 10.62.113.132
t=0 0
m=audio 10060 RTP/SAVP 8 0 4 18 101 13 98
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:so6+49CK8XaP/h0rPxX9Gh0R8YKAS2RD dNvvA1DB
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:kPZBroqF6J1KZOkpJR6xvG+YrHbc9EpN 4ZHeuTeq
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=rtpmap:98 PCMA/8000
a=gpmd:98 vbd=yes
m=audio 10060 RTP/AVP 8 0 4 18 101 13 98
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=rtpmap:98 PCMA/8000
a=gpmd:98 vbd=yes
07:59:16.207996 IP (tos 0x0, ttl 61, id 43544, offset 0, flags [DF], proto UDP (17 ), length 457)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 429
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d890f8787b42 8e33;received=10.62.113.132;rport=5060
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK2026117162
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
From: <sip:7031@10.62.113.132>;tag=1477643992
To: <sip:4390@10.62.113.132>
Call-ID: 1831317458
CSeq: 20 INVITE
User-Agent: smg_pa_sip 3.22.3.8
Content-Length: 0
07:59:16.210983 IP (tos 0x0, ttl 61, id 43546, offset 0, flags [DF], proto UDP (17 ), length 616)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 588
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d890f8787b42 8e33;received=10.62.113.132;rport=5060
Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK2026117162
Record-Route: <sip:10.62.113.132:5060;transport=udp;lr>
From: <sip:7031@10.62.113.132>;tag=1477643992
To: "4390" <sip:4390@10.62.113.132>;tag=i242p0D1147D0t3r235092
Call-ID: 1831317458
CSeq: 20 INVITE
X-UniqueTag: 110000f266fa5a541704ebd2e7432001
Reason: Q.850;cause=65;text="Bearer capability not implemented"
User-Agent: smg_pa_sip 3.22.3.8
Content-Length: 0
07:59:16.224361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 333)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 305
ACK sip:4390@10.62.40.24 SIP/2.0
Via: SIP/2.0/UDP 10.62.113.132:5060;branch=z9hG4bK-524287-1---d890f8787b42 8e33;rport
Max-Forwards: 70
To: "4390" <sip:4390@10.62.113.132>;tag=i242p0D1147D0t3r235092
From: <sip:7031@10.62.113.132>;tag=1477643992
Call-ID: 1831317458
CSeq: 20 ACK
Content-Length: 0
07:59:23.959071 IP (tos 0x0, ttl 61, id 44078, offset 0, flags [DF], proto UDP (17 ), length 354)
10.62.40.24.5060 > 10.62.113.132.5060: SIP, length: 326
OPTIONS sip:10.62.113.132:5060 SIP/2.0
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-986196
Max-Forwards: 70
To: <sip:10.62.113.132>
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 310728 OPTIONS
Contact: <sip:10.62.40.24:5060>
Accept: multipart/mixed, application/SDP
Content-Length: 0
07:59:23.968454 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), l ength 285)
10.62.113.132.5060 > 10.62.40.24.5060: SIP, length: 257
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.62.40.24:5060;branch=z9hG4bK-u-3-3-777-986196
Contact: <sip:10.62.113.132:5060>
To: <sip:10.62.113.132>;tag=c35f1e4e
From: <sip:t3@10.62.40.24>;tag=3-3
Call-ID: 3-3-777-3-3
CSeq: 310728 OPTIONS
Content-Length: 0
14 packets captured
14 packets received by filter
0 packets dropped by kernel
Sep 30 07:58:39 syslogd started: BusyBox v1.18.5 Sep 30 07:58:52 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 5 Sep 30 07:58:55 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 13 Sep 30 07:58:57 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 5 Sep 30 07:58:59 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 13 Sep 30 07:59:00 sip_ua[391]: fxo.cpp:272: ts 30: dialing 4390 Sep 30 07:59:00 sip_ua[391]: user_agent.cpp:3892: --> ua_dial_out() -> sip:4390@10.62.113.132... Sep 30 07:59:00 sip_ua[444]: repro.cpp:608: doSessionAccounting(): Session Created 'branch=z9hG4bK188019 8138' Sep 30 07:59:00 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 9 (4xx received for Call!) : cid=71, did=0, tid=83, rid=0, sid=0, nid=0 Sep 30 07:59:00 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Calling: Call disconnected, ts=30, flags=000 0, data=71 Sep 30 07:59:00 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 30 07:59:00 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 30 07:59:00 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Drop Line: CAS event, ts=30, flags=0000, dat a=5 Sep 30 07:59:06 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Idle: CAS event, ts=30, flags=0000, data=13 Sep 30 07:59:08 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 5 Sep 30 07:59:11 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 13 Sep 30 07:59:13 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 5 Sep 30 07:59:16 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Ringing: CAS event, ts=30, flags=0000, data= 13 Sep 30 07:59:16 sip_ua[391]: fxo.cpp:272: ts 30: dialing 4390 Sep 30 07:59:16 sip_ua[391]: user_agent.cpp:3892: --> ua_dial_out() -> sip:4390@10.62.113.132... Sep 30 07:59:16 sip_ua[444]: repro.cpp:608: doSessionAccounting(): Session Created 'branch=z9hG4bK202611 7162' Sep 30 07:59:16 sip_ua[416]: user_agent.cpp:2134: ---> transport 0: SIP event 9 (4xx received for Call!) : cid=72, did=0, tid=84, rid=0, sid=0, nid=0 Sep 30 07:59:16 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Calling: Call disconnected, ts=30, flags=000 0, data=72 Sep 30 07:59:16 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 30 07:59:16 sip_ua[391]: comcerto.cpp:6995: ts 30: stopping RTP stream Sep 30 07:59:16 sip_ua[391]: fxo.cpp:363: ---> ts=30, state=Drop Line: CAS event, ts=30, flags=0000, dat a=5 Sep 30 07:59:28 syslogd exiting
comment:19 by , 6 weeks ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
Из последнего дампа видно, что завершение вызова происходит по инициативе Eltex - сообщением 488 Not Acceptable Here.
alx прокомментировал это сообщение так:
Код 488 означает, что UA не нашел в предложении ни одного поддерживаемого им медиапотока/кодека.
Также в ответе есть поле Reason: "Bearer capability not implemented", что alx прокомментировал так:
"Bearer capability not implemented" бывает в TDM-сигнализациях (ISDN). Могу предположить, что Eltex SMG3016 направил вызов другому коммутатору, в ответ получил ошибку "Bearer capability not implemented", что и транслировал в сторону вызывающего в поле Reason.
follow-up: 21 comment:20 by , 6 weeks ago
Пользователь методом сравнения конфигураций окончаний, выяснил что Элтекс принимает инвайт, при настройке медиа в окончании VE-01 = RTP, а при настройке медиа = RTP/RTCP RTP/SRTP, Элтекс говорит 488.
Мне это кажется странным ведь значение RTP/RTCP RTP/SRTP говорит о том что плата VE-01 поддерживает оба варианта, т.е. Элтекс может выбрать любой из двух вариантов протокола передачи медиа. Т.е. если Элтекс умеет работать только в RTP, и если плата VE предлагает оба варианта, то он может также работать с платой по RTP.
Или я что-то неправильно понимаю?
p.s. исправил опечатку
comment:21 by , 6 weeks ago
Replying to san:
Пользовтель методом сравнения конфигураций окончаний, выяснил что Элтекс принимает инвайт, при настройке медиа в окончании VE-01 = RTP, а при настройке медиа = RTP/RTCP, Элтекс говорит 488.
Это удивительно, так как включение/выключение RTCP никак не отражается в передаваемом шлюзом INVITE.
Мне это кажется странным ведь значение RTP/RTCP говорит о том что плата VE-01 поддерживает оба варианта, т.е. Элтекс может выбрать любой из двух вариантов протокола передачи медиа.
Т.е. если Элтекс умеет работать только в RTP, и если плата VE предлагает оба варианта, то он может также работать с платой по RTP.
Или я что-то неправильно понимаю?
Я вообще не понял, о каких вариантах ты говоришь. Если не включать RTCP, то шлюз просто не будет RTCP пакеты передавать, и все (и, вероятно, будет игнорировать принимаемые от удаленной стороны, но я не уверен). Если RTCP включен, а удаленная сторона его не поддерживает, то передаваемые шлюзом пакеты RTCP будут просто игнорироваться удаленной стороной (вероятно, от удаленной стороны будут приходить ICMP port unreachable). На работу RTP включение/выключение RTCP никак влиять не должно.
follow-up: 23 comment:22 by , 6 weeks ago
Я опечатался в своём сообщении, речь шла о настройке RTP/SRTP
comment:23 by , 6 weeks ago
Replying to san:
Я опечатался в своём сообщении, речь шла о настройке RTP/SRTP
Когда установлено RTP/SRTP, шлюз при отправке INVITE предлагает и RTP, и SRTP.
follow-ups: 25 29 comment:24 by , 6 weeks ago
Ну т.е. для Элтекса так больше вариантов чем просто RTP и мне кажется странным что при предложении RTP он принимает вызов, а при предложении обоих протоколов говорит 488. Видимо это какой-то баг у них, как ещё это объяснить?
У пользователя произошла такая ситуация.
- У него была какая-то старая прошивка VE-01 - он создавал новое окончание(по умолчанию оно создавалось с метдиа=RTP) и оно успешно отправляло вызовы в Элтекс.
- Он обновил прошивку VE-01 до актуальной
- Теперь при создании нового окончания по умолчанию медиа=RTP/SRTP и с такой настройкой Элтекс не принимает вызов от VE-01
- В итоге, пользователь, проделывая на новой прошивке VE-01 те-же действия, что и раньше, в том же окружении, получал другой(неудачный) результат.
Исходя из п4, пользователь предположил что проблема в плате VE-01.
Но фактически, выходит, что плата VE-01, при создания нового окончания по дефолту предлагает условия не хуже, чем были в старой прошивке.
comment:25 by , 6 weeks ago
Replying to san:
Ну т.е. для Элтекса так больше вариантов чем просто RTP
Да, в режиме "только RTP" SRTP не предлагается.
и мне кажется странным что при предложении RTP он принимает вызов, а при предложении обоих протоколов говорит 488. Видимо это какой-то баг у них, как ещё это объяснить?
Не знаю. Об этом лучше спрашивать пользователей или разработчиков Eltex SMG3016.
А в режиме "только SRTP" принимает?
У пользователя произошла такая ситуация.
- У него была какая-то старая прошивка VE-01 - он создавал новое окончание(по умолчанию оно создавалось с метдиа=RTP) и оно успешно отправляло вызовы в Элтекс.
- Он обновил прошивку VE-01 до актуальной
- Теперь при создании нового окончания по умолчанию медиа=RTP/SRTP и с такой настройкой Элтекс не принимает вызов от VE-01
- В итоге пользователь проделывая на новой прошивке VE-01 те-же действия, что и раньше, в томже окружении получал другой(неудачный) результат.
Значение по умолчанию режима медиапотока в VE-01 не менялось. Оно было и есть "только RTP". Поэтому описанная тобой ситуация невозможна - от смены прошивки VE-01 работа канального окончания не меняется. Думаю, ты что-то путаешь.
Но фактически, выходит, что плата VE-01, при создания нового окончания по дефолту предлагает условия не хуже, чем были в старой прошивке.
Нет. Плата VE-01 по дефолту предлагает только RTP - ровно то, что было с "старой" прошивке. Иначе бы нарушилась совместимость.
comment:26 by , 6 weeks ago
Посмотрел приложенный конфиг - у канального окончания FXO канал 31 (id=30) параметр "codecs" имеет значение "8 0 4 18 101 13 98". Здесь нет числа 992, следовательно, нет режима RTP/SRTP. Медиапоток SRTP при данной конфигурации платой VE-01 предлагаться не должен. Думаю, что пользователь вводит нас в заблуждение.
follow-up: 28 comment:27 by , 6 weeks ago
Значение по умолчанию режима медиапотока в VE-01 не менялось. Оно было и есть "только RTP". Поэтому описанная тобой ситуация невозможна - от смены прошивки VE-01 работа канального окончания не меняется. Думаю, ты что-то путаешь.
Нет, видимо ты не верно понял про "по умолчанию", я имел в виду, что пользователь создаёт НОВОЕ окончание, не трогая настройки вкладки медиа. И при этом в новой прошивке создаётся окончание с медиа = RTP/SRTP, а в старой RTP.
Думаю, что пользователь вводит нас в заблуждение.
Это любимое дело пользователей.
Но в последнем дампе в Инвайте есть две строчки, насколько я понимаю, это говорит о том, что выбран вариант RTP/SRTP
m=audio 10060 RTP/SAVP 8 0 4 18 101 13 98 m=audio 10060 RTP/AVP 8 0 4 18 101 13 98
Изначально вызов не работал т.к. Элтекс не хотел принимать TCP(конфиг от этого случая), видимо после пользователь не только изменил транспорт на UDP, но и другие настройки.
comment:28 by , 6 weeks ago
Replying to san:
Значение по умолчанию режима медиапотока в VE-01 не менялось. Оно было и есть "только RTP". Поэтому описанная тобой ситуация невозможна - от смены прошивки VE-01 работа канального окончания не меняется. Думаю, ты что-то путаешь.
Нет, видимо ты не верно понял про "по умолчанию", я имел в виду, что пользователь создаёт НОВОЕ окончание, не трогая настройки вкладки медиа. И при этом в новой прошивке создаётся окончание с медиа = RTP/SRTP, а в старой RTP.
По-моему это ты что-то не понимаешь. Режим медиапотока определяется конфигурацией канального окончания, а именно, параметром "codecs". Режим "RTP/SRTP" будет только если в параметре "codecs" есть число 992. Если нет - будет режим "только RTP". От прошивки VE-01 это не зависит (если прошивка вообще не поддерживает SRTP, то SRTP, естественно, предлагаться не будет ни при какой конфигурации). Плата сама не принимает решения, предлагать SRTP или нет. Плата строго следует записанной в нее конфигурации.
Но в последнем дампе в Инвайте есть две строчки, насколько я понимаю, это говорит о том, что выбран вариант RTP/SRTP
m=audio 10060 RTP/SAVP 8 0 4 18 101 13 98 m=audio 10060 RTP/AVP 8 0 4 18 101 13 98
Совершенно верно.
Изначально вызов не работал т.к. Элтекс не хотел принимать TCP(конфиг от этого случая), видимо после пользователь не только изменил транспорт на UDP, но и другие настройки.
Вероятно.
comment:29 by , 6 weeks ago
А, кажется я понял, о чем ты говорил.
Replying to san:
У пользователя произошла такая ситуация.
- У него была какая-то старая прошивка VE-01 - он создавал новое окончание(по умолчанию оно создавалось с метдиа=RTP) и оно успешно отправляло вызовы в Элтекс.
- Он обновил прошивку VE-01 до актуальной
- Теперь при создании нового окончания по умолчанию медиа=RTP/SRTP и с такой настройкой Элтекс не принимает вызов от VE-01
- В итоге, пользователь, проделывая на новой прошивке VE-01 те-же действия, что и раньше, в том же окружении, получал другой(неудачный) результат.
Уверяю тебя, что без п. 2 (то есть без обновления прошивки) было бы то же самое, так как от прошивки платы VE-01 это не зависит (если только прошивка VE-01 не была насколько древней, что вообще не поддерживала SRTP, но такое трудно себе представить).
comment:30 by , 6 weeks ago
что без п. 2 (то есть без обновления прошивки) было бы то же самое
А ну да, вместе с обновлением VE-01 он обновил и ПО sw, не знаю от кого в данном случае зависит выбор того что будет в медиа при создании нового окончания.
Вот цитата пользователя:
Я сейчас посмотрел на более старой версии Версия sw: 1.0-r2294 там по умолчанию (только RTP) а в новой RTP/SRTP
Конфиг платы пользователь прислал внутри конфига блока - плата VE-01 в слоте 3.