Freeswitch: mod_xml_curl и группы вызовов

В настоящее время я переключаюсь со статических конфигураций на использование mod_xml_curl и столкнулся с проблемой при настройке групп вызовов.

Внутри моего диалплана (обслуживаемого динамически, работающего как положено) я подключаюсь к группе:

<action application="bridge" data="${group_call([email protected])}"/>

Freeswitch делает запрос с section=directory&action=group_call к веб-серверу, на который я отвечаю фрагментом каталога, содержащего группу и всех соответствующих пользователей:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<document type="freeswitch/xml">
    <section name="directory">
        <domain name="domain-a.com">
            <params>
                <param name="dial-string" value="{presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}" />
            </params>
            <variables>
                <variable name="user_context" value="domain-a.com" />
            </variables>
            <group name="call-group">
                <users>
                    <user id="john" number-alias="1000">
                        <params>
                            <param name="password" value="1234" />
                            <param name="vm-password" value="1000" />
                        </params>
                        <variables>
                            <variable name="toll_allow" value="domestic,international,local" />
                            <variable name="accountcode" value="1000" />
                            <variable name="outbound_caller_id_name" value="John at domain-a.com" />
                            <variable name="outbound_caller_id_number" value="1234567" />
                        </variables>
                    </user>
                    <user id="lucy" number-alias="1001">
                        <params>
                            <param name="password" value="1234" />
                            <param name="vm-password" value="1000" />
                        </params>
                        <variables>
                            <variable name="toll_allow" value="domestic,international,local" />
                            <variable name="accountcode" value="1001" />
                            <variable name="outbound_caller_id_name" value="Lucy" />
                            <variable name="outbound_caller_id_number" value="12345678" />
                        </variables>
                    </user>
                </users>
            </group>
        </domain>
    </section>
</document>

Тем не менее, group_call(), кажется, терпит неудачу, и в журналах я получаю ``:

2016-02-24 10:42:14.249534 [DEBUG] mod_dptools.c:1498 SET sofia/internal/[email protected] [call_timeout]=[15]
2016-02-24 10:42:14.529107 [CONSOLE] mod_xml_curl.c:323 XML response is in /tmp/2f772a8a-4c3a-46f2-834f-b9ba2c735feb.tmp.xml
EXECUTE sofia/internal/[email protected] bridge(error/NO_ROUTE_DESTINATION)

Возможно, у кого-то есть опыт настройки групповых звонков с помощью mod_xml_curl и кто-нибудь может пояснить, что именно Freeswitch ожидает в ответ?


person Disenchanted    schedule 24.02.2016    source источник


Ответы (2)


После небольшого скрежета зубов у меня все получилось. Подсказка была здесь под описанием group_call:

Обратите внимание: если вам нужно установить исходящие пользовательские переменные в ветви B, убедитесь, что у вас нет строки набора и строки набора группы в вашем домене или в списке переменных набираемой группы; вместо этого установите строку набора номера или строку набора номера группы в группе пользователя по умолчанию. Таким образом, group_call вернет user/101, а user/ установит все ваши пользовательские переменные на канал ноги B.

Итак, когда вы получаете действие типа group_call, переместите параметр dial-string на уровень группы, чтобы вместо

<domain name="domain-a.com">
    <params>
        <param name="dial-string" value="{presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}" />
    </params>
    <variables>
        <variable name="user_context" value="domain-a.com" />
    </variables>
    <group name="call-group">
        <users>
            <user id="john" number-alias="1000">
    ...

отправить это

<domain name="domain-a.com">
    <variables>
        <variable name="user_context" value="domain-a.com" />
    </variables>
    <group name="call-group">
        <params>
            <param name="dial-string" value="{presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}" />
        </params>
        <users>
            <user id="john" number-alias="1000">
    ...

После того, как я сделал это изменение, все было отлично. Ваше здоровье!

person Jrd    schedule 27.04.2021

Это связано с вашим диалпланом. Он не сгенерирован идеально. просто проверьте контекст domain-a.com в диалплане.

person suren    schedule 26.02.2016
comment
Спасибо за предложение, однако с диалпланом проблем нет: я отключил xml_curl и протестировал все со статическими конфигурациями, все работает правильно. Затем я включил привязку directory, оставив диалплан статичным, и я получаю ту же ошибку с групповыми вызовами. - person Disenchanted; 26.02.2016
comment
K я сделаю одну вещь, я проверю то же самое в своей системе. дайте вам знать, как справиться с этой ситуацией - person suren; 27.02.2016
comment
Вы можете решить эту проблему или все еще упорствуете? - person suren; 29.02.2016
comment
Я до сих пор не решил эту проблему, но я думал о том, чтобы отказаться от функции group_call и попытаться имитировать ее, вручную сгенерировав строку моста на веб-сервере при запросе диалплана. Хотя не было возможности попробовать. - person Disenchanted; 29.02.2016
comment
Попробовал описанный выше метод, создав расширение диалплана на веб-сервере (что-то вроде <action application="bridge" data="user/john|user/lucy" />), похоже, работает. Хотя до сих пор не ясно, что не так с group_call - person Disenchanted; 05.03.2016
comment
да, это сработает, даже групповой вызов будет работать. Я думаю, вы где-то ошиблись в групповом вызове. - person suren; 05.03.2016