Поведение UAS |
|
UAS, получающий второй запрос INVITE до того, как в том же диалоге передан окончательный ответ на первый запрос INVITE с меньшим порядковым номером в заголовке Cseq, передает на второй INVITE ответ с кодом 500 (Server Internal Error) и включает в него заголовок Retry-After со случайно выбранной величиной в интервале от 0 до 10 секунд. UAS, который получает второй запрос INVITE до прихода окончательного ответа на первый запрос INVITE, инициированный им самим, передает на второй запрос ответ с кодом 491 (Request Pending). Если UAS получает re-INVITE для существующего диалога, он должен проверить все идентификаторы версии в описании сеанса, а при их отсутствии - содержимое описания сеанса, чтобы определить, изменилось оно или нет. Если описание сеанса изменилось, UAS должен настроить соответствующие параметры, возможно, после запроса подтверждения пользователя. Если новое описание сеанса неприемлемо, UAS может отклонить его, передав ответ на re-INVITE с кодом 488 (Not Acceptable Here). Такой ответ должен содержать заголовок Warning. Если UAS неоднократно передает ответ класса 2хх и ни разу не получает подтверждение АСК, он должен передать сообщение BYE для разрушения диалога. UAS может не передавать ответ с кодом 180 (Ringing) на запрос re-INVITE, поскольку UAC обычно не передает эту информацию пользователю. По той же причине UAS может не использовать в ответе на re-INVITE заголовок Alert-Info или тело сообщения, для которого заголовок Content-Disposition имеет значение alert. UAS, помещающий offer в ответ класса 2хх (из-за того, что re-INVITE не содержал offer), должен формировать offer так же, как если бы UAS создавал новый вызов, подчиняясь правилам передачи информации offer, обновляющей существующий сеанс в случае использования протокола SDP», RFC 3264. Это значит, что информация offer должна включать в себя столько форматов и типов медиа-информации, сколько поддерживает UA. UAS должен гарантировать, что описание сеанса частично совпадает с предыдущим описанием - форматами медиа-информации, типом транспортного протокола, или другими параметрами, которые поддерживаются UAC. Это делается, чтобы исключить возможность того, что описание сеанса будет отключено UAC. Если, все же, это описание не приемлемо для UAC, он должен сформировать answer с надлежащим описанием сеанса и затем передать BYE. |
