Re: Методологический вопрос

От: Dmitry Akindinov <CGatePro_at_mx_ru>
Дата: Fri 25 Mar 2011 - 14:14:08 MSK

Здравствуйте,

On 2011-03-25 11:39, Benjamin Franklin wrote:
> On Thu, 24 Mar 2011 12:14:51 +0300
> "Dmitry Akindinov"<CGatePro@mx.ru> wrote:
>
>> Для сбора лога одного SIP диалога обычно достаточно установить
>> уровень лога Settings -> Real-Time -> SIP -> Sending -> Transport в
>> All Info (хотя бы на время теста, когда проблема воспроизводится).
>> Далее в логе надо найти запрос INVITE, просто по строке
> [skip]
>
> Спасибо большое, логи отфильтровать удалось почти удовлетворительно.
>
>> С трансфёрами немного сложнее, поскольку там обычно присутствует два
>> диалога SIP - основной и тот, в который осуществляется этот трансфёр.
>> В таком случае надо найти в основном диалоге запрос REFER и, если в
>> нём есть заголовок Replaces, то он будет содержать URL-encoded
>> значение Call-ID второго диалога. Его надо скопировать, обычно
>> хватает небольшого кусочка до первого кодированного символа (до
>> первой %XX последовательности). И аналогично основному получить лог
>> этого SIP диалога.
> [skip]
>
> Проблема, с которой я пытаюсь разобраться, состоит в том, что перевод
> нормально работает если принять звонок, нажать xfer, набрать номер
> получателя, дождаться ответа и снова нажать xfer, а вот в случае, если
> второй раз нажать xfer на аппарате не дожидаясь ответа получателя
> звонка, то исходный звонок прерывается с сообщением в лог "491 Request
> pending". Причём хозяева сервера говорят, что "недавно само началось, а
> раньше всё работало".

Этот сценарий, когда перевод осуществляется в ранний диалог, является наиболее проблематичным, особенно если звонки - основной и второй - строятся с участием B2BUA приложений (а без них и совсем простые трансфёры могут не работать, к сожалению). В случае CGPro таким B2BUA в основном диалоге может быть приложение gatewayincoming, а с дополнительным обеспечением таких B2BUA может быть даже несколько. Ошибка 491 получается, скорее всего, при передаче запроса re-INVITE, который нужен для перекоммутации медиа трафика основного диалога в сторону нового его участника, а поскольку там диалог еще в ранней стадии (были provisioning ответы 18х, но не было финальных - транзакция ещё не выполнена), то получить 491 ошибку - очень вероятно. Если по-хорошему, то там надо было бы использовать метод UPDATE, но устройств, нормально его поддерживающих, ещё меньше, чем нормально выполняющих простой трансфёр посредством REFER. Если раньше работало, а потом вдруг перестало, то какие были изменения на сервере? И вообще, о какой версии CGPro мы говорим?

> P.S. Сервер не мой, я просто мимо проходил...
>

-- 
Best regards,
Dmitry Akindinov
Получено Fri Mar 25 11:14:34 2011

Этот архив был сгенерирован hypermail 2.1.8 : Fri 25 Mar 2011 - 16:16:39 MSK