Context Navigation

← Previous Ticket
Next Ticket →

#476 closed баг (invalid)

Проблема с вызовом всех операторов в диспетчерскую конференцию

Reported by:	roman_zhur	Owned by:	alx
Priority:	средний	Milestone:	2 очередь
Component:	any	Keywords:
Cc:

Description

окончания DS регистрируются на VE-02 на стороне диспетчера.
VE-02 - диспетчерская - 192.168.20.40
VE-01 - операторская - 192.168.20.50
VE-01 - операторская - 192.168.20.60

Эксперимент:

с телефона диспетчера (disp@) вызываем окончание PPS диспетчера 1@ в конференцию с помощью рег. выражение вызова и автоматического вызова по номеру "01".
окончание PPS попадает в конференцию, отправляет DTMF A в групповой канал.
операторское окончание DS (2@ и 3@) вызывает окончание FXS (op2@ и op3@) в конференцию.
первый поднявший трубку оператор подключается к конференции и может говорить с диспетчером.

второй поднявший трубку оператор получает 480 Temporarily Unavailable и отбивается.

Ожидалось, что второй оператор после снятия трубки попадёт в конференцию и сможет общаться.

tcpdump_20.40.txt, messages_20.40.txt - tcpdump и лог с VE-02 диспетчера
tcpdump_20.50.txt, messages_20.50.txt - tcpdump и лог с VE-01 оператора 2@
tcpdump_20.60.txt, messages_20.60.txt - tcpdump и лог с VE-01 оператора 3@

Attachments (7)

messages_20.40.txt (17.8 KB ) - added by roman_zhur 22 hours ago.
messages_20.50.txt (9.4 KB ) - added by roman_zhur 22 hours ago.
messages_20.60.txt (8.3 KB ) - added by roman_zhur 22 hours ago.
tcpdump_20.40.txt (42.2 KB ) - added by roman_zhur 22 hours ago.
tcpdump_20.50.txt (28.3 KB ) - added by roman_zhur 22 hours ago.
tcpdump_20.60.txt (24.2 KB ) - added by roman_zhur 22 hours ago.
ss1.jpg (157.4 KB ) - added by alx 16 hours ago.

Download all attachments as: .zip

Change History (27)

by roman_zhur, 22 hours ago

Attachment:	messages_20.40.txt added

by roman_zhur, 22 hours ago

Attachment:	messages_20.50.txt added

by roman_zhur, 22 hours ago

Attachment:	messages_20.60.txt added

by roman_zhur, 22 hours ago

Attachment:	tcpdump_20.40.txt added

by roman_zhur, 22 hours ago

Attachment:	tcpdump_20.50.txt added

by roman_zhur, 22 hours ago

Attachment:	tcpdump_20.60.txt added

in reply to: description ; follow-up: 3 comment:1 by alx, 21 hours ago

Replying to roman_zhur:

Прочитал описание эксперимента, и у меня возник ряд вопросов. Не очень понятно, что ты делал и почему.

окончания DS регистрируются на VE-02 на стороне диспетчера.

Во-первых, непонятно, почему оно регистрируется на VE-02. Канальное окончание DS должно регистрироваться на сервере диспетчерской связи.

Эксперимент:

с телефона диспетчера (disp@) вызываем окончание PPS диспетчера 1@ в конференцию с помощью рег. выражение вызова и автоматического вызова по номеру "01".

Почему и зачем диспетчер вызывает собстченное канальное окончание PPS? Он собирается с ним поговорить? :) Мне казалось, что диспетчер работает (разговаривает) с операторами и, следовательно, он должен вызывать операторов, а не канальные окончания. О том, что где-то там есть какие-то каналы с окончаниями, по идее, диспетчер даже не должен знать...

операторское окончание DS (2@ и 3@) вызывает окончание FXS (op2@ и op3@) в конференцию.

Непонятно, для чего в этой схеме канальное окончание FXS. Что оно там делает? Изучи, пожалуйста, вот эту статью, и в особенности обрати внимание на самый первый рисунок - там показано, как должно быть организовано подключение операторов к серверу диспетчерской связи с передачей речи по групповому каналу TDM вместо сети IP (для чего и было создано окончание DS). Как ты можешь видеть, там нет никаких окончаний FXS. Там одно окончание PPS (в точке подключения канала к серверу конференций) и окончания DS (по одному на каждого оператора ГРС).

первый поднявший трубку оператор подключается к конференции и может говорить с диспетчером.
второй поднявший трубку оператор получает 480 Temporarily Unavailable и отбивается.

Ожидалось, что второй оператор после снятия трубки попадёт в конференцию и сможет общаться.

Есть подозрение, что твое ожидание ошибочно, так как схема связи, которую ты собрал, отличается от схемы использования канальных окончаний DS. Собери, пожалуйста, схему в точном соответствии с рисунком в описании канального окончания DS и повтори свой эксперимент. Либо опиши подробно как по-твоему собранная тобой схема должна работать (подробно, по шагам опиши, что должно происходить: какие сообщения, какие сигналы откуда куда должны передаваться и т.п.) - иными словами, обоснуй, пожалуйста, свое ожидание. Я из описания тикета не понимаю, что за схему ты собрал, и как она должна (или не должна) работать...

tcpdump_20.40.txt, messages_20.40.txt - tcpdump и лог с VE-02 диспетчера
tcpdump_20.50.txt, messages_20.50.txt - tcpdump и лог с VE-01 оператора 2@
tcpdump_20.60.txt, messages_20.60.txt - tcpdump и лог с VE-01 оператора 3@

Я, конечно, могу посмотреть эти дампы, но для этого уточни, пожалуйста, как минимум, кто такой "первый оператор", и кто такой "второй оператор" (укажи их адреса), чтобы я мог найти и опознать их в приложенных дампах.

follow-up: 4 comment:2 by roman_zhur, 19 hours ago

Канальное окончание DS должно регистрироваться на сервере диспетчерской связи.

VE-02 - диспетчерская. На ней и настроена конференция, и регистрируются DS. VE-02 является сервером диспетчерской связи.

Почему и зачем диспетчер вызывает собстченное канальное окончание PPS?

Цитата из раздела "Вызов диспетчером всех абонентов группового канала" из статьи, которую ты рекомендовал прочитать: "Вызов всех абонентов группового канала в конференцию выполняется путем подключения к конференции "диспетчерского" канального окончания PPS." Именно это я и делаю.

Непонятно, для чего в этой схеме канальное окончание FXS.

Переформулирую третий пункт как "3. Операторское окончание DS (2@ и 3@) вызывается в конференцию."

Первый оператор - 2@192.168.20.40, URI телефонного аппарата абонента - op2@192.168.20.50
Второй оператор - 3@192.168.20.40, URI телефонного аппарата абонента - op3@192.168.20.60

in reply to: 1 comment:3 by alx, 19 hours ago

Replying to alx:

Почему и зачем диспетчер вызывает собстченное канальное окончание PPS?

Этот вопрос снимается. Я забыл, что таким "хитрым" (и немного странным) образом у нас выполняется вызов всех операторов группового канала. :)

in reply to: 2 ; follow-ups: 5 7 comment:4 by alx, 18 hours ago

Replying to roman_zhur:

VE-02 - диспетчерская. На ней и настроена конференция, и регистрируются DS.

А, кажется я понял. Используется так называемая "диспетчерская для бедных", когда вместо сервера диспетчерской связи используется плата VE-01 (в данном случае VE-02) с настроенными в ней статическими конференциями, а вместо пульта диспетчера - просто телефонный аппарат.

VE-02 является сервером диспетчерской связи.

Нет. Сервер диспетчерской связи - это MC04-Softswitch, представляющий собой немного модифицированный FreeSwitch. Но иногда пользьватели из соображений экономии вместо сервера диспетчерской связи MC04-Softswitch используют плату VE-01 (хотя по моим подсчетам это какая-то копеечная экномия получается). @san называет такое использование "диспетчерская для бедных". :)

Почему и зачем диспетчер вызывает собстченное канальное окончание PPS?

Цитата из раздела "Вызов диспетчером всех абонентов группового канала" из статьи, которую ты рекомендовал прочитать: "Вызов всех абонентов группового канала в конференцию выполняется путем подключения к конференции "диспетчерского" канального окончания PPS."

Да, спасибо, с этим вопросом я уже сам разобрался.

Непонятно, для чего в этой схеме канальное окончание FXS.

Переформулирую третий пункт как "3. Операторское окончание DS (2@ и 3@) вызывается в конференцию."

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

Первый оператор - 2@192.168.20.40, URI телефонного аппарата абонента - op2@192.168.20.50
Второй оператор - 3@192.168.20.40, URI телефонного аппарата абонента - op3@192.168.20.60

Спасибо за уточнение, хотя я его не до конца понял. То есть телефон второго оператора (который получает "480 Temporarily Unavailable") имеет адрес 192.168.20.60. Я правильно понял? Не понятно, что тогда такое "3@192.168.20.40".

in reply to: 4 comment:5 by alx, 18 hours ago

Replying to alx:

Не понятно, что тогда такое "3@192.168.20.40".

А, кажется я догадался: это наверное URI, с которым он регистрируется на плате VE-02...

follow-up: 8 comment:6 by roman_zhur, 18 hours ago

То есть телефон второго оператора (который получает "480 Temporarily Unavailable") имеет адрес 192.168.20.60. Я правильно понял?

Да.

Не понятно, что тогда такое "3@192.168.20.40".

Это SIP URI канального окончания DS.

in reply to: 4 comment:7 by alx, 18 hours ago

Replying to alx:

То есть телефон второго оператора (который получает "480 Temporarily Unavailable") имеет адрес 192.168.20.60. Я правильно понял?

Видимо, неправильно - в описании тикета написано, что 192.168.20.60 - это адрес платы VE-01. Вопрос остается открытым...

in reply to: 6 comment:8 by alx, 18 hours ago

Replying to roman_zhur:

То есть телефон второго оператора (который получает "480 Temporarily Unavailable") имеет адрес 192.168.20.60. Я правильно понял?

Да.

??? Это противоречит написанному в описании тикета: "VE-01 - операторская - 192.168.20.60"!

follow-up: 10 comment:9 by roman_zhur, 18 hours ago

Почему противоречит?
На VE-01 с адресом 192.168.20.60 есть два канальных окончания: первое - DS c URI 3@192.168.20.40, второе - FXS с URI op3@192.168.20.60

in reply to: 9 comment:10 by alx, 18 hours ago

Replying to roman_zhur:

Почему противоречит?

Потому что тогда получается, что и плата VE-01, и телефон оператора оба имеют один и тот же адрес. Я не допускаю мысли, что ты мог назначить двум устройствам один и тот же адрес - ты по-моему достаточно квалифицировнный сепциалист чтобы понимать, что адреса устройств в сети должны быть уникальными, иначе такая сеть нормально работать не будет. :)

На VE-01 с адресом 192.168.20.60 есть два канальных окончания: первое - DS c URI 3@192.168.20.40, второе - FXS с URI op3@192.168.20.60

Я в comment:1 просил уточнить не адрес платы VE-01, и не URI канального окончания FXS (которое вообще не должно использоваться в данной схеме). Я просил уточнить адреса телефонных аппаратов операторов.

Last edited 18 hours ago by alx (previous) (diff)

follow-up: 12 comment:11 by roman_zhur, 18 hours ago

В схеме используются аналоговые телефоны

in reply to: 11 ; follow-up: 13 comment:12 by alx, 18 hours ago

Replying to roman_zhur:

В схеме используются аналоговые телефоны

О, вот это существенное уточнение, спасибо. Теперь кажется становится понятнее... Верно ли я теперь догадался, что этот аналоговый телефонный аппарат подключен к плате PD-04 или FS-08, которая соединена по каналу TDM с канальным окончанием FXS платы VE-01, используемым вместо телефонного аппарата оператора ГРС?

Когда используется нетиповая схема включения, лучше сразу говорить об отличиях от типовой схемы, не ждать когда я сам догадаюсь (а еще лучше сразу описать используемую схему, независимо от того, типовая она или нет). Это типа пожелание на будущее... :)

in reply to: 12 comment:13 by roman_zhur, 17 hours ago

О, вот это существенное уточнение, спасибо. Теперь кажется становится понятнее... Верно ли я теперь догадался, что этот аналоговый телефонный аппарат подключен к плате PD-04 или FS-08, которая соединена по каналу TDM с канальным окончанием FXS платы VE-01, используемым вместо телефонного аппарата оператора ГРС?

Да

comment:14 by alx, 17 hours ago

Хорошо. Тогда попробую проанализировать приложенный дамп tcpdump_20.60.txt. Вычленю из него вызов телефона второго оператора (как его видел бы настоящий IP телефон оператора):

06:28:17.004128 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1479)
    localhost..5060 > localhost..6060: SIP, length: 1451
        INVITE sip:op3@127.0.0.1:6060;transport=udp SIP/2.0
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---bf0924550c29b502;rport
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1830764452
        Max-Forwards: 69
        Record-Route: <sip:192.168.20.60:5060;transport=udp;lr>
        Contact: <sip:00@127.0.0.1:6060>
        To: <sip:op3@192.168.20.60>
        From: <sip:00@192.168.20.40>;tag=554232430
        Call-ID: 1027022968
        CSeq: 20 INVITE
        Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK, SUBSCRIBE
        Content-Type: application/sdp
        Supported: replaces, timer, 100rel
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        X-Endpoint-Type: DS
        X-Secure-Transport: yes
        Content-Length: 750

        v=0
        o=gateway 0 17 IN IP4 192.168.20.60
        s=conversation
        c=IN IP4 192.168.20.60
        t=0 0
        m=audio 10004 RTP/SAVP 8 0 4 18 101 13 98
        a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:I8pVb9bcUeTx0SxqZcNPQVMzGbiDy/AoFnbTXnLv
        a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:mgkH1Upzb65/2b59IM4YIxY7WjbmP5hcmZjUibpz
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:4 G723/8000
        a=rtpmap:18 G729/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=rtpmap:13 CN/8000
        a=rtpmap:98 PCMA/8000
        a=gpmd:98 vbd=yes
        m=audio 10004 RTP/AVP 8 0 4 18 101 13 98
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:4 G723/8000
        a=rtpmap:18 G729/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=rtpmap:13 CN/8000
        a=rtpmap:98 PCMA/8000
        a=gpmd:98 vbd=yes
06:28:17.014199 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 362)
    localhost..6060 > localhost..5060: SIP, length: 334
        SIP/2.0 100 Trying
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---bf0924550c29b502;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1830764452
        From: <sip:00@192.168.20.40>;tag=554232430
        To: <sip:op3@192.168.20.60>
        Call-ID: 1027022968
        CSeq: 20 INVITE
        User-Agent: eXosip/5.3.0
        Content-Length: 0

06:28:17.059695 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 683)
    localhost..6060 > localhost..5060: SIP, length: 655
        SIP/2.0 180 Ringing
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---bf0924550c29b502;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1830764452
        Record-Route: <sip:192.168.20.60:5060;transport=udp;lr>
        From: <sip:00@192.168.20.40>;tag=554232430
        To: <sip:op3@192.168.20.60>;tag=1817180611
        Call-ID: 1027022968
        CSeq: 20 INVITE
        Contact: <sip:op3@127.0.0.1:6060>
        Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,INFO,UPDATE,PRACK,SUBSCRIBE
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        Supported: replaces,timer,100rel
        P-Asserted-Identity: <sip:op3@192.168.20.60>
        Require: 100rel
        RSeq: 100
        Content-Length: 0

06:28:17.116951 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 462)
    localhost..5060 > localhost..6060: SIP, length: 434
        PRACK sip:op3@127.0.0.1:6060 SIP/2.0
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---7150d9256623871a;rport
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1772458070
        Max-Forwards: 69
        Contact: <sip:00@127.0.0.1:6060>
        To: <sip:op3@192.168.20.60>;tag=1817180611
        From: <sip:00@192.168.20.40>;tag=554232430
        Call-ID: 1027022968
        CSeq: 21 PRACK
        User-Agent: eXosip/5.3.0
        RAck: 100 20 INVITE
        Content-Length: 0

06:28:17.127958 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 614)
    localhost..6060 > localhost..5060: SIP, length: 586
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---7150d9256623871a;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1772458070
        From: <sip:00@192.168.20.40>;tag=554232430
        To: <sip:op3@192.168.20.60>;tag=1817180611
        Call-ID: 1027022968
        CSeq: 21 PRACK
        Contact: <sip:op3@127.0.0.1:6060>
        Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,INFO,UPDATE,PRACK,SUBSCRIBE
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        Supported: replaces,timer,100rel
        X-Endpoint-Type: FXS
        P-Asserted-Identity: <sip:op3@192.168.20.60>
        Content-Length: 0

06:28:21.537147 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1102)
    localhost..6060 > localhost..5060: SIP, length: 1074
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---bf0924550c29b502;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1830764452
        Record-Route: <sip:192.168.20.60:5060;transport=udp;lr>
        From: <sip:00@192.168.20.40>;tag=554232430
        To: <sip:op3@192.168.20.60>;tag=1817180611
        Call-ID: 1027022968
        CSeq: 20 INVITE
        Contact: <sip:op3@127.0.0.1:6060>
        Content-Type: application/sdp
        Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,INFO,UPDATE,PRACK,SUBSCRIBE
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        Supported: replaces,timer,100rel
        X-Endpoint-Type: FXS
        P-Asserted-Identity: <sip:op3@192.168.20.60>
        Content-Length:   395

        v=0
        o=gateway 0 0 IN IP4 192.168.20.60
        s=conversation
        c=IN IP4 192.168.20.60
        t=0 0
        m=audio 10002 RTP/SAVP 8 101 13 98
        a=rtpmap:8 PCMA/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=rtpmap:13 CN/8000
        a=rtpmap:98 PCMA/8000
        a=gpmd:98 vbd=yes
        a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:zkZKsKgXv7LLI5fhh0qwaHHDq6AbjRj6KZPZKBFy
        a=sendrecv
        m=audio 0 RTP/AVP 8 0 4 18 101 13 98
06:28:21.585690 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 436)
    localhost..5060 > localhost..6060: SIP, length: 408
        ACK sip:op3@127.0.0.1:6060 SIP/2.0
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---29b7c8661ada0276;rport
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK180670483
        Max-Forwards: 69
        Contact: <sip:00@127.0.0.1:6060>
        To: <sip:op3@192.168.20.60>;tag=1817180611
        From: <sip:00@192.168.20.40>;tag=554232430
        Call-ID: 1027022968
        CSeq: 20 ACK
        User-Agent: eXosip/5.3.0
        Content-Length: 0

06:28:21.975679 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 402)
    localhost..5060 > localhost..6060: SIP, length: 374
        BYE sip:op3@127.0.0.1:6060 SIP/2.0
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---754f66774ef05a74;rport
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK632651689
        Max-Forwards: 69
        To: <sip:op3@192.168.20.60>;tag=1817180611
        From: <sip:00@192.168.20.40>;tag=554232430
        Call-ID: 1027022968
        CSeq: 22 BYE
        User-Agent: eXosip/5.3.0
        Content-Length: 0

06:28:21.980729 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 369)
    localhost..6060 > localhost..5060: SIP, length: 341
        SIP/2.0 200 OK
        Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---754f66774ef05a74;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK632651689
        From: <sip:00@192.168.20.40>;tag=554232430
        To: <sip:op3@192.168.20.60>;tag=1817180611
        Call-ID: 1027022968
        CSeq: 22 BYE
        User-Agent: eXosip/5.3.0
        Content-Length: 0

Что я виду в этом дампе:

В 06:28:17.004128 телефон оператор получает вызов.
Телефон оператора включает вызывной сигнал (ответ "180 Ringing").
В 06:28:21.537147 оператор ответил на вызов (ответ "200 OK").
Канальное окончание DS передает телефону ACK, и на этот момент соединение успешно установлено.
В 06:28:21.975679 канальное окончание DS прислало телефону BYE.
Телефон ответил "200 OK".

Чего я в дампе не увидел: телефон второго оператора не получал ответа "480 Temporarily Unavailable". Более того, телефон второго оператора вообще за весь сеанс связи не отправил ни одного запроса, поэтому он в принципе не мог получить никакого ответа - ни 480, ни какого бы то ни было другого.

Предполагаю, что в действительности "жалоба" тикета состоит в том, что оператор получил отбой сразу после установки соединения (хотя ожидалось, что оператор будет вести разговор). Далее попробую выяснить, почему канальное окончание DS отбило вызов...

comment:15 by alx, 16 hours ago

Как следует из описания (и видно на приведенной мной выше диаграмме), получив ответ оператора, канальное окончание DS выполняет "фальшивое" подключение к конференции (подключение без медиапотока) чтобы индицировать диспетчеру, что в конференции есть новый участник. Вот что я вижу в приложенном дампе tcpdump_20.60.txt:

06:28:21.805426 IP (tos 0x0, ttl 64, id 57935, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.20.60.5060 > 192.168.20.40.5060: SIP, length: 1472
        INVITE sip:00@192.168.20.40 SIP/2.0
        Via: SIP/2.0/UDP 192.168.20.60:5060;branch=z9hG4bK-524287-1---d10913283efb6273;rport
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1049753513
        Max-Forwards: 69
        Record-Route: <sip:192.168.20.60:5060;transport=udp;lr>
        Contact: <sip:3@127.0.0.1:6060>
        To: <sip:00@192.168.20.40>
        From: <sip:3@192.168.20.40>;tag=1214697537
        Call-ID: 1450925902
        CSeq: 21 INVITE
        Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK, SUBSCRIBE
        Content-Type: application/sdp
        Proxy-Authorization: Digest username="3",realm="192.168.20.40",nonce="8516:da0faed36020f8c94f9235628b7174fd",uri="sip:00@192.168.20.40",response="
        Supported: replaces, timer, 100rel
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        X-Endpoint-Type: DS
        Content-Length: 768

        v=0
        o=gateway 0 18 IN IP4 192.168.20.60
        s=conversation
        c=IN IP4 0.0.0.0
        t=0 0
        m=audio 10004 RTP/SAVP 8 0 4 18 101 13 98
        a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qy+Mo6UfN7/W7sQrs8fFn+ioWkq+0lqOLLohmXzU
        a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:S0juts/k6k24Adfw8FriOWx0se5VEwoUIPaK+uht
        a=rtpmap:8 PCMA/8000
        a=rtpmap:0 PCMU/8000
        a=rtpmap:4 G723/8000
        a=rtpmap:18 G729/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15
        a=rtpmap:13 CN/8000
        a=rtpmap:98 PCMA/8000
        a=gpmd:98 vbd=yes
        a=inactive
        m=audio 10004 RTP/AVP 8 0 4 18 101 13 98
        a=rtpmap:8 PCMA/8000
        a=[!sip]
06:28:21.902113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 339)
    192.168.20.40.5060 > 192.168.20.60.5060: SIP, length: 311
        SIP/2.0 100 Trying
        Via: SIP/2.0/UDP 192.168.20.60:5060;branch=z9hG4bK-524287-1---d10913283efb6273;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1049753513
        To: <sip:00@192.168.20.40>
        From: <sip:3@192.168.20.40>;tag=1214697537
        Call-ID: 1450925902
        CSeq: 21 INVITE
        Content-Length: 0

06:28:21.912124 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 548)
    192.168.20.40.5060 > 192.168.20.60.5060: SIP, length: 520
        SIP/2.0 480 Temporarily Unavailable
        Via: SIP/2.0/UDP 192.168.20.60:5060;branch=z9hG4bK-524287-1---d10913283efb6273;rport=5060
        Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1049753513
        To: <sip:00@192.168.20.40>;tag=1848537065
        From: <sip:3@192.168.20.40>;tag=1214697537
        Call-ID: 1450925902
        CSeq: 21 INVITE
        Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK, SUBSCRIBE
        Supported: replaces, timer, 100rel
        User-Agent: eXosip/5.3.0
        Allow-Events: conference
        Content-Length: 0

06:28:21.930193 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 309)
    192.168.20.60.5060 > 192.168.20.40.5060: SIP, length: 281
        ACK sip:00@192.168.20.40 SIP/2.0
        Via: SIP/2.0/UDP 192.168.20.60:5060;branch=z9hG4bK-524287-1---d10913283efb6273;rport
        Max-Forwards: 70
        To: <sip:00@192.168.20.40>;tag=1848537065
        From: <sip:3@192.168.20.40>;tag=1214697537
        Call-ID: 1450925902
        CSeq: 21 ACK
        Content-Length: 0

Что я здесь вижу:

В 06:28:21.805426 канальное окончание DS вызвало конференцию 00@192.168.20.40.
На этот вызов пришел ответ "480 Temporarily Unavailable" (вот он где - этот ответ пришел канальному окончанию DS, а не оператору!).

В свете этой информации ситуация выглядит следующим образом:

канальное окончание DS получило и групповом канале TDM сигнал "подключение".
Канальное окончание DS успешно подключило своего оператора к групповому каналу.
Попытка установить "фальшивый" (без медиапотока) вызов конференции закончился неудачно - конференция отказалась принимать участника.
Канальное окончание отключило телефон оператора от группового канала, так как ему было отказано в участии в конференции.

Вывод: канальное окончание DS ведет себя здесь правильно - так, как и было задумано при его разработке. А почему конференция отказала оператору в присоединении к ней, попробую выяснить далее...

comment:16 by alx, 16 hours ago

Анализирую приложенный файл messages_20.40.txt чтобы понять, почему конференция отказала в подключении оператору. Вот фрагмент лога, зафиксировавший прием "проблемного" вызова:

98	Jun  3 06:28:21 sip_ua[478]: user_agent.cpp:2289: INVITE received: sip:00@127.0.0.1:6060;transport=udp (Call-ID: 1450925902@(null))
99	Jun  3 06:28:21 sip_ua[454]: pps.cpp:97: ---> ts=1, state=Connected: Incoming call, ts=-1, flags=0001, data=136
100	Jun  3 06:28:21 sip_ua[454]: fxs.cpp:434: ---> ts=254, state=Connected: Incoming call, ts=-1, flags=0001, data=136
101	Jun  3 06:28:21 sip_ua[454]: conference.cpp:96: ---> ConferenceFocus: Incoming call, ts=-1, flags=0001, data=136
102	Jun  3 06:28:21 sip_ua[454]: virtualChannel.cpp:217: ---> VirtualChannelManager: Incoming call, ts=-1, flags=0005, data=136

Из этого фрагмента следует, что вызов был "опознан" фокусом конференции как адресованный ему.

Далее я проанализировал код фокуса конференции (conference.cpp) и выяснил, что ответ с кодом 480 передается фокусом конференций в случае, если достигнут лимит количества участников конференции. В связи с этим у меня вопрос: каково значение конфиуграционного параметра "Макс. число участников конференции" платы VE-02?

Version 0, edited 16 hours ago by alx (next)

follow-up: 19 comment:17 by roman_zhur, 16 hours ago

В связи с этим у меня вопрос: каково значение конфиуграционного параметра "Макс. число участников конференции" платы VE-02?

Подскажи, пожалуйста, где именно я могу его посмотреть?

follow-up: 20 comment:18 by roman_zhur, 16 hours ago

Кажется, я нашел, что в чём проблема)
Если ты про параметр "Макс. число участников конференции:" на вкладке "ДВО", то по умолчанию там стояла цифра 3.
Я изменил ее на 10 и второй оператор смог подключиться к конференции и поговорить.
Я удивлен, что этот параметр так же отвечает и за участников конференции на вкладке "Конференции", потому что это максимально контринтуитивно.

by alx, 16 hours ago

Attachment:	ss1.jpg added

in reply to: 17 comment:19 by alx, 16 hours ago

Replying to roman_zhur:

Подскажи, пожалуйста, где именно я могу его посмотреть?

В веб-интерфейсе блока: открыть диалог конфигурации платы VE-02, которая используется для диспетчерской конференции, переключиться на вкладку "ДВО" и смотреть вот сюда:

in reply to: 18 comment:20 by alx, 16 hours ago

Resolution:	→ invalid
Status:	new → closed

Replying to roman_zhur:

Кажется, я нашел, что в чём проблема)
Если ты про параметр "Макс. число участников конференции:" на вкладке "ДВО",

Да, я спрашивал именно о нем.

то по умолчанию там стояла цифра 3.
Я изменил ее на 10 и второй оператор смог подключиться к конференции и поговорить.

Отоично. Значит все работает так, как и должно.

Note: See TracTickets for help on using tickets.

Download in other formats: