sips
-
Posts
148 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by sips
-
-
56 minutes ago, Barin86 said:
if I put a Fritzbox as client and I configure the voip with the fritzbox itself, all works perfectly
Please, repeat the steps 1-6 described above when your PC accesses the Internet via your FRITZ!Box router.
And, when you change to your Keenetic Hero DSL back, collect the diagnostic info:1) open the web configurator of your Keenetic, go to Management>Diagnostics>Debug, click “Restart system in debug mode”;
2) wait for 1 minute;
3) click “Stop debugging”;
4) download the file self-test_xxxxx.txt and attach it here with your next post.
-
21 hours ago, Barin86 said:
there is only a 503 error (No answer record in the DNS response)
Keenetic Phone Station application (hereafter, the app) performs DNS SRV resolution for the SIP proxy domain name, which is “voip.it.isp.sky” in our case. If DNS SRV resolution returns an error, the app tries to perform DNS A resolution for the SIP proxy domain name. If DNS A resolution returns a error as well, we'll see the error 503 like shown on your screenshot. Therefore, in your case we have a DNS resolution issue, the app can’t get the IP address of the SIP proxy.
In order to verify DNS resolution, please execute the following commands in the command prompt on your PC connected to the internet via your Keenetic Hero DSL to which USB port the Keenetic Linear is plugged. I assume that you have a PC powered by MS Windows OS. In case your PC is powered with OS Linux, the command specified below will be the same, but the outputs will look slightly different from those given in the examples.1. Check the ability to get DNS A records to resolve domain names into IPv4 addresses:
Command: nslookup -type=A google.com
Example:
C:\Users\sips>nslookup -type=A google.com
Address: 192.168.1.1
Non-authoritative answer:
google.com
Addresses: 108.177.14.138
108.177.14.100
108.177.14.102
108.177.14.101
108.177.14.113
108.177.14.139
2. Check the ability to get DNS AAAA records to resolve names into IPv6 addresses:
Command: nslookup -type=A google.com
Example:
C:\Users\sips>nslookup -type=AAAA google.com
Address: 192.168.1.1
Non-authoritative answer:
google.com
Addresses: 2a00:1450:4010:c0f::8a
2a00:1450:4010:c0f::65
2a00:1450:4010:c0f::66
2a00:1450:4010:c0f::71
3. In case of succes on the previous steps, check the DNS SRV record for the domain name “voip.it.isp.sky”
Command: nslookup -type=SRV _sip._udp.voip.it.isp.skyRight now, I have no abilities to get DNS SRV record for the “voip.it.isp.sky”, this is why below there is an
example with another domain name:
C:\Users\sips>nslookup -type=SRV _sip._udp.sip.1und1.deAddress: 192.168.11.1
Non-authoritative answer:
_sip._udp.sip.1und1.de SRV service location:
priority = 0
weight = 0
port = 5060
svr hostname = 1und1-1.sip.1und1.de
_sip._udp.sip.1und1.de SRV service location:
priority = 1
weight = 0
port = 5060
svr hostname = 1und1-2.sip.1und1.de
In the output above, you can see two host names: “1und1-1.sip.1und1.de” and “1und1-2.sip.1und1.de”. In case you successfully get DNS SRV for “voip.it.isp.sky”, the hostnames will be different.
4. If you successfully get DNS SRV on the previous step, check DNS A record for the hostname with the priority 0 from the output you got on the previous step.
Command: nslookup -type=A hostname
In the above command, replace “hostname” with the hostname from the output you got on step 3.
Example:C:\Users\sips>nslookup -type=A 1und1-2.sip.1und1.de
Address: 192.168.1.1
Non-authoritative answer:
1und1-2.sip.1und1.de
Addresses: 212.227.124.129
212.227.124.130
In the above output we see two IPv4 addresses to which the hostname resolves.
5. If you successfully get DNS SRV earlier, check DNS AAAA. Execute the command “nslookup -type=AAAA hostname”, replace “hostname” with the hostname from the output you got on step 3.
Example:C:\Users\sips>nslookup -type=AAAA 1und1-2.sip.1und1.de
Address: 192.168.1.1
Non-authoritative answer:
1und1-2.sip.1und1.de
Addresses: 2001:8d8:104:100:212:227:124:129
2001:8d8:104:100:212:227:124:130
In the above output, we see two IPv6 addresses to which the hostname resolves.
6) If you didn’t get the DNS SRV record for the domain name “voip.it.isp.sky” on step 3, try to get DNS A and AAAA records.
Commands:
nslookup -type=A voip.it.isp.sky
nslookup -type=AAAA voip.it.isp.sky
After performing the above steps 1-6, share the output of the commands, please.
-
1
-
-
On 10/22/2022 at 9:42 PM, Paprikar said:
The simplest and rather correct solution would be to simply move Steam (and other similar services) traffic somewhere in the "File transferring" group set.
In the latest version of the traffic classification engine, the digital distribution platforms for games such as BattleNet, EA Origin, Epic Games, Gearbox Shift, GOG, Steam and Ubisoft Connect were moved to the "App-Stores and OS Updates" category of the “File transferring” group (see the screenshots). At the moment, Keenetic OS v3.9 Beta 1 includes the latest traffic classification engine. You can update your KeeneticOS to 3.9 Beta 1 from the update channel Dev or Preview. The next release following 3.8.5 will include the latest traffic classification engine as well.
-
2
-
-
On 2/14/2020 at 8:40 PM, KorDen said:
3.4 Alpha 1, трубка S850HX, при входящих-исходящих звонках отсутствует слышимость удаленной стороны (сервер->роутер), явно не проключается входящий RTP ни в early media, ни во время разговора.
Захватите и выложите здесь дамп трафика звонка без звука. Чтобы в дамп попала вся сигнализация и аудиопотоки звонка, захватывайте трафик следующим образом:
1) настроить захват трафика с фильтром “udp” на внешнем интерфейсе роутера;
2) включить захват трафика;
3) позвонить, убедиться, что звука нет;
4) через минуту после ответа на вызов завершить звонок;
5) выключить захват.Возможно, дамп поможет понять причину отсутствия звука.
Статья о том, как захватывать трафик: https://help.keenetic.com/hc/ru/articles/360000401420 -
On 9/29/2017 at 8:29 AM, Swetch said:
но SIP ALG по факту не работает
В отладочной версии NDMS 2.11.A.8.0-1 добавлен опциональный режим работы SIP ALG при котором любой IP-адрес в SDP перезаписывается адресом внешнего интерфейса. Вы можете загрузить отладочную версию и выполнить команду “no ip sip alg direct-media”, чтобы включить этот режим. Это должно решить вашу проблему односторонней слышимости без использования IPSec.
-
1
-
-
4 hours ago, Swetch said:
с маской понятно, думал где то в фаерволе можно настроить
Попробуйте создать на стороне телефона три правила межсетевого экрана для интерфейса Home: разрешить UDP от телефона к АТС, разрешить UDP от телефона к DSP и третье - запретить IP из домашней подсети в рабочую. И аналогичные правила на стороне АТС, чтобы разрешить UDP от АТС к телефону, от DSP к телефону и запретить IP из рабочей сети в домашнюю. В обоих случаях запрещающее правило должно быть последним в списке. После добавления правил межсетвого экрана нужно перезагрузить устройства.
-
6 hours ago, Swetch said:
в общем настроил IPSec, телефон работает, только работа и дом теперь в одной сети, ткните носом как закрыть сети друг от друга при этом оставить нужное соединение...
Для этого можете максимально сузить диапазоны IP-адресов подсетей указанных в настройках второй фазы IPSec. Вместо адреса домашней подсети 192.168.15.0/24 можно указать только адрес телефона. Он должен быть статическим. Вместо адреса рабочей подсети можно указать подсеть с минимальным диапазоном адресов включающую адреса АТС и DSP (10.0.0.219 и 10.0.0.220). Похоже, это будет подсеть 10.0.0.216/29. С такими настройками через туннель может ходить трафик только между телефоном и диапазоном адресов 10.0.0.217 - 10.0.0.222 рабочей подсети.
-
1 minute ago, Le ecureuil said:
Это я товарищу @sips про его конкретный пост с неправильными портами.
соберите для GIGAII. Протестирую.
2 hours ago, Swetch said:IPSec звернет весь трафик на GIGA II а мне этого не надо...
IPSec завернет только трафик адресованный в удаленную подсеть в соответствии с настройками фазы 2 IPSec.
-
On 9/24/2017 at 12:05 PM, Swetch said:
у АТС два ip адреса 80.69.ХХХ.ХХХ проброшен на локальный 10.0.0.219 sip
10.0.0.220 ip DSP платы, не понимаю почему TGP-600 пытается подключиться на локальный?
прикрепил захват пакетов с обеих сторон, помогите пожалуйста разобраться...
Исходя из дампов трафика, в вашем случае АТС отправляет телефону ответ 200 с IP-адреса 10.0.0.219. При этом в полях “o” и “с” секции SDP этого ответа указан другой IP-адрес: 10.0.0.220. NDMS SIP ALG на GIGA II не перезаписывает локальный IP-адрес 10.0.0.220 в полях “o” и “с”, вероятнее всего, потому, что этот адрес не является IP-адресом отправителя данного сообщения. В результате телефон отправляет медиаданные на локальный IP-адрес АТС, и это вызывает проблему односторонней слышимости.
Думаю, данная реализация SIP ALG заработает, если вы сделаете так, чтобы АТС и DSP были на одном локальном IP-адресе.
Еще можно поднять туннель IPSec между двумя вашими Кинетиками, чтобы маршрутизировать SIP-сигнализацию и медиаданные между подсетями 10.0.0.x и 192.168.15.x через этот туннель. Тогда в настройках телефона можно будет указать локальный IP-адрес АТС. Телефон будет адресовать АТС и DSP по их локальным IP-адресам, SIP ALG использоваться не будет и, медиаданные дойдут от телефона до АТС. -
Дополнительное тестирование показало, что SIP ALG в NDMS 2.09 работает. Он перезаписывает локальные IP-адреса и порты в SIP-сообщениях адресованных на порт UDP 5060. Если SIP-сообщения отправляются на другой порт, то SIP ALG их игнорирует.
Если NAT вашего устройства Keenetic GIGAIII отображает локальный SIP-порт телефона на внешний порт отличный от UDP 5060, то SIP ALG устройства Keenetic GIGAII не будет перезаписывать адреса и порты в сообщениях АТС адресованных телефону на этот порт. И это может быть причиной односторонней слышимости.
Захватите сигнализацию SIP (статья 4068 базы знаний на https://help.keenetic.net) на внешнем интерфейсе GIGA II при исходящем вызове с телефона TGP600 и проверьте порт источника в заголовках UDP пакетов сообщений SIP приходящих от телефона. Если это не порт 5060, то это может быть причиной проблемы.
В этом случае можно заставить NAT отображать UDP 5060 на тот же порт. Для этого нужно создать правило NAT на GIGA II (веб-конфигуратор>Безопасность>Трансляция сетевых адресов (NAT):
Интерфейс: ISPПротокол: UDP/5060
Перенаправить на адрес: IP-адрес телефонаНовый номер порта назначения 5060 (локальный SIP-порт телефона)
После добавления правила нужно перезагрузить GIGA II. Если после этого сигнализация от телефона будет приходить с порта 5060, SIP ALG на GIGAII должен работать.
-
При маршрутизации сообщений сигнализации SIP из LAN в WAN механизм SIP ALG должен перезаписывать локальный IP-адрес на IP-адрес внешнего интерфейса маршрутизатора в заголовке SIP и в SDP этих сообщений. Тестирование показало, что GIGAIII с релизом NDMS 2.09 этого не делает. Разработчики NDMS проинформированы о данной проблеме. Когда проблема будет устранена, вы будете проинформированы.
Вероятнее всего, проблему односторонней слышимости можно устранить активировав STUN на вашей АТС. STUN перезапишет локальный IP-адрес АТС внешним IP-адресом NAT в сообщениях SIP от АТС. В документе NS500_Installation_Manual.pdf найденном навскидку в Интернете имеется информация о том, как активировать STUN на NS500. Кстати, на телефоне TGP600 лучше тоже активировать STUN, если это еще не сделано.
-
Попробуйте сконфигурировать автоматический выбор интерфейса для подключения VAPP:
Keentic LTE GUI>Телефон>SIP>Подключение VAPP>Выбрать интерфейс: Выбрать интерфейс.
После применения новых настроек перезагрузите устройство. В моем случае это помогло решить проблему с отсутствием SIP-регистрации на Keenetic LTE v2.09(AATF.6)A3 в режиме AP.-
1
-
-
Если у вас входящие вызовы не работают, активируйте STUN-клиент на вашем Keenetic LTE (см. веб-конфигуратор>Телефон>SIP). Если STUN уже активирован, возможно, STUN-сервер, указанный у вас в настройках не отвечает. Попробуйте указать другой STUN-сервер, например stun.sipnet.ru:3478.
Если манипуляции со STUN не помогут, рекомендую вам захватить дамп трафика UDP на интерфейсе 4G LTE Internal Modem (LTE) вашего устройства во время входящих и исходящих вызовов, когда наблюдаются проблемы. Дампы выложите сюда. О том, как захватить трафик см. в этой статье: https://help.keenetic.net/hc/ru/articles/213966089. Вероятнее всего, дампы помогут выяснить причину ваших проблем.
Error 503 with Sky Wifi Italy and Keenetic Linear
in Community Support & Knowledge Exchange
Posted
Can you, please, check if you can get SRV and AAAA like in the following example?
$ nslookup -type=SRV _sip._udp.voip.glb.it.isp.sky
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_sip._udp.voip.glb.it.isp.sky service = 20 10 5060 sbc.mica1.voip.glb.it.isp.sky.
_sip._udp.voip.glb.it.isp.sky service = 40 10 5060 sbc.rmle1.voip.glb.it.isp.sky.
_sip._udp.voip.glb.it.isp.sky service = 30 10 5060 sbc.mid41.voip.glb.it.isp.sky.
$ nslookup -type=AAAA sbc.mica1.voip.glb.it.isp.sky
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: sbc.mica1.voip.glb.it.isp.sky
Address: 2a0e:402:100:200::7
$ nslookup -type=AAAA sbc.rmle1.voip.glb.it.isp.sky
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: sbc.rmle1.voip.glb.it.isp.sky
Address: 2a0e:402:100::7
$ nslookup -type=AAAA sbc.mid41.voip.glb.it.isp.sky
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: sbc.mid41.voip.glb.it.isp.sky
Address: 2a0e:402:100:300::7