Как я могу отправить сообщение 182 Queued SIP из CCXML?

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

Я использую Genesys GVP 8.1 IVR на основе SIP, подключенный к медиашлюзу.

У меня проблема в том, что звонок остается без ответа, время ожидания истекает через 30 секунд. Мне нужно отправить медиа-шлюзу какое-то сообщение проверки активности, чтобы сказать, что вызов все еще продолжается.

Я пробовал использовать это:

<send target="inConnectionID" targettype="'x-connection'" data="'connection.progressing'"/>

который сгенерирует 180 Ringing ... но я уже отправил 180 Ringing сообщение, и я думаю, что SIP-сервер не передает его по сети, потому что он уже обработал сообщение 180.

В идеале я хочу попробовать отправить сообщение 182 Queued, но я не могу найти ничего в документации CCXML или расширенной документации GVP CCXML, чтобы сказать, как это сделать.

Моя трассировка Wireshark SIP выглядит так:

Wireshark

Вы можете видеть, что второй звонок 180 через 24 секунды не передается на медиашлюз.

Как заставить GVP/CCXML отправлять SIP-сообщение 182 Queued?


person BG100    schedule 05.04.2011    source источник
comment
Я бы предложил посмотреть, почему медиасервер отменяет вызов через 24 с. Это довольно небольшой тайм-аут, и, скорее всего, его можно настроить. Я сомневаюсь, что отправка медиасерверу еще одного ответа 18x остановит его отмену.   -  person sipsorcery    schedule 06.04.2011


Ответы (2)


Сервер должен перенаправить ваши 180, хотя он не обязан этого делать, но должен, поскольку первые 180 могут быть потеряны между ним и медиа-сервером (хотя сервер, вероятно, повторно отправит INVITE) .

Однако, как указывает sipwiz, вероятная проблема заключается в настроенном максимальном времени ожидания медиа-сервера для приема вызова. 182 вряд ли поможет (хотя, не разбираясь в медиасервере, трудно быть окончательным).

Кроме того, вы должны повторно передавать 180 (и sip-сервер должен передавать его) примерно каждые 1 минуту, чтобы избежать возможного 3-минутного тайм-аута, разрешенного спецификацией. Некоторые стеки SIP, такие как eXosip, по умолчанию отключают INVITE, если прошло 3 минуты без ответа 1xx.

person jesup    schedule 07.04.2011

Я согласен, что медиашлюз не должен отменять на 34.7. Я также думаю, что SIP-сервер должен отправить 100 попыток обратно на ногу 1, прежде чем он отправит исходящее приглашение для ноги 2. Это остановит любые повторные передачи, поступающие от UAC ноги 1, и предотвратит отработку отказа, если медиашлюз использует алгоритм опрокидывания SRV.

person siphappens    schedule 29.07.2011