asterisk.ru

Asterisk 11.16.0 (FPBX-12.0.76.4)
Настроены два транка от разных провайдеров.
На одном провайдере городской номер, на другом 8-800 от mcn.ru Входящие и исходящие через другого провайдера работают без проблем. Через mcn.ru со входящим звонком тоже проблем нет.
Потребовалось добавить транк mcn.ru в Outbound, чтобы исходящие звонки были через mcn.ru И получилась проблема.
При изменении исходящих в "Оutbound Routes", указания транка на mcn.ru, делающий вызов на внешний телефон пользователь ничего не слышит в ответ. Внешний абонент слышит всё, а обратно к пользователю ничего.
Внимательно изучил схему решения проблемы. "Вау! Вызов пошёл". Да, пошёл. Да asterisk за nat. Да, все параметры выставлены (externip, localnet, nat). С другого провайдера нет никаких проблем со звонком в обе стороны.
Если поставить debug на trunk, то отличие при соединении через работающий транки и полуработающий от mcn.ru заключается в том, что в поле From нет имени пользователя. Через работающий транк так:

Код: Выделить всё

Audio is at 15224
Adding codec 100008 (g729) to SDP
Adding codec 100003 (ulaw) to SDP
Adding codec 100004 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 111.111.11.111:5060:
INVITE sip:11111111111@2222222222.domen.ru:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 222.222.222.222:5060;branch=60fE3bL34b35a8e;rport
Max-Forwards: 70
From: "SEM" <sip:11111111111@2222222222.domen.ru>;tag=as2296e1d6
To: <sip:11111111111@2222222222.domen.ru:5060;user=phone>
Contact: <sip:11111111111@222.222.222.222:5060>
Call-ID: xxxx5afa04e949cdef2a@2222222222.domen.ru
CSeq: 103 INVITE
User-Agent: FPBX-12.0.76.4(11.16.0)
Proxy-Authorization: Digest username="33333", realm="11111111111@222.222.222.222", algorithm=MD5, uri="sip:11111111111@2222222222.domen.ru:5060;user=phone", nonce="xxx-4925-a08e-02737f22ab80", response="438cf30eef44ffa1f698", qop=auth, cnonce="3dbe1121", nc=00000001
Date: Thu, 19 Jan 2017 22:03:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 311

Выше во "From" есть пользователь:

Код: Выделить всё

[xxxxx]
deny=0.0.0.0/0.0.0.0
secret=xxxxxxx
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
mediaencryption=no
sendrpid=no
type=friend
nat=force_rport,comedia
port=5060
qualify=yes
qualifyfreq=60
transport=udp,tcp,tls
avpf=no
force_avp=no
icesupport=no
encryption=no
callgroup=
pickupgroup=
dial=SIP/xxxxx
permit=0.0.0.0/0.0.0.0
callerid=SEM <xxxxx>
callcounter=yes
faxdetect=no

Но как только я поменяю trunk на mcn, то debug по trunk такой:

Код: Выделить всё

Audio is at 15500
Adding codec 100008 (g729) to SDP
Adding codec 100004 (alaw) to SDP
Adding codec 100003 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to xx.xx.xx.xxx:5060:
INVITE sip:11111111111@sip.mcn.ru:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 222.222.222.222:5060;branch=60fE3bL34b35a8e;rport
Max-Forwards: 70
From: <sip:xxxxxxxx@sip.mcn.ru>;tag=as37202412
To: <sip:11111111111@sip.mcn.ru:5060;user=phone>
Contact: <sip:xxxxxxxx@222.222.222.222:5060>
Call-ID: 3333xxxxxxxxxxec000ee5666@sip.mcn.ru
CSeq: 103 INVITE
User-Agent: FPBX-12.0.76.4(11.16.0)
Authorization: Digest username="xxxxxxxx", realm="mcn", algorithm=MD5, uri="sip:11111111111@sip.mcn.ru:5060;user=phone", nonce="206a1r87", response="sssssss0uuuuuu653cab1d03333333"
Date: Thu, 19 Jan 2017 22:24:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 311

v=0
o=root 2038298311 2038298312 IN IP4 222.22.222.222
s=Asterisk PBX 11.16.0
c=IN IP4 222.22.222.222
t=0 0
m=audio 15500 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Вызов на внешний телефон (мой мобильный, для пробы) есть. В мобильном всё слышно, но обратно - нет. В поле "From" нет пользователя "SEM".
PEER Details (для mcn):

Код: Выделить всё

[MCN]
disallow=all
host=sip.mcn.ru
username=xxxxxxxx
secret=**********
fromdomain=sip.mcn.ru
port=5060
usereqphone=yes
fromuser=xxxxxxxx
insecure=invite
type=friend
context=from-trunk
qualify=yes
allow=alaw,ulaw,g729

Не подскажете почему может возникнуть такая проблема?

Проблема не в поле From

+1 к awsswa, ибо про From чушь

Во-первых, не понятно, а 222.22.222.222 это там действительно реальник ? Или вы так внутренний ип замаскировали ?
Во-вторых, при проблемах с голосом нужно две вещи:

- убрать разнообразие кодеков и оставить ОДИН, например alaw
- взять в руки tcpdump и записать оба плеча а) пользователь - астрериск, б) астериск - провайдер и проанализировать в wireshark`е

Что было в SDP ? Какие адреса, какие порты ? Эти порты не закрыты ?
Что с RTP ? Откуда получали ? Откуда не получали ?
и т.п.

sem, проблема односторонней слышимости не нова и не уникальна. Даже на этом ресурсе обсуждалась миллионы раз, а в Инете наверно миллиарды. Действия по решению проблемы всегда они и те же. Прочтите и выполните уже миллиарды раз написанное.

Здравствуйте. Спасибо, что отвечаете.
Все адреса вымышлены. Порты для работы asterisk-а открыты и работают.
Локальных сетей две (192.168.0/24, 10.7.7/24)
10.7.7.1 - VPN сервер, 10.7.7.145 - asterisk
И что я тут мог бы проанализировать:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: Сверху рабочий транк, снизу проблемный

Видно только, что по рабочему транку звук идёт туда-сюда, а на транке mcn.ru - только наружу, не считая одного "прорвавшегося" пакета. Я об этом и говорю - наружу есть, обратно глухо.
Вот проблемное соединение:

Код: Выделить всё

    -- Executing [s@macro-dialout-trunk:22] Dial("SIP/999-0000001c", "SIP/MCN/ххххххххххх,300,Tt") in new stack
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
    -- Called SIP/MCN/ххххххххххх
    -- SIP/MCN-0000001d is making progress passing it to SIP/999-0000001c
    -- SIP/MCN-0000001d is ringing
    -- SIP/MCN-0000001d answered SIP/999-0000001c
    -- fixed jitterbuffer created on channel SIP/MCN-0000001d
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/999-0000001c", "hangupcall,") in new stack

а вот хорошее соединение на другом транке:

Код: Выделить всё

    -- Executing [s@macro-dialout-trunk:22] Dial("SIP/999-00000020", "SIP/worktrunk/ххххххххххх,300,Tt") in new stack
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
    -- Called SIP/worktrunk/ххххххххххх
    -- SIP/worktrunk-00000021 is making progress passing it to SIP/999-00000020
    -- SIP/worktrunk-00000021 answered SIP/999-00000020
    -- fixed jitterbuffer created on channel SIP/999-00000020
    -- fixed jitterbuffer created on channel SIP/worktrunk-00000021
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/999-00000020", "hangupcall,") in new stack

Чтоб одно на другое было похоже, то на полурабочем транке при снятии внешней трубки (на вызываемом телефоне) отсутствует, наверное, вот это:

Код: Выделить всё

    -- fixed jitterbuffer created on channel SIP/999-0000001c

Если бы не это отсутствие, то всё один в один. А что значит эта строка я не знаю. "Библию" сегодня опять перелистал, нет там ничего про это. Что это такое вообще? На что влияет, откуда происходит и как бы так сделать, чтобы было?

По поводу RTP. Так по worktrunk:

Код: Выделить всё

Sent RTP packet to      333.333.333.333:22024 (type 00, seq 042853, ts 2596870912, len 000160)
Got  RTP packet from    333.333.333.333:22024 (type 00, seq 034322, ts 2986194208, len 000160)
Sent RTP packet to      10.7.7.1:11430 (type 08, seq 006957, ts 2986192608, len 000160)
Got  RTP packet from    10.7.7.1:11430 (type 08, seq 021211, ts 2596872672, len 000160)
Sent RTP packet to      333.333.333.333:22024 (type 00, seq 042854, ts 2596871072, len 000160)
Sent RTP packet to      10.7.7.1:11430 (type 08, seq 006958, ts 2986192768, len 000160)
Got  RTP packet from    333.333.333.333:22024 (type 00, seq 034323, ts 2986194368, len 000160)

"односторонний" mcn.ru так и есть - выдаёт наружу, обратно не выдаёт:

Код: Выделить всё

Sent RTP packet to      85.94.32.218:60052 (type 08, seq 062903, ts 2598466096, len 000160)
Got  RTP packet from    10.7.7.1:13360 (type 08, seq 019401, ts 2598467861, len 000160)
Sent RTP packet to      85.94.32.218:60052 (type 08, seq 062904, ts 2598466256, len 000160)
Got  RTP packet from    10.7.7.1:13360 (type 08, seq 019402, ts 2598468021, len 000160)
Sent RTP packet to      85.94.32.218:60052 (type 08, seq 062905, ts 2598466416, len 000160)
Got  RTP packet from    10.7.7.1:13360 (type 08, seq 019403, ts 2598468181, len 000160)

Визуально вся эта неприятность выглядит, например, на софтофоне (bria) следующим образом.
На рабочем транке, как только вызываемый снимает трубку, так сразу "Peer IP" меняется с 0.0.0.0 на адрес интерфейса asterisk-а:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: worktrunk

А на полурабочем для mcn.ru не меняется, так и остаётся 0.0.0.0, пакеты идут только наружу, обратно - глухо:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: MCN

Спросил в сапорте mcn.ru, мол, а если телефон за фаерволом, то какие порты нужны для RTP? Мне ответили так, что для них 10000-20000 маловато будет и надо 1024-65535 udp разрешить для их sip.mcn.ru в обе стороны. Ну, да и бог бы с ним! Хотя, это как-то странно, так как от них RTP идёт на asterisk в пределах 10-20т/udp. Открыл все порты udp, начиная с 1024. Картина такая же.
Куда бы мне ещё посмотреть? Помогите, пожалуйста.

Думаете здесь кому-то интересно копаться в куче "вымышленных адресов"? Сами себя загнали в угол..
Какой-то VPN вырисовался, замазки и внутренних подсетей..

Платный саппорт, у Вас же всё секретно)))))

[xxxxx]

Диагноз..

Рецепт для секретчика: ставите X-lite на комп, транк этот регите на него БЕЗ Asterisk. Проверяете ходят ли наружу звонки. С помощью Wireshark записываете его. Ставите на Asterisk транк и добиваетесь АНАЛОГИЧНЫХ заголовков в INVITE.

Что есть NAT у Вас, что за зверь его делает?

Передайте в сапорт mcn.ru: "Настраиваем присоединения ваших клиентов, аутсорсинг, двойной тариф, предоплата 100%"

Здравствуйте. Думаю, что абсолютно никому не интересно "копаться". Другое дело, что желающих позвонить в мире так много, что... Ну, о-очень много. И что же? Пригласить ещё желающих? Опубликовать на весь мир откуда, куда и как надо позвонить?
Продвинутые в области телефонии граждане прут потоком. А я, разумеется, ещё не на столько продвинут, чтобы грамотно этой толпе халявщиков что-нибудь противопоставить, вот и мажу что ни попадя.
Платный сапорт? В конце концов, почему бы и нет. Если единственный выход "для секретчика" "ставить ещё один софтовон", хотя их уже есть (с.м. сообщение выше), а перед этим надо найти где-нибудь свободный статический адрес, чтобы не отключать всё уже работающее, то придётся воспользоваться этим единственным выходом. Вы не могли бы порекомендовать к кому можно обратиться?
У меня NAT - это трансляция сетевых адресов, делает его маршрутизатор. По рекомендуемой схеме выявления недостатков я смотрю сессии соединений с компьютера, где установлен FreePBX, и вижу, что и входящие, и исходящие проходит. Некоторые события мне непонятны. Спрашиваю.
На проблемном транке после "Status-Line: SIP/2.0 100 Trying" и "Status-Line: SIP/2.0 183 Session Progress" возникает "Status-Line: SIP/2.0 180 Ringing" Из-за чего это происходит?
А в заголовках INVITE что на проблемном транке, что на рабочем - заголовки одинаковые. Там разнообразия нет.

ded писал(а):Передайте в сапорт mcn.ru: "Настраиваем присоединения ваших клиентов, аутсорсинг, двойной тариф, предоплата 100%"

Бизнес по-русски, называется. Если мне кто-нибудь поможет, то тариф у меня = нулю. Двойной тариф - 2 умножить на ноль = сумашедшая сумма!

Уважаемые знатоки! Пожалуйста, подскажите что-нибудь по поводу выше заданных вопросов. Пока их два:
почему на проблемном транке нет:

Код: Выделить всё

-- fixed jitterbuffer created on channel SIP/999-0000001c

что есть на рабочем? Или это не существенно, как с "From"?
И почему на проблемном транке при вызове странный (для меня)

Код: Выделить всё

"Status-Line: SIP/2.0 180 Ringing"

? Или это тоже никакой роли в разрешении проблемы не сыграет?
Если все различия, найденные мною, не играют ни малейшего значения, то на что можно ещё обратить внимание? Пакеты RTP поступают обратно, они есть. Но что может происходить в недрах asterisk я не понимаю. Нужны варианты, из вашего опыта, пожалуйста.
Могу оплатить ваши услуги, если договоримся. Тему новую в "бизнесе" надо открывать?
Я тут уже одному умельцу с авито по объявлению звякнул, объяснил практически как здесь. Человек отказался. Он не хочет возиться с "кастомными", как он выразился, конфигурациями. Хотя у меня "кастомов" никаких нет, не продвинулся ещё до кастомов.

И почему на проблемном транке при вызове странный (для меня)

Код: выделить все
"Status-Line: SIP/2.0 180 Ringing"

? Или это тоже никакой роли в разрешении проблемы не сыграет?

Для начала вдумайтесь: при чем сигнализация о идущем дозвоне и ... дальшейшее RTP после соединения. Вы все смешали в одну кучу, а не анализируете путем логики и последовательности.

Даже заголовок - "два ОДИНАКОВЫХ транка" - что значит одинаковые если от разных провов?

asterisk.ru

Два одинаковых транка. На одном проблема.

Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.

Re: Два одинаковых транка. На одном проблема.