Формирование первоначального запроса INVITE происходит вне диалога с использованием соответствующих стандартных процедур. Дополнительная обработка требуется лишь в особых случаях.

Как правило, INVITE содержит заголовок Allow. Он указывает, какие типы запросов могут быть использованы вызывающей стороной в процессе диалога. Скорее всего, в запросе будет также присутствовать заголовок Supported. Он перечисляет все расширения, поддерживаемые клиентом агента пользователя. Возможно присутствие заголовка Accept, который указывает поддерживаемые данным УАтипы тел сообщения из предложенных в принятом ответе или запросе в ходе диалога. Заголовок Accept особенно важен для индикации поддержки различных форматов описания сеансов. UAC можеттакже добавить заголовок Expires, чтобы ограничить время действия приглашения к установлению соединения. Если время, указанное в Expires, истечет до получения окончательного ответа на INVITE, UAC передает сообщение CANCEL. Кроме этого, UAC может посчитать нужным добавить заголовки Subject, Organization и User-Agent; все они содержат информацию, относящуюся к запросу INVITE. UAC может добавить в запрос INVITE тело сообщения. Существуют отдельные правила для тел, содержащих описание сеанса связи, - их заголовок Content-Disposition имеет значение session. Протокол SIP использует модель типа «запрос/ответ» (offer/answer), где один UA посылает предложение - запрос с описанием сеанса. Запрос предлагает желаемые средства общения (аудио, видео), их параметры (такие как типы кодека) и адреса для получения медиа-информации от отвечающей стороны.

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

• Начальное offer с описанием сеанса должно содержаться в сообщении INVITE или в первом надежном сообщении от UAS, не информирующем об ошибке (ответе класса 2хх).
• Если offer содержится в сообщении INVITE, то answer должен присутство вать в надежном ответе на INVITE от UAS. Точно такой же ответ с описанием сеанса (answer) может быть помещен в предварительные ответы, предшествующие окончательному. UAC трактует первый пришедший answer как описание сеанса связи и игнорирует описания сеанса во всех следующих ответах на начальное сообщение INVITE.
• Если offer содержится в первом надежном сообщении от UAS, не информирующем об ошибке, answer должен быть в подтверждении АСК на ответ класса 2хх.
• После передачи или получения answer на первый offer UAC может помещать следующие offer в запросы, следуя правилам для запроса данноготипа, но только если он получил answer на предыдущие offer и не передал offer, на которые answer еще не получены.
• После того как UAS передал или получил answer на начальный offer, он не должен включать новые offer в состав ответов на начальное сообщениеINVITE. Это означает, что UAS никогда не сможет в одиночку создать новые offer до завершения начальной транзакции. Приведенные выше правила определяют для агентов пользователя два вида обмена:
• offer в запросе INVITE и answer в ответе класса 2хх (и, возможно, в ответекласса 1хх с тем же значением),
• offer в ответе класса 2хх и answer в подтверждении АСК,

  причем все агенты пользователя, поддерживающие запрос INVITE, должны поддерживать оба этих вида обмена. К тому же, протокол описания сеансов связи Session Description Protocol (SDP) должен поддерживаться любыми UA [37]. Указанные выше ограничения для модели offer/answer применимы лишь к тем телам сообщения, в которых заголовок Content-Disposition имеет значение session. Поэтому возможен случай, когда и INVITE, и АСК содержат тело сообщения (например, запрос INVITE переносит фотографию (Content-Disposition: render), a АСК - описание сеанса (Content-Disposition: session)). Если заголовок Content-Disposition отсутствует, то для сообщений со значением заголовка Content-Type application/sdp для заголовка Content-Disposition по умолчанию устанавливается значение session, в противном случае устанавливается значение render.

  После создания запроса INVITE UAC отправляет его, следуя процедурам, определенным для передачи запросов вне диалога. Это приводит к формированию клиентской транзакции, которая, в конечном счете, передает запрос и доставляет ответы клиенту.