Версия для печати темы

Автор: Alexey A. Astashov 21.3.2012, 10:12

не получается прозвониться по SIP на сотовый номер, получаю отлуп 404 No routes found, станция весело сообщает о неправильно набранном номере
в МТС говорят что мы неправильно отправляем поле FROM
в чем может быть косяк? во вложении трейс звонка

Автор: Dron 21.3.2012, 10:44

Пропишите ваш адрес 82.208.82.18 для Domain.

Автор: Alexey A. Astashov 21.3.2012, 10:51

аааааааааа, в МТС что-то поменяли у себя, теперь у меня после набора номера вся станция уходит в ребут....


PS
аааааа, любой успешный звонок через этот SIP Trunk уводит станцию в ребут


PS2. изменение Main Domain Name привело теперь к тому что Contact стал неправильно отправляться

В МТС сделали подмену заголовка VIA

Автор: Dron 21.3.2012, 11:07

Ну вы уж там договоритесь..

Автор: Alexey A. Astashov 21.3.2012, 11:11

они уже в зад все вернули, а станции всеравно крышну сносит, я сделал Trunk 789 через него пытаюсь позвонть и набираю типа
7899101234567# и станция махом уходит в ребут, причем пока станция ребутится звонок успешно приходит на сотовый, ну ясно дело что там тишина

Автор: Dron 21.3.2012, 11:16

А у вас User ID прописан? В каком виде?

Автор: Dron 21.3.2012, 11:24

А, при этом, обратно на станцию (на внутренний номер) не валится?? Этот мобильник в данной услуге прописан?

Автор: Alexey A. Astashov 21.3.2012, 11:31

в 373 программе
UserID пусто
AUID пусто
Registration NO
Usage YES
From Number UserID
Contact Number UserID
Firewall Routing YES

в 131 PGM
11 - пусто

Автор: Alexey A. Astashov 21.3.2012, 11:32

обратный звонок через эту группу проходит нормлаьно

Автор: Dron 21.3.2012, 11:33

Оно ранее работало, или только настраиваете??

Автор: Alexey A. Astashov 21.3.2012, 11:40

входящие заработали давно исходящие только настраиваем

во вложении полная трассировка вызова от начала до момента полной перезагрузки станции

Автор: Dron 21.3.2012, 11:53

9103967366 - это ваш мобильный? На МТС с него переадресация на 107?

Автор: Alexey A. Astashov 21.3.2012, 12:02

да это номер моего мобильно, да этотже номер по FMC явзяется привязанным у МТС как номер 107, но на самом деле пробовали не только со 107 звонить, мы пробовали осуществить звонок с другого внутреннего номера 140, результат получили тотже самый, звонили также
7899103967366# - станция ушла в ребут всеравно.

Автор: Dron 21.3.2012, 12:06

А сниф такого варианта можно глянуть? Со 140...
Получается, как бы, закольцовка... Вы со 107 набираете ваш мобильный, с МТС начинает сыпаться INVITE - вызывается 107... Как то так.

Автор: Alexey A. Astashov 21.3.2012, 12:45

сниф не сняли со 140 сейчас в МТС вернули все в самые начальные настройки до ошибки 404, сейчас я со своей стороны попробую поменять FROM.
в общем сделали со 139 номера во вложении:

Автор: Dron 21.3.2012, 12:47

В МТС, по-моему, можно прописать вызов внутреннего номера с задержкой. Так не пробовали?

Автор: Alexey A. Astashov 21.3.2012, 12:53

нет, незнаю..
выше сообщение отредактировал вложил туда сниф со 139 номера.

Автор: Dron 21.3.2012, 13:21

Кстати, а вы можете звонить не на свои мобильники? Как там с этим в FMC?

Автор: Alexey A. Astashov 21.3.2012, 13:31

Попробовал набрал вообще левый номер типа 9051234567 станция вывалилась в ребут.
Сниф во вложении, если посмотреть сниф, то видно как последний INVITE обрывается на перезагрузке станции.

Автор: Alexey A. Astashov 21.3.2012, 18:26

в общем что я только не пробовал, не работает вызов через МТС.

1. проверил через бортовую VOIU тот-же результат
2. Снял VOIB24 - установил VOIB8 на это место, проверил, вызов как с VOIB8 так с VOIU+VOIB8 - станция стабильно уходит в ребут..

думамю на этом мои силы иссякли, проверть и смотреть больше нечего.. и прошивки менял как станции так и VOIBов, ничего не помогает.. тут нужна уже более глобальная помощь в поиске проблемы..
одно я знаю точно станция не должна уходить в ребут

Автор: Alexey A. Astashov 21.3.2012, 19:11

По рекомендациям полностью обнулил и проинициализировал станцию, поменял даже все номера доступа к группам, запрограммировал только SIP через MTS больше вообще ничего не запрограммировано, первый звонок - станция ушла в ребут

Больше скажу, я даже забыл прописать IP адрес на плату VOIB, т.е. до нее даже RTP пакеты не доходят, а станция всеравно уходит в ребут.. т.е. проблемы еще до установления RTP соединения.

Автор: Dron 21.3.2012, 21:37

А у вас NAT используется? Я к тому, если имеется роутер, можете ли снять снифы и со стороны LAN, и со стороны WAN??
И, не пробовали набирать не мобильный, а короткий номер FMC??

Автор: Alexey A. Astashov 22.3.2012, 7:46

NAT имеется, вообще сниф со шлюза собствено и снимается, снимаетестя все что ходит меду IP 213.87.52.254(МТС) и любым моим IP адресом как снаружи так и внутри по всем портам и протоколам без ограничений. Короткий номер также набирал результат тотже. Могу еще попросить прислать со стороны МТС сниф собственно.

Автор: Dron 22.3.2012, 7:55

Вот и интересно посмотреть на MG. Потому как, из представленных снифов видно, что INVITE на МТС ушел, МТС отвечает, а от MG ответа нет...

Автор: Alexey A. Astashov 22.3.2012, 8:12

хорошо, ближе к обеду или как АТС маленько разгрузится сниму сниф с процессора(172.16.15.211). а ответа нет собственно потому что АТС мгновенно перегружается.

Автор: Dron 22.3.2012, 8:13

Но посмотреть то надо.

Автор: Alexey A. Astashov 22.3.2012, 8:24

ну в общем снял сниф с проца см. вложение

(я вот думаю гдебы найти вторую АТС, чтобы не обижая руководство периодическами перегрузками станции путём набора номера проводить собственно эксперименты)

Автор: Dron 22.3.2012, 8:59

Это вы опять звонили на свой мобильник. Тут опять путаница возникает. Вы со 107 звоните на свой мобильник, а с МТС вызывется номер 107... Интересно посмотреть вызов с другого внутреннего номера.

Автор: Alexey A. Astashov 22.3.2012, 9:09

аааа, ну ладно:
(во вложении 2 файла, значит 1 со 140 на мой мобильный, второй со 140 на левый номер. снято с проца статистика)

Автор: Dron 22.3.2012, 9:39

Что то крышу сносит... Почему в заголовках ТО 9103967366@82.208.82.18, а не 9103967366@213.87.52.254??
Где косяк??...

Автор: Alexey A. Astashov 22.3.2012, 9:47

Потому что МТС просит от нас присылать поле FROM с нашим IP адресом, а сталобыть мы в Main Domain Name поставили наш IP адрес. почему так, хз. на самом деле пробовали по всякому.


PS
У нас в консиллиуме после долгого сравнивания протокола соединения SIPNET и МТС было обнаружено, что МТС работает в форамте: Content-Type: application/gtd, а SIPNET Content-Type: application/sdp
Насколько я правильно понимаю gtd это цисковский проткол, и нужен он МТС для поддержки закрытых групп.

Автор: Dron 22.3.2012, 10:00

Да, это из-за Main Domain Name...

Автор: Alexey A. Astashov 22.3.2012, 10:03

Ну это да тем не менее станция не должна перегружаться.



----
PS я умею не только попадать в баги, я научился их скрещивать

Автор: Dron 22.3.2012, 10:11

Для начала хотелось бы понять, почему она не отвечает...

Автор: Alexey A. Astashov 22.3.2012, 10:13

ну как минимум, вообще станция уходит в ребут практически сразу после набора номера и отправки путём нажатия #

Автор: Dron 22.3.2012, 10:17

Да, но в одном из снифов, при этом, ответила на BYE(не относящийся к данному вызову, но адекватно), до которого получила кучу 200ОК...

Автор: Dron 22.3.2012, 10:25

А можете попробовать оставить для FMC только одну линию??

Автор: Alexey A. Astashov 22.3.2012, 10:29

Станция на момент ответа на BYE уже перегрузилась, и ответила адекватно - типа какго хрена мне BYE если соединение не устанавливалось.
200 она тоже начала получать после перезагрузки станции, потому что платформа FMC успешно произвела соединение с сотовым телефоном, потому что он звонит, но обрабатывать пакеты она уже не в состоянии постому что у станции более нет информации о звонке.

Автор: Alexey A. Astashov 22.3.2012, 10:29

вчера пробовал, сбрасывал в 0 станцию, и настраивать только 1 - FMC более ничего, результат не изменился.. очевидно что станция валится получая следующие пакеты от МТС.
добавлю, что входящий-же звонок FMC на станцию имеет формат - Content-Type: application/sdp
Уже есть мнение что станция не умеет обрабатывать Content-Type: application/gtd

Автор: Dron 22.3.2012, 10:39

Понял. Тогда логично все.
Т.е., что имеем? При Main Domain Name 213.87.52.254 станция не перезагружается, но и вызова нет, так?

Автор: Dron 22.3.2012, 10:44

Я не много не о том. У меня тут в голове крутится мысль... Я про то, чтобы был, для пробы, только ОДИН канал с МТС. Чтобы при вызове мобильного со станции, на нее от МТС больше ничего не могло бы поступить...

Автор: Alexey A. Astashov 22.3.2012, 10:47

404 No routes found, в МТС делали скрипт подмены поля FROM, результат тотже, станция уходила в ребут

Автор: Alexey A. Astashov 22.3.2012, 10:49

так и делал, 1 единственный канал FMC, да и с VOIB8 у меня и так 1 канал и был на FMC, потому что каналов не хватало.

Автор: Dron 22.3.2012, 10:50

Ок.
А можно сниф входящего вызова глянуть?

Автор: Alexey A. Astashov 22.3.2012, 10:56

см.вложение:

Автор: Dron 22.3.2012, 10:59

Спасибо

Автор: switch 22.3.2012, 11:26

xxx: знаешь, какая самая опасная служба для собаки?
yyy: ну
xxx: на границе
xxx: а знаешь на какой?
yyy: нет
xxx: между северной и южной кореями
yyy: ))))))))))))))))))

Автор: Alexey A. Astashov 22.3.2012, 11:35

ну да это конечно весело, но у нас веселья особого... былабы у нас еще одна станция для экспериментов, болбы проще а так да, МТС просит позвонить протестировать очередное изменение, тут просят позвонить и собрать сниф.. в итоге народ остается на время ребута станции (а иногда даже не успешного, приходится руками ребутить) без связи

Автор: Alexey A. Astashov 22.3.2012, 17:43

rfc3398
http://www.rfc-editor.org/rfc/rfc3398.txt

5.1 'Transparent' Transit of ISUP Messages

To allow gateways to take advantage of the full range of services
afforded by the existing telephone network when placing calls from
PSTN to PSTN across a SIP network, SIP messages MUST be capable of
transporting ISUP payloads from gateway to gateway. The format for
encapsulating these ISUP messages is defined in [3].

SIP user agents which do not understand ISUP are permitted to ignore
these optional MIME bodies.

5.2 Understanding MIME Multipart Bodies

In most PSTN interworking situations, SIP message bodies will be
required to carry session information (Session Description Protocol -
SDP) in addition to ISUP and/or billing information.

PSTN interworking nodes MUST understand the MIME type of
"multipart/mixed" as defined in RFC2046 [4]. Clients express support
for this by including "multipart/mixed" in an "Accept" header.


rfc3261
http://www.faqs.org/rfcs/rfc3261.html

Документы по ITU-T:
•Q.GTD.1 —Generic Transparency Descriptor Syntax Definition

•Q.GTD.2 —Generic Transparency Descriptor Usage Rules and Mappings


Интересная информация тут:
http://docstore.mik.ua/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/941fm/fmsipt.htm#wp1103885


Документы от Cisco:
http://www.cisco.com/en/US/docs/voice_ip_comm/pgw/9/feature/module/9.4_1_/FMsipt.pdf

http://old.ciscoexpo.ru/moscow/2008/download/pdf/SP_Voice_Update-afelizha.pdf


Из пакета видно, что формируется multipart/mixed
который содержит в себе информацию, после которой есть мнения что станция валится в ребут:

Content-Type: multipart/mixed;boundary=unique-boundary-1
MIME-Version: 1.0
Content-Length: 414

--unique-boundary-1
Content-Type: application/sdp

v=0
o=personeta 23927 52451 IN IP4 213.87.52.254
s=iPECSMG Call
c=IN IP4 213.87.52.254
t=0 0
m=audio 19638 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

--unique-boundary-1
Content-Type: application/gtd
Content-Disposition: signal; handling=optional

ANM,
CNN,00,,0,4,

--unique-boundary-1---ÀjOtÅ^@^@N^B^@^@N^B^@^@^@&Z^EãÇ´^Nܲ^G/^H^@EÀ^B@<8c>0^@^@@^A%<94>¬^P^OÓÕW4þ^C^C^?æ^@^@^@^@E^@^D^_^@^@^@^@t^Q|<95>ÕW4þ¬^P^OÓ^SÄ^SÄ^D^KVÎSIP/2.0 200 OK

Автор: Alexey A. Astashov 23.3.2012, 9:00

Тут уже нужна тяжелая артиллерия - например Артком, для того чтобы сформировать запрос к разработчику, я так понимаю что только Артком это вправе делать?.. кто-тоже должен у себя проверить этот баг, готов оказать содействие и договорться с МТС для того чтобы IP адрес разрешили для звонков в нашу внутреннуюю сеть.

Автор: vldmr 23.3.2012, 9:11

Позвони
Будет время сегодня от себя попробую

Автор: Alexey A. Astashov 26.3.2012, 18:04

Ну в общем я так понимаю что разобрались почему не работает, остается только ждать когда разработчик поправит этот момент..

Автор: vldmr 26.3.2012, 20:23

Пока похоже разобрались почему рестартует, будем чинить.
На LIK кстати работает без проблем.

Автор: harris 27.3.2012, 8:06

Что чинить?? Чтоб не рестартовала?? - Это да, понятно.
Но SIP-T/STD корейцы не планировали вводить в LIK/MG.
И непонятно, зачем вообще МТС шлет эту инфу в сторону MG.

Автор: Alexey A. Astashov 27.3.2012, 8:29

по стандарту как минимум станция имеет право игнорировать эту информацию. В любом случае опыт с LIK показал, что свзь с SIP-T/STD (GTD) работает нормально.. так почему-бы не сделать так чтобы еще и MG работала с МТС... я лично понимаю что платформы Cisco 2200 не сильно распространены в России, но тем не менее. МТС один из крупнейших сотовых операторов в России, и сейчас услуга работы по SIP у них начинает предоставляться все в больших регионах России, а услуга FMC переходит в централизированное управление как следствие любая распределенная организация сможет безболезненно и за небольшие деньги организовать корпоративную телефонную связь Mobile as DECT (мы например планируем включить в одну корпоративную телефонную сеть СПБ, МСК, НН, Томск, Хабаровск). Такое развитие услуги у МТС будет означать что проблемы у владельцев iPECS-MG будут появляться чаще. И что владельцам MG из-за этого продавать свои станции и покупать Cisco или Avaya (отличный коммерческий шаг)? кстати сказать, частично опираясь на наш опыт - МТС уже исправили работу с iPECS у себя, по началу iPECS вообще никак не дружил с МТС, сейчас благодаря нам МТС с iPECS теперь умеет устанавливать нормальную связь при звонках в обратном направлении (с сотового на станцию), теперь остался вопрос за LG, чтобы iPECS научился устанавливать связь в прямом направлении с iPECS на Сотовый через эту услугу.

Автор: harris 27.3.2012, 8:45

Я же это и имел в виду.
LIK просто игнорирует GTD, а MG уходит в перезагрузку. Это баг. Это нужно исправлять, но не более того.
Поддержку GTD (отработку) не будут вводить ни в LIK, ни в MG, поскольку это не имеет смысла.
Мне просто непонятно, зачем МТС посылает GTD в сторону клиента (MG)...

Автор: Alexey A. Astashov 27.3.2012, 9:32

Ну как они говорят GTD необходим для связи Мобльной сети с SIP, а вообще этим занимается платформа Cisco 2200 для которой стандартом SIP является SIP-T/GTD, вот она и посылает при соединении эти пакеты, МТС не может передалать у себя протокол как-то по другому.
В любом случае конечным абонентам всеравно как станция будет обрабатывать протокол, задача конечного абонента получить связь и чтобы связь была качественная.

(и так в мыслях, понимаю что это не очень нужно)
Я так понимаю, что если реализовать SIP-T/GTD на iPECS, то теоритически из этой станции можно будет сделать мега сервер SIP который будет управлять закрытыми группами абонентов, распределять звонки между цифровыми потоками итд в общем получить станцию с возможностями платформ которые стоят совершенно других денег.
поправьте меня если не правильно понял как это работает.

Автор: harris 27.3.2012, 9:46

Нет. Если я правильно понимаю, то SIP-T (и как вариант GTD) - это передача сигнальной информации протокола ОКС7 (SS7) между двумя узлами связи посредством SIP, т.е посредством инкапсуляции сообщений ISUP (SS7) в сообщения SIP.

Автор: Alexey A. Astashov 27.3.2012, 9:54

неправильно выразился я, не как это работает, а для чего это нужно.. всмысле если я правильно понял иммется ввиду это необходимо, чтобы средствами протокола управлять доступами к закрытым группам SIP, при организации переходов между SIP-ISDN.

Автор: harris 27.3.2012, 9:57

Пардон, но я не очень понимаю, как связаны ISUP и закрытые группы SIP.
По мне, так это совершенно разные вещи.

Автор: Alexey A. Astashov 27.3.2012, 10:00

вот и я пытаюсь понять

Автор: All is not what it seems 27.3.2012, 11:18

Пусть выключат в вашу сторону:
This task reenables the feature if it was disabled by using the no isdn gtd.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftgtdisd.html

Автор: Alexey A. Astashov 27.3.2012, 12:52

говорят что не многут выклчить

Автор: switch 27.3.2012, 16:06

Яйца мешают

Автор: Alexey A. Astashov 27.3.2012, 16:26

да хоть тапочки, самое главное во всем этом - станция не должна перегружаться при наборе номера! не зависимо от того что на нее послали. А в применительно к данному контетксту еще необходимо, чтобы станция устанавливала связь, т.е. выполняла свои прямые функции

Автор: Dron 27.3.2012, 16:59

Тут не поспоришь!


Да. Но нельзя от нее требовать того, чего она выполнять не обязана...

Автор: harris 27.3.2012, 17:10

Да, но это от нее и не требуется. Она должна игнорировать информацию GTD, и отрабатывать вызов, как любой другой, и не уходить в перезагрузку. Это просто баг, который нужно устранить.
А вот LIK в аналогичной ситуации ведет себя нормально.

Автор: Alexey A. Astashov 27.3.2012, 17:12

В данном контексте она просто обязана установить успешную связь с МТС, иначе станция дискредетирует себя окончательно, как не поддерживающая стандарты в которых работают ведущие операторы связи РФ но думаю, на самом деле инженера по ПО смогут разобраться с ней, чтобы все заработало. сегодня от них я получил окло полусотни пустых звонков, один из которых был успешный, но я незнаю с чего они устанавливали связь с исправленной версией MG или чего-то другого.. потому как на последующие звонки я уже даже трубку снимать не успевал, как будто, сделали вызов и сразу-же уже послал CANCEL.

Автор: Dron 27.3.2012, 17:37

Вот у нас в прошлом, или позапрошлом году МТС меняло оборудование. У одного из наших клиентов, подключенных по Е1 к Тулателеком (они были не одни такие, естественно) возникла проблема - не могли звонить на мобильные МТС Тульской области, на любые другие номера, в том числе и на мобильные МТС других регионов - без проблем.
Оказалось, что МТС в ALERTING выдавало инфу, не предусмотренную EDSS, ipLDK прекращало вызов. Инженеры МТС сначала утверждали, что у них все по правильному. Тулателекому то все равно было - они просто перегоняли все как есть.
И что, работала себе станция много лет нормально, провайдер поменял у себя оборудование - покупать новую станцию?!
Разобрались, конечно, устаканили все... Около месяца разбирались.

Автор: Dron 27.3.2012, 17:39

Игорь, так я о том же. Естественно, в данном случае, станция должна проигнорировать и не уходить в перезагрузку.

Автор: Alexey A. Astashov 27.3.2012, 17:46

второе главное, чтобы вызов был обработан как любые другие ключевое слово тут - "обработан" а не отброшен как непонятный ) с LIK-то все работает

Автор: Dron 27.3.2012, 17:49

А я о чем то другом??
Проигнорировать - не обратить внимания, не отреагировать...
А, по большому счету, зачем слать то, что другие не обязаны выполнять... Во избежание нестыковок.
В перезагрузку уходить, по-любому, станция не должна!

Автор: vldmr 28.3.2012, 10:38

Диспут зациклился!!!
Сидим спокойно и ждем, люди работают.

Автор: Alexey A. Astashov 28.3.2012, 14:15

ТОлько что мне звонили для проверки мегаинжеера LG-Erricsson, и сообщили радостную весть, что баг фиксед, в ближайшее время соберут прошивку и будет щастье, судя по всему звонили с софта именно для iPECS-MG.

Автор: harris 28.3.2012, 15:12

Угу... А упомянутый "мегаинженер LG-Erricsson", сидящий рядом со мной, уже по уши погрузился в разбор других проблем... (по данному багу уже ушел запрос в Корею).... Чего-то сегодня день какой-то, мягко говоря, "урожайный" на выявленные проблемы... То неделями тишь да гладь, то одно за другим... Не то что раньше, при плановом хозяйстве...

Автор: Alexey A. Astashov 30.3.2012, 10:35

Граждане разработчики из Юной Кореи чтонибудь ответили?, не слыхать когда будет обновление?

Автор: harris 30.3.2012, 15:13

Чтоб ответили на след. день?? И чтоб уже все исправили?? И это несмотря на то, что у них и так работы хватает??
Так не бывает... Придется подождать!

Автор: Alexey A. Astashov 30.3.2012, 15:20

Еще нужен доступ в наш транк на МТС?

Автор: harris 30.3.2012, 15:25

Да, пока нужен... На днях пришлют новый софт, его нужно будет проверить.

Автор: Alexey A. Astashov 30.3.2012, 16:30

ok