Тема: LDK-60 + SIP (Need help!)
И при входящих с отбоем нормуль?
Спасибо за подсказку, как-то я на радостях о входящих подзабыл, и вот не нормуль с ними оказалось http://zalil.ru/34239191, нормально отбиваются только исходящие звонки....
Если я не путаю, то вроде бы провайдер не поддерживает T.38 и поэтому вам нужен G.711 для факсов. Так??
Тогда нужна трассировка попытки передать/принять факс при опции Fax Mode = Disable (all fax mode disable).
Провайдер говорит, что он поддерживает Т38, но лучше использовать Т30 по его же словам.
И при входящих с отбоем нормуль?
Спасибо за подсказку, как-то я на радостях о входящих подзабыл, и вот не нормуль с ними оказалось http://zalil.ru/34239191, нормально отбиваются только исходящие звонки....
ОК. Сейчас свяжемся с корейцами.
Увы, придется подождать с решением до конца след. недели.
В Кореи сейчас начались праздники - Восточный Новый Год.
С праздником!! 😊
Увы, придется подождать с решением до конца след. недели.
В Кореи сейчас начались праздники - Восточный Новый Год.
С праздником!! 😊
Подождем) Что нам остается то)
Добрый всем день! Получилось поймать заикание, проявляется оно периодически когда осуществляется один исходящий вызов и постоянно когда занимается несколько каналов единовременно. Подозреваю что дело в провайдере, но он упорно открещивается.
Трасса звонка http://zalil.ru/34253379
Уваж. G13MO!
Мы готовы отвечать за свои огрехи, но вовсе не за грехи всех провайдеров. И особенно тех провайдеров, которые не хотят разобраться со своими же проблемами. Они не знаю, что такое конкуренция?? 😊
У Вас там нет другого провайдера в ассортименте??? Похоже, что с этим и Вы замучаетесь... и нас вопросами завалите... 😊
Если есть просто Интернет, то попробуйте подключится на пробу к какому-нибудь другому провайдеру, к Sipnet, например. (Чтоб уж убедиться в исправности станции 😊).
Вы отправляли провайдеру вот эту же трассировкку??
Если нет, то отправьте ее прямиком к провайдеру. Пусть он посмотрит, какой от него идет RTP-поток, с каким джиттером.
Может, дело не именно в его сервере, но в ЕГО СЕТИ, ведь он доводит до Вас непосредственно свой “сосок”. Значит ВСЯ сеть находится в его зоне ответственности. Где-то пакеты от провайдера задерживаются, отсюда и все проблемы.
Поэтому голос от провайдера идет с “заиканием”.
А голос от станции идет нормально, поскольку Вы снимаете трассировку на своей стороне (до входа в сеть провайдера).
Уваж. G13MO!
Мы готовы отвечать за свои огрехи, но вовсе не за грехи всех провайдеров. И особенно тех провайдеров, которые не хотят разобраться со своими же проблемами. Они не знаю, что такое конкуренция?? 😊
У Вас там нет другого провайдера в ассортименте??? Похоже, что с этим и Вы замучаетесь... и нас вопросами завалите... 😊
Если есть просто Интернет, то попробуйте подключится на пробу к какому-нибудь другому провайдеру, к Sipnet, например. (Чтоб уж убедиться в исправности станции 😊).Вы отправляли провайдеру вот эту же трассировкку??
Если нет, то отправьте ее прямиком к провайдеру. Пусть он посмотрит, какой от него идет RTP-поток, с каким джиттером.
Может, дело не именно в его сервере, но в ЕГО СЕТИ, ведь он доводит до Вас непосредственно свой “сосок”. Значит ВСЯ сеть находится в его зоне ответственности. Где-то пакеты от провайдера задерживаются, отсюда и все проблемы.
Поэтому голос от провайдера идет с “заиканием”.
А голос от станции идет нормально, поскольку Вы снимаете трассировку на своей стороне (до входа в сеть провайдера).
Провайдер ответил))))
В звуковом файле, полученном на основании присланных Вами данных, заиканий нет, поэтому делать какие-то выводы сложно. Единственное, что бросилось в глаза – ваша мини-АТС шлет запросы на соединение, не отличающиеся уникальностью: они совпадают с точностью до байта вплоть до предлагаемого RTP-порта (2050). Сервер начинает общаться по соседним портам (2048 и 2052), RTP-пакеты при этом идут с очень частым интервалом. Справляется ли с этим трафиком ваша станция?
Провайдер ответил))))
В звуковом файле, полученном на основании присланных Вами данных, заиканий нет, поэтому делать какие-то выводы сложно. Единственное, что бросилось в глаза – ваша мини-АТС шлет запросы на соединение, не отличающиеся уникальностью: они совпадают с точностью до байта вплоть до предлагаемого RTP-порта (2050). Сервер начинает общаться по соседним портам (2048 и 2052), RTP-пакеты при этом идут с очень частым интервалом. Справляется ли с этим трафиком ваша станция?
Что имелось ввиду под уникальностью? И что не так в том, что запросы совпадают вплоть до байта?..
Если 60-ка предлагает порт 2050, почему сервер общается на 2048, 2052??
ИМХО, провайдер пишет ерунду и фактически занимается отписками!
Пускай внимательнее смотрит снифер!! См. также рисунок из снифера по ссылке:
http://rusfolder.com/34973302 (пароль для скачивания: LDK).
RTP-поток от провайдера идет “корявый”.
Если он проверяет “звуковой” файл, то там эта “корявость” нивелируется средствами WhireShark.
Нужно снифер смотреть, а не звуковой файл.
Что касается портов, то вообще неизвестно, что ему в голову пришло...
У Вас в станции 4 VOIP-канала (с допол. платой VOIU - 8). Для каждого канала используется своя пара портов RTP/RTCP:
Voice channels, 1, RTP/RTCP 2048/2049 udp
Voice channels, 2, RTP/RTCP 2050/2051 udp
Voice channels, 3, RTP/RTCP 2052/2053 udp
Voice channels, 4, RTP/RTCP 2054/2055 udp
Для исходящей связи занимается либо последний (старший) канал из данной группы линий, либо каналы занимаются по кругу. Это определяется значением параметра CO Line Choice (ПГМ160/3): Last/Round.
Еще раз Вам предлагаю: подключитесь просто через Интернет к любому нормальному провайдеру (Sipnet, MTT), благо сейчас провайдеров полно. И убедитесь, что ваша станция работает нормально.
Проблемы с LDK в данном случае мы никакой не видим. У нее на входе кривой RTP с большим джиттером, неравномерный, с задержками, с потерей пакетов и нарушенным порядком пакетов. Станция это никак не может нивелировать. Что станция получила, то Вы и слышите. Это проблема провайдера, его сети!!
Извините, но “бодаться” с вашим провайдером уже начинает надоедать... И это мягко сказано...
Можно попробовать немного увеличить размер буфера джиттера (Jitter Buffer) в станции - в ПГМ340.
(По умолчанию там = 150). Возможно, “заикание” будет немного сглажено, но в целом это проблему не решит.
Уваж. G13MO!
Мы отправили Вам новую версию прошивки для VOIB, на которой сообщение сообщение BYE формируется корректно как в случае исходящего, так и при входящем вызовах.
Можно попробовать немного увеличить размер буфера джиттера (Jitter Buffer) в станции - в ПГМ340.
(По умолчанию там = 150). Возможно, “заикание” будет немного сглажено, но в целом это проблему не решит.Уваж. G13MO!
Мы отправили Вам новую версию прошивки для VOIB, на которой сообщение сообщение BYE формируется корректно как в случае исходящего, так и при входящем вызовах.
Большое вам спасибо! Отбой стал корректно срабатывать как при исходящих, так и при входящих вызовах. Трасса входящего вызова http://zalil.ru/34259940
С заиканием провайдер также решил проблему.
С заиканием провайдер также решил проблему.
Ну наконец-то!! 😊
ИМХО, вместо того, чтобы заниматься отписками, они могли бы уже давно вникнуть в суть проблемы, проанализировать и устранить ее... Ну лучше поздно, чем никогда 😊
Теперь, может быть, и факсы пойдут нормально...
Спасибо за проверку версии софта и за трассировку. Удачи!!
