Учебники

SIP — Модель предложения / ответа

Февраль 25, 2019

Использование SDP с SIP дано в ответе предложения SDP RFC 3264. Тип тела сообщения по умолчанию в SIP — это application / sdp .

  • Вызывающая сторона перечисляет мультимедийные возможности, которые они готовы получить в SDP, обычно в сообщении INVITE или ACK.

  • Вызываемая сторона перечисляет свои мультимедийные возможности в ответе 200 OK на сообщение INVITE.

Вызывающая сторона перечисляет мультимедийные возможности, которые они готовы получить в SDP, обычно в сообщении INVITE или ACK.

Вызываемая сторона перечисляет свои мультимедийные возможности в ответе 200 OK на сообщение INVITE.

Типичное использование SDP протокола SIP включает в себя следующие поля: версия, источник, тема, время, соединение и один или несколько носителей и атрибутов.

  • Поле субъекта и время не используются SIP, но включены для совместимости.

  • В стандарте SDP поле субъекта является обязательным полем и должно содержать хотя бы один символ, предположительно s = — если субъекта нет.

  • Поле времени обычно устанавливается равным t = 00. SIP использует поля подключения, мультимедиа и атрибута для настройки сеансов между UA.

  • Поле происхождения имеет ограниченное использование с SIP.

  • Идентификатор сеанса обычно поддерживается постоянным в течение сеанса SIP.

  • Версия увеличивается каждый раз, когда изменяется SDP. Если отправляемый SDP не изменился по сравнению с отправленным ранее, версия остается прежней.

  • Поскольку тип мультимедийного сеанса и используемый кодек являются частью согласования соединения, SIP может использовать SDP для указания нескольких альтернативных типов мультимедиа и для выборочного принятия или отклонения этих типов мультимедиа.

Поле субъекта и время не используются SIP, но включены для совместимости.

В стандарте SDP поле субъекта является обязательным полем и должно содержать хотя бы один символ, предположительно s = — если субъекта нет.

Поле времени обычно устанавливается равным t = 00. SIP использует поля подключения, мультимедиа и атрибута для настройки сеансов между UA.

Поле происхождения имеет ограниченное использование с SIP.

Идентификатор сеанса обычно поддерживается постоянным в течение сеанса SIP.

Версия увеличивается каждый раз, когда изменяется SDP. Если отправляемый SDP не изменился по сравнению с отправленным ранее, версия остается прежней.

Поскольку тип мультимедийного сеанса и используемый кодек являются частью согласования соединения, SIP может использовать SDP для указания нескольких альтернативных типов мультимедиа и для выборочного принятия или отклонения этих типов мультимедиа.

Спецификация предложения / ответа, RFC 3264, рекомендует использовать атрибут, содержащий = rtpmap: для каждого поля мультимедиа. Поток мультимедиа отклоняется путем установки нуля номера порта для соответствующего поля мультимедиа в ответе SDP.

пример

В следующем примере вызывающая сторона Tesla хочет установить аудио- и видеовызов с двумя возможными аудиокодеками и видеокодеком в SDP, передаваемым в начальном INVITE — 

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

На кодеки ссылаются номера профилей RTP / AVP 97, 98.

Вызываемая сторона Marry отвечает на вызов, выбирает второй кодек для первого мультимедийного поля и отклоняет второе мультимедийное поле, желая только сеанса AMR. 

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Если этот аудиозвонок неприемлем, Том отправит ACK, а затем BYE, чтобы отменить звонок. В противном случае аудио сеанс будет установлен и RTP-пакеты будут обмениваться.

Как показано в этом примере, если не поддерживается количество и порядок полей мультимедиа, вызывающая сторона не может точно знать, какие сеансы мультимедиа были приняты и отклонены вызываемой стороной.

Правила предложения / ответа кратко изложены в следующих разделах.

Правила генерации предложения

Предложение SDP должно включать все обязательные поля SDP (это включает v =, o =, s =, c = и t =). Это обязательные поля в SDP.

Обычно включает в себя поле мультимедиа ( m = ), но это не обязательно. Строки мультимедиа содержат все кодеки, перечисленные в порядке предпочтения. Единственное исключение из этого — если конечная точка поддерживает огромное количество кодеков, должны быть перечислены наиболее вероятные или наиболее предпочтительные. Различные типы медиа включают аудио, видео, текст, MSRP, BFCP и так далее.

Правила генерации ответа

Ответ SDP на предложение должен быть составлен в соответствии со следующими правилами:

  • Ответ должен иметь такое же количество m = строк в том же порядке, что и ответ.

  • Отдельные медиапотоки можно отклонить, установив номер порта в 0.

  • Потоки принимаются отправкой ненулевого номера порта.

  • Перечисленные полезные нагрузки для каждого типа мультимедиа должны быть подмножеством полезных нагрузок, перечисленных в предложении.

  • Для динамических полезных нагрузок один и тот же номер динамической полезной нагрузки не требуется использовать в каждом направлении. Обычно выбирается только одна полезная нагрузка.

Ответ должен иметь такое же количество m = строк в том же порядке, что и ответ.

Отдельные медиапотоки можно отклонить, установив номер порта в 0.

Потоки принимаются отправкой ненулевого номера порта.

Перечисленные полезные нагрузки для каждого типа мультимедиа должны быть подмножеством полезных нагрузок, перечисленных в предложении.

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

Правила изменения сеанса

Любая из сторон может инициировать другой обмен предложением / ответом для изменения сеанса. При изменении сеанса необходимо соблюдать следующие правила:

  • Номер версии линии источника ( o = ) должен быть таким же, как и последний отправленный, что указывает на то, что этот SDP идентичен предыдущему обмену, или может быть увеличен на единицу, что указывает на новый SDP, который должен быть проанализирован.

  • Предложение должно включать в себя все существующие линии средств массовой информации, и они должны быть отправлены в том же порядке.

  • Дополнительные медиа потоки могут быть добавлены в конец списка m = line.

  • Существующий медиапоток можно удалить, установив номер порта равным 0. Эта медийная линия должна оставаться в SDP и всех будущих обменах предложением / ответом для этого сеанса.

Номер версии линии источника ( o = ) должен быть таким же, как и последний отправленный, что указывает на то, что этот SDP идентичен предыдущему обмену, или может быть увеличен на единицу, что указывает на новый SDP, который должен быть проанализирован.

Предложение должно включать в себя все существующие линии средств массовой информации, и они должны быть отправлены в том же порядке.

Дополнительные медиа потоки могут быть добавлены в конец списка m = line.

Существующий медиапоток можно удалить, установив номер порта равным 0. Эта медийная линия должна оставаться в SDP и всех будущих обменах предложением / ответом для этого сеанса.

Удержание вызова

Одна сторона в вызове может временно поставить другую на удержание. Это делается путем отправки сообщения INVITE с идентификатором SDP, идентичным исходному сообщению INVITE, но с присутствующим атрибутом = sendonly .

Вызов снова становится активным путем отправки другого сообщения INVITE с присутствующим атрибутом a = sendrecv . На следующем рисунке показан поток вызовов при удержании вызова.

59
Share: