Для чего используется тег from в SIP-запросе?

[EDIT] О значении атрибута "tag" внутри поля заголовка From, вот ваш ответ: http://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/

Удаление тега просто предложит серверам считать сообщения дубликатами.

Подводя итог тому, что написал Эндрю Прокоп:

Наиболее очевидная проблема с использованием Call-ID для уникальной идентификации сообщения возникает при разветвлении вызовов. При разветвлении вызовов одно сообщение SIP Invite превращается в несколько сообщений Invite для разных пунктов назначения. Например, вы можете позвонить мне, Эндрю Прокоп, но разветвление вызовов может привести к тому, что сообщения с приглашением будут отправлены на все мои зарегистрированные конечные точки — мой смартфон, мой настольный телефон и мой компьютерный телефон. Этот единственный Call-ID был в порядке, когда это было одно приглашение, но это не так хорошо, когда их становится три. Здесь на помощь приходят теги.

Теги действительно довольно просты, но требуют небольшого пояснения. Цель тега — работать с Call-ID, чтобы сделать весь диалог уникальным, независимо от того, сколько раз сеанс может быть разветвлен. На самом деле, я должен был сказать теги, так как их два. Существует локальный тег (от тега), который назначается отправителем сообщения или UAC. Существует также удаленный тег (To tag), который назначается конечным получателем сообщения или UAS (User Agent Server). UAC помещает свой тег в заголовок From, а UAS помещает свой тег в заголовок To. Таким образом, когда сообщение покидает UAC, оно имеет один тег в заголовке From и не имеет тега в заголовке To. Когда UAS получает это сообщение и отвечает ответом SIP (например, 180 Ringing), он затем добавляет тег в заголовок To. Если несколько клиентов получили исходное сообщение, то все они добавили бы свои собственные определенные значения тегов. Другими словами, все эти SIP-сообщения будут иметь один и тот же тег «От», но в зависимости от того, кто отвечает, будут разные теги «Кому».

@Ani, вот один реалистичный пример, когда вы можете сказать, почему действительно требуется «From-tag». В случае повторного INVITE, когда это было сделано с вызываемого/завершающего номера из исходного INVITE, происходит обмен заголовками To и From, и, таким образом, тегом From и тегом To-Tag.

Пример ссылки: Пример -пригласить поток

Предположим, A отправляет начальное INVITE на B, From заголовок имеет тег A (локальный тег), To Header имеет тег B (удаленный тег). позже, после того, как вызов принят, B отправляет повторное INVITE в A, в этом повторном INVITE From Header имеет sip uri B с тегом B, а заголовок TO имеет sip uri A с тегом A. Теперь для этого случая тег B становится локальным тегом, а тег A становится удаленным тегом.

Теперь, если вы думаете, что если From-тег не был в самом первоначальном ПРИГЛАШЕНИИ, то в повторном ПРИГЛАШЕНИИ не будет To-Tag, и будет трудно идентифицировать получателя.

From Tag — это идентификатор UAC для Диалога, отличный от Call-Id. Вместе они придают диалогу уникальный характер.

Другие варианты использования

1. Заколка / Тромбонинг — хотя это разные услуги, обе они полагаются на тег FROM, чтобы различать направление вызова на основе тегов Dialog.

2. Отправка нескольких INVITE для взаимодействия с PSTN, где IAM и последующие цифры в SAM переносятся в INVITE и в том же заголовке FROM. Помогает нижестоящим шлюзам соответствовать конкретным диалогам. RFC 3578 содержит более подробную информацию. Таким образом, в этом случае тег FROM для того же вызова помогает GW определить, как обрабатывать сообщение INVITE, содержащее дополнительные цифры.

Поле «От» предназначено для информации об инициаторе запроса.

Попробуйте этот PDF-файл http://www.sipknowledge.com/rfc3261_explained_light.zip

Раздел 8.1.1.3 «От кого»

Кроме того, в разделе 8.3.1 говорится, что поле From является обязательным, как один из основных блоков в любом SIP-запросе.

Прежде всего, я также искал ответ на то же самое. Да, CALL-ID служит определенной цели. Но тег From & To используется для обработки SIP-авансов. Как много новых функций, включенных в вызов SIP.

Но нужно 3 :(можно много)

1. Если адрес From может появляться в запросах, сгенерированных другими клиентами агента пользователя для того же вызова, вызывающий абонент ДОЛЖЕН вставить параметр тега в поле From.

https://www.ietf.org/rfc/rfc2543.txt

2. Последнее: заголовок JOIN использует теги FROM и TO для проверки. Предположим, разговаривают 2 человека, и еще один хочет ПРИСОЕДИНИТЬСЯ к разговору.

RFC3911 — заголовок «Присоединение» протокола инициации сеанса (SIP) https://www.rfc-editor.org/rfc/rfc3911.txt

3. используется для проверки последующего запроса: -

   11.5 Получение последующих запросов

   При последующем получении запроса выполняются следующие проверки:

   1.   If the Call-ID is new, the request is for a new call,
        regardless of the values of the To and From header fields.
   
   2.   If the Call-ID exists, the request is for an existing call.
        If the To, From, Call-ID, and CSeq values exactly match
        (including tags) those of any requests received previously,
        the request is a retransmission.
   
   3.   If there was no match to the previous step, the To and From
        fields are compared against existing call leg local and
        remote addresses. If there is a match, and the CSeq in the
        request is higher than the last CSeq received on that leg,
        the request is a new transaction for an existing call leg.
   

Как и получатель. У отправителя вызова может быть несколько устройств. IP-телефон, агент обработки вызовов или IP-коммуникатор на ноутбуке. Отличие от тегов от вызова может помочь определить устройство, с которого поступает вызов. Кроме того, как упоминалось выше, это может помочь перезвонить исходному устройству, если получатель перезвонит отправителю.