AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

УралСвязьИнформ+"неподдерживаемый"t38+звонки с городских цифровых АТС = проблема

Asterisk IP PBX 19 сообщений -
#1
Имеется:
asterisk 1.6.0.5
ubutu 8.04.2
городской телефон по сипу от уралсвязьинформа.
Проблемма:
при звонках на сип телефон с городских цифровых АТС слышимость в одну сторону.
Дебаг SIP и RTP показал сл:
SIP
Код:
v=0
o=MG2K5_731_25_4 2278744009 2278744009 IN IP4 62.148.237.201
s=-
p=+7
t=0 0
m=audio 54690 RTP/AVP 8
c=IN IP4 62.148.237.201
a=ptime:20
m=image 0 udptl t38
c=IN IP4 10.104.12.136

RTP
Код:

Sent RTP P2P packet to 10.104.12.136:44778 (type 08, len 000320)
Sent RTP P2P packet to my_ext_IP:50000 (type 08, len 000160)

Разговор с тех поддержкой:
Они знают про проблеммы с asterisk и с этими станциями. Говорят что мы официально не поддержываем ОперСурс, и официально не поддерживаем t38, но всетаки он есть....И внятного ответа какого лешего ко мне на * попадает их внутренний IP 10.104.12.136 не смогли дать.
Перекрутил все кодеки, прочитал кучу мануалов но так ничего внятного и не нашел.
Кто и как решил эту проблемму?
#2
Покажи INVITE от них
#3
Это при поступлении звонка на астериск
Код:

INVITE sip:s@my_Ext_IP:5060;maddr=my_Ext_IP SIP/2.0
From: ;tag=-45026-196882b-63575b2f-196882b
To: "my_Name my_Name"
Call-ID: e493d905325d69a7120e85ec6be545465df30dd@62.148.237.132
CSeq: 1 INVITE
Via: SIP/2.0/UDP 62.148.237.132:5060;branch=z9hG4bK-178bac2-bf998818-76ce42a0
content-type: application/sdp
contact:
user-agent: CS2000_NGSS/9.0
max-forwards: 69
supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join
remote-party-id: ;screen=yes;party=calling;privacy=off
allow: ACK,REFER
allow: BYE
allow: CANCEL
allow: INVITE
allow: OPTIONS
allow: INFO
allow: SUBSCRIBE
allow: REFER
allow: NOTIFY
allow: PRACK
allow: UPDATE
x-nt-corr-id: a493d90532d0faa7120e85ee4ffbe78c8e349bb@62.148.237.132
x-nt-location: 193624
privacy: none
Content-Length: 147

v=0
o=MG2K5_731_25_4 2278744002 2278744002 IN IP4 62.148.237.201
s=-
p=+7
t=0 0
m=audio 54690 RTP/AVP 8
c=IN IP4 62.148.237.201
a=ptime:20

а это после того как я поднимаю трубку на IP телефоне (dlink DPH-150SE)
Код:

INVITE sip:s@my_Ext_IP SIP/2.0
From: ;tag=-45026-196882b-63575b2f-196882b
To: "my_Name my_Name";tag=as521b003b
Call-ID: e493d905325d69a7120e85ec6be545465df30dd@62.148.237.132
CSeq: 2 INVITE
Via: SIP/2.0/UDP 62.148.237.132:5060;branch=z9hG4bK-178baca-bf99a5df-2380151f
content-type: application/sdp
contact:
user-agent: CS2000_NGSS/9.0
max-forwards: 69
supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join
allow: ACK,REFER
allow: BYE
allow: CANCEL
allow: INVITE
allow: OPTIONS
allow: INFO
allow: SUBSCRIBE
allow: REFER
allow: NOTIFY
allow: PRACK
allow: UPDATE
x-nt-corr-id: a493d90532d0faa7120e85ee4ffbe78c8e349bb@62.148.237.132
x-nt-location: 193624
Content-Length: 192

v=0
o=MG2K5_731_25_4 2278744009 2278744009 IN IP4 62.148.237.201
s=-
p=+7
t=0 0
m=audio 54690 RTP/AVP 8
c=IN IP4 62.148.237.201
a=ptime:20
m=image 0 udptl t38
c=IN IP4 10.104.12.136
#4
Как я это вижу: проблема действительно в *. Точнее в том, как он отрабатывает множественное описание "connection information" в SDP. При реинвайте * приходит описание "медиа-контакта" для голосовых сессий (первый параметр с в SDP) и "медиа-контакт" для t38 сессий. Почему-то * запоминает только последнее упоминание этого поля.
С другой стороны t38 с этим провом НЕ ЗАРАБОТАЕТ по тем же причинам. Так что можно продолжать любовную переписку с тех. саппортом Smile

Можно попробовать побаловаться с параметром nat, но тут без гарантий - как уж * отработает =)
#5
nat=yes
или nat=no
вы про это?

я думаю еще можно сделать вариант в iptables прописать "проброс" c 10.104.12.136 на IP провайдера.
есть ли вариант вообще отключить t38 ???
#6
Zmiy писал(а):
вы про это?
Да, было вроде еще nat=route
Отключать t38 безсмысленно я думаю, хотя можно поставить t38udptl= no (в названии параметра могу ошибаться).

Проброс конечно тоже вариант, но уж больно костыльно выглядит, ИМХО.
#7
Не знаю, может я не в тему, но сталкивался с подобной ситуацией на другой куллсвитче и уяснил себе одну вещь, если голосовой порт отдается вне принятого диапазона портов (10000-30000). то односторонняя слышимость просто обеспечена...

v=0
o=MG2K5_731_25_4 2278744009 2278744009 IN IP4 62.148.237.201
s=-
p=+7
t=0 0
m=audio 54690 RTP/AVP 8
c=IN IP4 62.148.237.201
a=ptime:20
m=image 0 udptl t38
c=IN IP4 10.104.12.136
#8
Это указывается порт, на котором удаленная сторона готова принимать медиа-трафик. Никакого отношения к * и его портам не имеет.
#9
у УСИ порты RTP в диапазоне 40000-60000
#10
Скажите если не прав.

рассмотрел функцию get_ip_and_port_from_sdp из chan_sip.c

Код:


05238 c = get_sdp_iterate(&citerator, req, "c");
05239 if (sscanf(c, "IN IP4 %256s", host) != 1) {
05240 ast_log(LOG_WARNING, "Invalid host in c= line, '%s'\n", c);
05241 /* Continue since there may be a valid host in a c= line specific to the audio stream */
05242 }
05243 /* We only want the m and c lines for audio */
05244 for (m = get_sdp_iterate(&miterator, req, "m"); !ast_strlen_zero(m); m = get_sdp_iterate(&miterator, req, "m")) {
05245 if ((media == SDP_AUDIO && ((sscanf(m, "audio %30d/%30d RTP/AVP %n", &x, &numberofports, &len) == 2 && len > 0) ||
05246 (sscanf(m, "audio %30d RTP/AVP %n", &x, &len) == 1 && len > 0))) ||
05247 (media == SDP_VIDEO && ((sscanf(m, "video %30d/%30d RTP/AVP %n", &x, &numberofports, &len) == 2 && len > 0) ||
05248 (sscanf(m, "video %30d RTP/AVP %n", &x, &len) == 1 && len > 0)))) {
05249 /* See if there's a c= line for this media stream.
05250 * XXX There is no guarantee that we'll be grabbing the c= line for this
05251 * particular media stream here. However, this is the same logic used in process_sdp.
05252 */
05253 c = get_sdp_iterate(&citerator, req, "c");
05254 if (!ast_strlen_zero(c)) {
05255 sscanf(c, "IN IP4 %256s", host);
05256 }
05257 break;
05258 }
05259 }


получается что он первый раз читает заголовок находит что есть параметр с, определяется переменная host. а потом второй раз ищет, НО уже первое объявление с он не видит.

Только не понятно нафига это сделано?
#11
Первое объявление c является глобальным для всего SDP. Именно поэтому оно не учитывается, когда для определенного вида медиа (m) находится дополнительное поле c. Можно добавить в места, где точно оперделена переменная c поставить вывод этого значения в консоль *. И там уже анализировать, правильно ли выбирается это значение и почему.
На первый взгляд, логика обработки полей SDP верная. Но может быть я чего-то не вижу Smile
#12
мне почему то казалось что в данном случае вторая с толжна идти в паре с "m=image 0 udptl t38 " толь тут уже тип не звука, не видео.
#13
посмтрите RFC сразу все станет понятно.
а вот если это баг в астериске то можно и поправить.
_________________
нанотехнолигии в области Asterisk
#14
Полагаю действительно можно дописать в код обработку еще 1го класса медиа по аналошии с предыдущими. Работать будет по-пацански (RFC) и у вас все будет бегать Smile Все инструменты в коде для этого есть!
#15
Я думаю это ни к чему... Хотя может пригодиться в будущем... а теперь и больного на костыли поставить...
т.е. как понимаю есть 2 решения.
1. это на уровне фарвола
2. на уровне кода.

Я пожалуй второй выберу...
#16
Я решил эту проблему, установив на шлюз sip-proxy (siproxd).
#17
А я бы поставил какой-нить шлюз, который тоже не работает в таком режиме, и взял бы оператора за причинное место, чтоб сделал как надо.
#18
Не получится. У Уралсвязьинформа есть список рекомендованного оборудования, а на все остальное им наплевать.
#19
Это точно. Open Source решения они называют не сертифицированные в России и даже не хотят вникать в проблемы.
А продвигают свои бренды. В общем сговор телекома и поставщиков.