Заголовки INVITE
Method and RURI (Request URI) — назначение запроса, используется прокси-серверами для роутинга запроса.
Via: сообщает, куда слать ответы на данный запрос, каждый прокси-сервер добавляет свой заголовок Via. Параметр branch идентифицирует транзакцию.
To: не используется для роутинга, содержит display name и SIP URI.
From: содержит display name и SIP URI, которые идентифицируют звонящего (Caller ID). Параметр Tag добавляется телефоном.
Call-ID: глобальный уникальный идентификатор вызова
Call-ID + To Tag + From Tag: вместе идентифицируют SIP диалог — Dialog ID (tags используются in parallel forking)
CSeq: command sequence инкременрируется при каждом запросе в текущем диалоге.
Contact: прямой маршрут для связи с userA (как сконтактировать с клиентом напрямую).
Разница между Via и Contact
- Via: говорит, куда слать ответы
- Contact: говорит, куда слать будущие запросы
Описанием медиа, кодеков и т.д. занимается протокол SDP. Описание вкладывается в тело SIP запроса. Описание SDP используется при установлении RTP сессии.
Если Record Routing не вовлечен, ACK посылается напрямую пользователю, минуя прокси-сервера (я так понимаю, это Stateless режим работы прокси-сервера).
Но зачастую используются Stateful режим и прокси-сервера таки добавляют заголовок Record Route в сообщения, чтобы заставить «пользователей» слать все запросы через себя. Это дает возможность мониторить состояние сессий.
ACK — метод, не требующий ответа. ACK отсылается только на INVITE, на BYE — нет (BYE—>, <—OK, все, сессия завершена)
Конечные пользователи изучают друг друга через Contact.
INVITE/200 OK/ ACK называют SIP three-way handshake.
Разница между SIP-транзакцией и SIP-диалогом
- SIP-транзакция: запрос — промежуточные ответы (если есть) — окончательный ответ.
ACK на положительный ответ — новая транзакция.
ACK — на отрицательный ответ — принадлежит существующей INVITE-транзакции, новая транзакция не создается.
- SIP-диалог: все общение от начала до конца, идентифицируется Dialog ID (Call-ID+From Tag+To Tag)
Разница между SIP-Proxy и B2BUA (PBX)
- SIP-Proxy:
Маршрутизирует запросы (1 leg)
Как быстро опознать? Один и тот же Call-ID
- B2BUA (back-to-back user agent):
Отвечает на входящий вызов (a-leg)
Инициирует исходящий вызов (b-leg)
Bridge 2 legs — соединяет 2 ноги
Как быстро опознать? Call-ID разные
Call-ID сохраняется при прохождении через прокси-сервер, но при прохождении через B2BUA у вызова 2 ноги, Call-ID у двух ног разные
Remote-Party-ID (RPID) -не стандартизирован, но популярен, используется для определения CallerID.
Стандарный путь для определения CallerID, это заголовки:
P-Asserted-Identity
P-Prefered-Identity
Privacy headers
Режимы работы Proxy-серверов
- Stateful
- Stateless
Initial and Sequential Requests
Initial and Sequential Requests — почему важно различать? — по разному роутятся
- Initial — отсутствует To Tag (например, запрос INVITE)
- Sequential (In-Dialog)— есть To Tag; Same Call-ID, From Tag , To Tag (например BYE, ACK, RE-INVITE)
SDP Negotiation
- Normal Negotiation:
INVITE with SDP offer —>
<— 200 OK with SDP answer
ACK without SDP —>
-последнее слово в согласовании за UAS
- Late Negotiation:
INVITE without SDP —>
<— 200 OK with SDP offer
ACK with SDP answer —>
-последнее слово в согласовании за UAC
DTMF
- inband DTMF
- named events (RFC 2833)
- SIP INFO