Re: ложный кпв

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Thu 26 Oct 2006 - 15:24:42 MSD

On Thu, 26 Oct 2006 11:17:17 +0400
  "Oleg Shumsky" <CGatePro@mx.ru> wrote:
> Здравствуйте.
>

>>> У меня модифицирован gatewaycaller и ip pstn шлюза он берет исходя из 
>>> ответа httpcall, на который уже потом и формируется инвайт. Вот 
>>> только никак не могу понять вашу фразу, что нужно сделать. Я не 
>>> использую callerLeg.sppi, он не вызывается из gatewaycaller. Там 
>>> используются startcall и acceptcall и из external функций только 
>>> playNumber и все.
>>
>>
>> Тогда вместо StartCall надо использовать (в 5.1.х!) 
>> StartBridgedCall(), а вместо AcceptCall - StartBridge().

>
>
> Дмитрий, а нельзя ли как-то поподробнее, т.к. проблема мне кажется
>выглядит достаточно серьезной.

а в чем, собственно, проблема? В том, что при бриджевании звонков не передаются 180/183 из одного лега B2BUA в другой? Так они и не должны передаваться. у операции StartBridge() нет такого понятия, как "установление звонка" и она НИКАКИМ образом в передаче чего-то там не участвует.

Прочитайте внимательно описание - бриджевание при помощи StarrBridge/AcceptBridge делается ТОЛЬКО для уже установленных звонков. И картинки в описании есть. Движущиеся даже. И ничего там про "установление звонка" нету.

Реально все эти B2BUA (gatewayincoming, gatewaycaller) работают/работали так:
по звонку рожалась задача (Task), которая разбиралась с параметрами и сеттингами. И рожала себе вторую задачу. Вторая задача начинала звонить, куда ей сказли (это всё упаковано нынче в callerLeg.sppi). Если звонок установился, то эти задачи начинали делать StartBridge/AcceptBridge. Заметим - ТОЛЬКО когда звонок уже установился. И передать медиа с одной ноги (задачи) в другую до установки звонка никак нельзя - они не связаны. Вторая задача, по получении provisioning event (а что это - 180, 183 или еще что-то - не разбиралась она), отсылала событие первой задаче, так что она тоже выдавала своему пиру (звонящему) provisionCall() - так что у него МОГЛИ начаться длинные гудки в трубе. Могла и сама их ему сэмулировать, проигрывая какой-то звук в этот "ранний диалог" - хотя наши программы этого не делали.

А после установления звонка шел StartBridge/AcceptBridge который виделся как re-INVITE с обеих сторон - и только тогда обе стороны становились связанными по медиа. Посмотрите на картинки внимательно еще раз.

В 5.1 появился StartBridgedCall() - он ОПИСАН в мануале.

Теперь разрешено выдавать StartBridge когда звонок еще не установлен (при ждущем входном звонке). Что новые B2BUA программы и делают (опционально). Порождают вторую таску B2BUA и дают ей StartBridge(). Та его хватает и делает StartBridgedCall() с параметрами звонка (куда, почём) и с этим StartBridge Event в качестве второго параметра.

Тогда звонок, уходяший со второй ноги будет иметь медиа (SDP) исходного звонящего (этот sdp пришел вместе с startBridge event), и "полурабочий" бридж между двумя ногами устанавливается сразу. Теперь, если тот, кому звоним, присылает 18x то -
а) этот 180 в виде provisionEvent попадает во второй таск (как обычно). б) этот 18x уходит в первый таск в виде специального события. Которое обрабатывается системой (первый таск висит в StartBridge вызове) и приводит к выдаче 18x звонящему.
в) так как звонимый (хм. кому звонят) уже поимел настоящий sdp звонящего, то он свои длинные мелодичные гудки может действительно ему поиграть, а тот их даже, может, и услышит.
г) когда приходит 200 - то есть звонок принят, то он пробегает тот же путь, что и 18x и диалог меж двумя конечными точками устанавливается полностью. Никаких ре-инвайтов тут уже не нужно.
Вторая задача получает FinalCall event, а первая задача успешно выходит из StartBridge.

Более того. При этом ни одна задача не создает (до этого момента) каналов Media Server-а. В исходном варианте с StartBridge/AcceptBridge: а) вторая задача создает MediaServer channel чтобы позвонить (она может им и воспользоваться, например проведя диалог с юзером - "слышь, тебе этот звонит! Хочешь отвечать - нажми 1")
б) первая задача создает MediaServer channl чтобы принять звонок AcceptCall() - и она тоже может им воспользоваться ("Эта, в натуре. Дозвонилась я, наконец. Говори быстрее, у тебя 50 копеек на счету").

Обычно этими медиа-каналами не пользуются (stock applications их не используют) и после StartBridge они живут совершенно ненасыщенной жизнью, сильно откушивая от ресурсов сервера.

Поэтому ОБЫЧНО лучше использовать вот этот вот StartBridgedCall. А еще лучше - stock library, такую как callLeg.sppi - которая умеет звонить, используя оба метода.

Старый метод все равно нужен, например в PBX. Там, где Вы сначала узнали (в уже установившемся звонке) куда надо звонить, а потом стали звонить. Тут можно использовать StartBridgedCall, но у вас не будет длинных гудков - когда вторая задача начнет передавать в первую 18x та будет только глупо улыбаться и бросать их на пол - потому что ей некуда их передать - её нога не в состоянии "входяшего звонка". А используя старый метод, можно просто играть эти длинные гудки самой (первой задаче), пока вторая трудится над установлением звонка.

Опять же - всё это есть в мануале, только несколько менее лирично, и поэтому сильно короче.

> Было бы неплохо ссылку на документацию и на
>описание передаваемых параметров в эти функции. Если я просто контекстной >заменой заменю в скрипте эти команды, то скорее всего ничего не заработает ?

Гарантированно не заработает, потому что тут совершенно разная логика работы.

Если Вы не совсем уверенно себя чувствуете с этими всеми операциями, то совет - использовать готорые "библиотеки" типа callerLeg.sppi - они дают гораздо более высокоуровневый интерфейс ко всем этим делам.

> Oleg V. Shumsky
> Corbina Telecom NOC, VoIP Dept. Ph.: +7 495 7284000, ext. 2174, ICQ:

Sincerely,
Vladimir Получено Thu Oct 26 11:23:29 2006