Многоадресный пейджинг

[mvt]

Мне кажется Вы не правильно поняли о чём идёт речь и что в итоге должно получиться.
Ещё раз:
1. У меня нет задачи организовать вещание для определённой группы адресов (в данном случае 239.0.0.1) с сервера, в том числе того на котором установлен asterisk для клиентов asterisk, их конечных точек (телефонов).
Такое вещание можно организовать сторонним приложением (сервером) на вышеуказанный ip-адрес, а что это будет - видео или аудио не важно.
2. Есть задача при звонке на определённый номер передать свой голос на другой телефон, который слушает адрес MulticastRTP/basic/239.0.0.1:1236, сообщить информацию и отключиться.
При этом никакое стороннее приложение в виде сервера трансляции потока RTP на машине где установлен asterisk не запускается, оно не нужно.
Все организовывается автоматическим созданием конференции, и мостов в неё путём использования приложения Page, и, если я правильно понял идею из книги, когда механизмы конференцсвязи приложением Page инициализированы и используются, в этом случае у всех кто прослушивает адрес многоадресного прослушивания, например, MulticastRTP/basic/239.0.0.1:1236, должен включиться динамик телефона и они должны услышать голос человека желающего сообщить им необходимую информацию.
И, приложение Page отрабатывает, но udp трафик до второго телефона не проходит.
Не думаю, что если бы для этого сервиса нужно было бы запустить отдельную трансляцию с сервера asterisk сторонним приложением в книжке про это бы не указали.

А, так, спасибо я почитал, не всё, конечно, запомнил, но идея понятна.

[mvt]

И, вот что происходит при звонке на номер 730

30 27.414554287 10.8.1.3 10.8.1.1 IPv4 1500 Fragmented IP protocol (proto=UDP 17, off=0, ID=a77c) [Reassembled in #31]
31 27.416218616 10.8.1.3 10.8.1.1 SIP/SDP 27 Request: INVITE sip:730@10.8.1.1 |
32 27.547303939 10.8.1.1 10.8.1.3 SIP 342 Status: 100 Trying |
33 29.200001175 10.8.1.1 10.8.1.3 SIP/SDP 949 Status: 200 OK |
34 29.224019117 10.8.1.3 10.8.1.1 SIP 598 Request: ACK sip:10.8.1.1:5060 |
35 29.377348430 10.8.1.3 10.8.1.1 RTP 60 PT=ITU-T G.729, SSRC=0x3742FD7F, Seq=28942, Time=481872568, Mark
36 29.396734770 10.8.1.3 10.8.1.1 RTP 60 PT=ITU-T G.729, SSRC=0x3742FD7F, Seq=28943, Time=481872728
37 29.415730134 10.8.1.3 10.8.1.1 RTP 60 PT=ITU-T G.729, SSRC=0x3742FD7F, Seq=28944, Time=481872888
38 29.435201328 10.8.1.3 10.8.1.1 RTP 60 PT=ITU-T G.729, SSRC=0x3742FD7F, Seq=28945, Time=481873048

CLI>Executing [730@a_family_c8_28:2] Page("PJSIP/c074adb81338-0000000a", "MulticastRTP/basic/239.0.0.1:1236//c(ulaw),dir,120")
-- Called basic/239.0.0.1:1236//c(ulaw)
-- MulticastRTP/0x7f062c009930 answered
-- <PJSIP/c074adb81338-0000000a> Playing 'beep.g722' (language 'ru')
-- Channel CBAnn/866532406-0000000a;2 joined 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
== Begin MixMonitor Recording CBRec/866532406-0000000a
-- Channel CBRec/866532406-0000000a joined 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
-- Channel MulticastRTP/0x7f062c009930 joined 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
> 0x7f063803bd50 -- Strict RTP learning after remote address set to: 10.10.0.2:5012
> 0x7f063803bd50 -- Strict RTP qualifying stream type: audio
> 0x7f063803bd50 -- Strict RTP switching source address to 10.8.1.3:5012
-- Channel PJSIP/c074adb81338-0000000a joined 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
-- Channel PJSIP/c074adb81338-0000000a left 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
-- Channel MulticastRTP/0x7f062c009930 left 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
-- Channel CBRec/866532406-0000000a left 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
== MixMonitor close filestream (mixed)
== End MixMonitor Recording CBRec/866532406-0000000a
-- Channel CBAnn/866532406-0000000a;2 left 'softmix' base-bridge <f0291c32-f84a-4ce8-a771-2a9ad59c0486>
== Spawn extension (a_family_c8_28, 730, 2) exited non-zero on 'PJSIP/c074adb81338-0000000a'

[ded]

Я правильно понял о чём идёт речь и что в итоге должно получиться. Пейджинг и интерком - известная феатура. Для мгновенного голосового оповещения AFAIK, например, типа "Начальникам отделов, главному инженеру и главному бухгалтеоу через 15 минут собраться в конференц-зале №2". При этом у них у всех телефон включиться на громкую связь без всяких рингов, проговорит это и отключится. Не требовалось для этого никакое стороннее приложение в виде сервера трансляции потока RTP.
Для этого телефоны должны уметь
а) Autoanswer и делать это не на все звонки, по соотв. Caller ID или протоколу multicast;
b) слушать соотв. мультикаст ИП адрес (239.0.0.1:1236).
Интерком попроще, там такая связь только между двумя телефонами - начальник/секретарша.
Адреса
10.10.0.2
10.8.1.1
10.8.1.3
из приведённого дебага не находятся в одном широковещательном домене (подсети). Если только у них у всех не установлена маска 255.0.0.0 (или в CIDR - /8 ).

[mvt]

Не претендую на абсолютное знание, но для меня сомнительно, что само по себе не нахождение ip адресов 10.10.0.2 и 10.8.1.1, 10.8.1.3 в одном широковещательном диапазоне негативно влияет на прохождение udp пакета многоадресной рассылки.
Но, я полностью отключил openVPN и снова набрал номер 730, результат такой же (отрицательный), достучаться на второй телефон не получается, хотя по-существу, сейчас-то ничего не мешает, по крайней мере несовпадение широковещательного диапазона.
Поэтому, полагаю что причина где-то глубоко закопана... в другом месте.

Executing [730@a_family_c8_28:2] Page("PJSIP/c074adb81338-00000004", "MulticastRTP/basic/239.0.0.1:1236,dir,120")
-- Called basic/239.0.0.1:1236
-- MulticastRTP/0x7f0f30008b20 answered
-- Channel CBAnn/495404967-00000000;2 joined 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
-- Channel CBRec/495404967-00000000 joined 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
-- Channel MulticastRTP/0x7f0f30008b20 joined 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
== Begin MixMonitor Recording CBRec/495404967-00000000
-- <PJSIP/c074adb81338-00000004> Playing 'beep.g722' (language 'ru')
> 0x7f0ed013e8e0 -- Strict RTP learning after remote address set to: 10.10.0.2:5008
> 0x7f0ed013e8e0 -- Strict RTP switching to RTP target address 10.10.0.2:5008 as source
-- Channel PJSIP/c074adb81338-00000004 joined 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
> 0x7f0ed013e8e0 -- Strict RTP learning complete - Locking on source address 10.10.0.2:5008
-- Channel PJSIP/c074adb81338-00000004 left 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
-- Channel MulticastRTP/0x7f0f30008b20 left 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
-- Channel CBRec/495404967-00000000 left 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
== MixMonitor close filestream (mixed)
== End MixMonitor Recording CBRec/495404967-00000000
-- Channel CBAnn/495404967-00000000;2 left 'softmix' base-bridge <8f1d3b6f-11a3-4fdb-8b09-a12902a92337>
== Spawn extension (a_family_c8_28, 730, 2) exited non-zero on 'PJSIP/c074adb81338-00000004'

А, wireshark показывает то же самое что и при включённом openVPN

6 4.509715652 10.10.0.2 10.10.0.1 SIP/SDP 1313 Request: INVITE sip:730@10.10.0.1 |
7 4.527030683 10.10.0.1 10.10.0.2 SIP 526 Status: 401 Unauthorized |
8 4.531558911 10.10.0.2 10.10.0.1 SIP 333 Request: ACK sip:730@10.10.0.1 |
9 4.539199797 10.10.0.2 10.10.0.1 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=c0c2) [Reassembled in #10]
10 4.539200052 10.10.0.2 10.10.0.1 SIP/SDP 105 Request: INVITE sip:730@10.10.0.1 |
11 4.561930681 10.10.0.1 10.10.0.2 SIP 352 Status: 100 Trying |
12 5.011429080 10.10.0.1 10.10.0.2 SIP/SDP 962 Status: 200 OK |
13 5.034395885 10.10.0.2 10.10.0.1 SIP 608 Request: ACK sip:10.10.0.1:5060 |
14 5.189409030 10.10.0.2 10.10.0.1 RTP 74 PT=ITU-T G.729, SSRC=0x613875D8, Seq=33106, Time=1651051267, Mark
15 5.202918290 10.10.0.1 10.10.0.2 RTP 74 PT=ITU-T G.729, SSRC=0x525191C8, Seq=10571, Time=160
16 5.207595491 10.10.0.2 10.10.0.1 RTP 74 PT=ITU-T G.729, SSRC=0x613875D8, Seq=33107, Time=1651051427

[ded]

Не видно как делается у вас вызов из диал-плана (тоже из Realtime?).

У нас нет опыта с Grandstream, используем Cisco phones..
В примерах для них есть специальная аппликация SIPCiscoPage, завязанная на параметре “Allow Auto Answer by Call-Info”, но как она работает с PJSIP - неизвестно. Типа так -

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

exten => 1234,1,SipAddHeader(Call-Info: <uri>\;answer-after=0)
exten => 1234,n,Page(PJSIP/SIPCiscoPage(730&741,om,ov(30)(224.0.1.1:5004//c(alaw))d(From ${CALLERID(number)}))

[mvt]

Был бы у меня Cisco я бы попробовал и приведённый Вами способ и те, что в книге расписаны:

1. На основе SIP:
exten => *729,1,Verbose(2,Paging to Cisco SPA sets, but not Cisco 79XX sets)
same => n,SIPAddHeader(Call-Info:\;answer-after=0) ; Телефоны Cisco SPA
same => n,Set(PageDevice=SIP/0004F2000000)
same => n,Page(${PageDevice},i)

2. На основе Multicast: (для аппаратов Cisco)
exten => *724,1,Page(MulticastRTP/linksys/239.0.0.1:1234/239.0.0.1:6061) ;(строка с учётом зоопарка телефонов разных производителей)

Проблема в том, что мне не известны в случае:
1. SIP - хидеры (заголовки) телефонов Grandstream

2. Multicast - я вынужден опираться на стандартную строку из книги: MulticastRTP/type/ip-address:port, то есть
exten => 730,1,Page(${MULCAST_GXP1100},dir,120) ;где MULCAST_GXP1100 это: /etc/asterisk/extensions.conf

[globals]
; Определение переменных для многоадресного пейджинга:
MULCAST_GXP1100=MulticastRTP/basic/239.0.0.1:1237//c(ulaw)

Что касается Realtime, да код вызова находится в таблице, результат я привёл выше.

Сегодня, после Вашего сообщения я удалил его из таблицы и внёс в extensions.conf
включил его в контекст:

[a_family_c8_28]
switch => Realtime/a_family_c8_28@family_ext_c8_28
;Включение в этот контекст других контекстов
include => multicast
include => balance_EtN
include => exit_to_EtN
include => parkedcalls

[multicast]
exten => 730,1,Page(${MULCAST_GXP1100},dir,120)

Ожидаемо, получил следующее:

Executing [730@a_family_c8_28:1] Page("PJSIP/c074adb81338-00000001", "MulticastRTP/basic/239.0.0.1:1237//c(ulaw),dir,120") in new stack
-- Called basic/239.0.0.1:1237//c(ulaw)
-- MulticastRTP/0x55fb65bca2f0 answered
-- <PJSIP/c074adb81338-00000001> Playing 'beep.g722' (language 'ru')
-- Channel CBAnn/128912758-00000001;2 joined 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
== Begin MixMonitor Recording CBRec/128912758-00000001
-- Channel CBRec/128912758-00000001 joined 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
-- Channel MulticastRTP/0x55fb65bca2f0 joined 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
> 0x7f34a4015430 -- Strict RTP learning after remote address set to: 10.10.0.2:5020
> 0x7f34a4015430 -- Strict RTP switching to RTP target address 10.10.0.2:5020 as source
-- Channel PJSIP/c074adb81338-00000001 joined 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
-- Channel PJSIP/c074adb81338-00000001 left 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
-- Channel MulticastRTP/0x55fb65bca2f0 left 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
-- Channel CBRec/128912758-00000001 left 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
== MixMonitor close filestream (mixed)
== End MixMonitor Recording CBRec/128912758-00000001
-- Channel CBAnn/128912758-00000001;2 left 'softmix' base-bridge <cfa3e40b-6106-46e2-b069-989f8cba4418>
== Spawn extension (a_family_c8_28, 730, 1) exited non-zero on 'PJSIP/c074adb81338-00000001'

То же самое, что было и в БД, таким образом Realtime, убедительно, негативного влияния в процесс не вносит.

Полагаю, что проблема кроется где-то здесь: MulticastRTP/basic/239.0.0.1:1237//c(ulaw)

P.S. не обращайте внимания на меняющийся порт (просто разные телефоны)

[ded]

*CLI> core show channeltypes
покажет, что такой channel MulticastRTP у вас есть.
Думаю надо пробовать использовать application SIPCiscoPage, исходя из названия - пробовать её использовать чере chan_sip вместо pjsip.

Проблема в том, что мне не известны в случае:
1. SIP - хидеры (заголовки) телефонов Grandstream

неверно сформулировано. Неизвестно поймут ли телефоны Grandstream переданный заголовок SIPAddHeader(Call-Info:\;answer-after=0).

Если пейдж-телефонов немного, то нет смысла заморачиваться с мультикастом. Его бы надо применять в случае опопвещения на кучу SIP-громкоговорителей по всему городу. Пробуйте упростить:
exten => *729,1,SIPAddHeader(Call-Info:\;answer-after=0)
exten => *729,n,Page(SIP/701&SIP/702&SIP/703,,5)
Оно так тоже работает.

Вы часом не в речном порту Пермь работаете? Мы там установили Астериск 15 лет назад, если не больше.

[mvt]

Нет, я для себя

[mvt]

core show channeltypes
Type Description Devicestate Presencestate Indications Transfer
------------- ------------- ------------- ------------- ------------- -------------
Recorder Bridge Media Recording Channel Driver no no yes no
Announcer Bridge Media Announcing Channel Driver no no yes no
CBAnn Conference Bridge Announcing Channel no no yes no
CBRec Conference Bridge Recording Channel no no no no
PJSIP PJSIP Channel Driver yes no yes yes
UnicastRTP Unicast RTP Media Channel Driver no no no no
MulticastRTP Multicast RTP Paging Channel Driver no no no no
OOH323 Objective Systems H323 Channel Driver no no yes no
Local Local Proxy Channel Driver yes no yes no
Surrogate Surrogate channel used to pull channel f no no no no

[ded]

Посмотрел в код приложения SIPCiscoPage, это тот же Page, но просто дополненный уже SIP-хидером Call-Info:;answer-after=0
Вполне себе работает, исправно сыпет RTP на два телефона одновременно:

same => n,SIPCiscoPage(2607&2780,ov(75)ad(From ${CALLERID(number)})))

-- Executing [*729@from-internal:2] SIPCiscoPage("IAX2/10.1.2.3:4569-15484", "101&102,ov(75)ad(From 123))")

Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026721, ts 025440, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009879, ts 025440, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026722, ts 025600, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009880, ts 025600, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026723, ts 025760, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009881, ts 025760, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026724, ts 025920, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009882, ts 025920, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026725, ts 026080, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009883, ts 026080, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026726, ts 026240, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009884, ts 026240, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026727, ts 026400, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009885, ts 026400, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026728, ts 026560, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009886, ts 026560, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026729, ts 026720, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009887, ts 026720, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026730, ts 026880, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009888, ts 026880, len 000160)
Sent RTP packet to 10.1.231.138:20480 (type 08, seq 026731, ts 027040, len 000160)
Sent RTP packet to 10.1.231.134:20480 (type 08, seq 009889, ts 027040, len 000160)