Текст, который вы цитируете из RFC3264, усекается:
После того, как заказчик отправил предложение, оно ДОЛЖНО быть готово получить
медиа для любых прямых потоков, описанных в этом предложении. Это должно быть
готовы отправлять и получать медиа для любых потоков sendrecv в
предлагать и отправлять мультимедиа для любых потоков, отправленных в предложении (из
Конечно, он не может на самом деле отправить, пока партнер не даст ответ
с необходимым адресом и информацией о порте). В случае RTP,
даже если он получит СМИ до получения ответа, он получит
не сможет отправлять отчеты получателя RTCP, пока не получен ответ.
Как написано: фактически не может отправлять, пока узел не предоставит ответ .
Я предполагаю, что готово отправить относится к тому факту, что вы должны
выделить все кодеки и сокеты. Даже для потока sendonly, вы можете получить
данные на медиа-сокете: например, запросы STUN, пакеты DTLS ... и
что-то из этого может произойти до того, как вы получите SDP answer . Если розетка
не готова к приему, ОС, вероятно, отправит ICMP-порт недоступным, который
например, может ввести задержку в настройке.
Мне не известно о существовании пустого пакета RTP . (Я видел некоторые в
Прошлое, но это не определяется никаким rfc, насколько я знаю!)
РЕДАКТИРОВАТЬ: Хотя вы никогда не будете отправлять пакеты RTP в потоке мультимедиа, вы ДОЛЖНЫ иметь возможность отправлять пакеты STUN (ICE) или DTLS (шифрование) ДО вы получите SDP-ответ . Вывод: вы, вероятно, не будете отправлять мультимедиа (RTP), но вам необходимо подготовиться и обработать данные, полученные в потоке мультимедиа, и отправить ответы на STUN, DTLS ...