Интернет-сайт protosip.ru является собственностью компании ООО «Бамлекс», специализирующейся на внедрениии следующих систем: voip телефонии (консультации в области телефонии через интернет - бесплатной офисной связи, единый план нумерации офисных телефонных номеров для компаний с распределенными офисами), голосовой почты, click to dial - звонки с сайта, обучении Asterisk (SER, OpenSER, SEMS, Red5), консалтинговых услуг построение call center (проект voip системы, обучение персонала, разработка бизнесс процессов под нужды заказчика).

Сайт содержит актуальную информацию по услугам компании, последние новости voip отрасли, интересный телекоммуникационный форум, отличный справочник по протоколу SIP, рекомендации по выбору оконечных устройств (SIP телефоны, voip телефоны и телефонные станции).

Подробнее описание оказываемых услуг Далфи Смарт: запуск и внедрение voip телефонии, внедрение SIP систем, консалтинг (в т.ч. и на телекоммуникационном форуме) компаний планирующих построение распределенной телефонной системы, специалистов разрабатывающих приложения для voip телефонии, а так же непрофессиональных любителей sip телефонии.

На сайте www.protosip.ru представлена исчерпывающая информация о компании: история, последние новости. Есть возможность осуществления он-лайн заявки на выполнение услуг по voip телефонии.

Мы искренне надеемся, что наш сайт окажется полезным и информативным для каждого из наших посетителей.

Rambler's Top100
Banner
7 Среда, 07 Мая 2008 15:19  

Действия UAC

Механизм offer/answer, используемый для обмена информацией описания сеанса при работе с запросом INVITE, применяется и для запроса re-INVITE. UAC, который, к примеру, хочет создать новый медиапоток, формирует новое предложение offer, описывающее параметры этого медиапотока, и передает его в сообщении INVITE другому участнику сеанса. Важно заметить, что передается полное описание сеанса, а не его изменение.

Конечно, UAC может передать re-INVITE без описания сеанса; в этом случае первый надежный ответ на re-INVITE, не информирующий об ошибке (класса 2хх), будет содержать offer.

Если формат описания сеанса предусматривает возможность нумерации версий - присвоения порядкового номера SDP-описанию, предложенному в ходе сеанса, - инициатор модификации должен указать, что версия описания сеанса изменилась. Заголовки То, From, Call-ID, CSeq, и поле Request-URI формируются в соответствии с правилами для запросов в рамках существующего диалога.

UAC может решить не добавлять в запрос re-INVITE заголовок Alert-Info или тело сообщения со значением alert в заголовке Content-Disposition, поскольку UAS обычно не извещает пользователя о получении re-INVITE.

В отличие от INVITE, re-INVITE не может быть размножен при прохождении по сети и, следовательно, на него всегда приходит один окончательный ответ. Причиной является то, что поле Request-URI идентифицирует текущий адрес вызываемого пользователя, а не его списочный адрес.

Заметим, что UAC не должен инициировать новую INVITE-транзакцию в диалоге, пока протекает другая INVITE-транзакция в любом из двух направлении, а именно:

  • Если существует действующая клиентская INVITE-транзакция, TU должен подождать, пока она перейдет в состояние «Completed» или «Terminated», а уже затем инициировать новый запрос INVITE.
  • Если существует действующая серверная INVITE-транзакция, TU должен подождать, пока она перейдет в состояние «Confirmed» или «Terminated», и лишь потом инициировать новый запрос INVITE.

Однако во время выполнения INVITE-транзакции UA может инициировать транзакцию для запроса любого типа, кроме INVITE, ACK и CANCEL. И, наоборот, UA также может инициировать INVITE-транзакцию во время действия транзакции запросов любого типа, кроме INVITE, ACK и CANCEL.

Если UA получает на запрос re-INVITE окончательный ответ, отличный от класса 2хх, параметры сеанса останутся неизменными, как будто запрос re-INVITE не передавался. Если полученный ответ является 481 (Call/Transaction Does Not Exist) или 408 (Request Timeout) или если ответа на re-INVITE не получено (то есть от клиентской транзакции пришло уведомление о срабатывании таймера), UAC завершит диалог. Если UAC на запрос re-INVITE получает ответ с кодом 491, он должен запустить таймер со значением Т, выбранным в соответствии с нижеописанным.

  • Если именно UAC сформировал значение Call-ID идентификатора диалога, Т выбирается случайным образом в интервале от 2,1 до 4 секундс шагом 10 мс.
  • Если значение Call-ID идентификатора диалога сформировал не UAC, то Т выбирается случайным образом в интервале от 0 до 2 секунд с шагом 10мс.

Когда таймер сработает, UAC должен предпринять еще одну попытку передать re-INVITE, если до этих пор сохранилась необходимость модификации сеанса. Например, в случае, если произошло завершение сеанса связи, сопровождающееся передачей сообщения BYE, re-INVITE не будет передан.

Правила для передачи запроса re-INVITE и для создания подтверждения АСК ответа 2хх на re-INVITE те же, что для начального INVITE.