Как я могу отправить сообщение SIP из очереди 182 из CCXML?
Я создаю голосовое приложение, для которого требуется длительный период звонка, пока мое приложение пытается настроить исходящий вызов. В течение этого времени звонок должен оставаться без ответа.
Я использую Genesys GVP 8.1 IVR на базе SIP, подключенный к медиа-шлюзу.
У меня проблема в том, что звонок остается без ответа, он истекает через 30 секунд. Мне нужно отправить какое-то сообщение проверки активности на медиа-шлюз, чтобы сказать, что вызов все еще продолжается.
Я пытался использовать это:
<send target="inConnectionID" targettype="'x-connection'" data="'connection.progressing'"/>
который сгенерирует звонок 180... но я уже отправил сообщение 180 звонка, и я думаю, что SIP-сервер не передает его по сети, потому что он уже обработал сообщение 180.
В идеале я хочу попробовать отправить 182 сообщение в очереди, но я не могу найти ничего в CCXML или расширенной документации GVP CCXML, чтобы сказать, как это сделать.
Мой след SIP Wireshark выглядит так:
Вы можете видеть, что второй 180-ринг в 24 секунды не передается в шлюз.
Как я могу заставить GVP/CCXML отправлять 182 сообщения SIP в очереди?
2 ответа
Сервер должен переслать ваши 180, хотя это и не обязательно - но это должно произойти, поскольку первые 180 могут быть потеряны между ним и медиасервером (хотя сервер, вероятно, повторно отправит сообщение INVITE).
Однако, как указывает sipwiz, вероятной проблемой является максимальное время ожидания, установленное медиасервером для принятия вызова. 182 вряд ли поможет (хотя без понимания медиасервера трудно быть окончательным).
Кроме того, вы должны повторно передавать 180 (и sip-сервер должен проходить через него) каждые около 1 минуты, чтобы избежать возможного 3-минутного тайм-аута, разрешенного спецификацией. Некоторые стеки SIP, такие как eXosip, по умолчанию рассчитывают на тайм-аут ПРИГЛАШЕНИЯ, если прошло 3 минуты без ответа 1xx.
Я согласен, что медиа-шлюз не должен отменяться в 34.7. Я также думаю, что SIP-сервер должен отправить 100 попыток на leg1, прежде чем он отправит исходящее приглашение для leg2. Это остановит любые повторные передачи, поступающие от leg1 UAC, и предотвратит любое аварийное переключение, если медиа-шлюз использует алгоритм опрокидывания SRV.