процесс соединения RTP с SIP через SDP и наземные линии

Question

У меня проблема с запуском медиа-сеанса и объединением его с моим SIP-клиентом. Я разработал рекурсивный SIP-клиент, который повторно использует тот же шаблон запроса для отправки следующих запросов на сервер в соответствии с приемлемыми последовательностями, отмеченными в RFC, и примерами, которые я читаю. Насколько я могу судить, SIP-часть работает нормально, регистрирует запросы на сервер и выполняет аутентификацию. Я еще не завершил никаких звонков клиентам, потому что заголовок контента должен быть заполнен (что я еще не сделал, поэтому я получаю 503 с сервера, который, я думаю, в порядке).

долгое время я не знал, с чего начать медиа-сессию, и медленно научился использовать JMF, и я создал объект, который обрабатывает передачу RTP, теперь я стою на перекрестке, с одной стороны, у меня есть SIP-сигнализация, но для завершения приглашения требуется заголовок содержимого SDP, а с другой - RTP, который знает, как выполнить p2p.

Чтобы завершить дизайн, мне нужна ваша помощь по следующим вопросам:

1. Существует ли простой // простой // реализованный способ преобразования аудио / видео формата из JMF в носитель SDP заголовки? или даже генератор , чтобы я вводил все параметры для заголовка контента, и он быстро генерировал бы заголовок контента, или я должен сам это реализовать?

2. Как только я закончу создание SDK, и SIP запущен и работает, и я получаю ответ OK от сервера (после звонка и все), как мне начать сеанс медиа? подключить p2p в соответствии с информацией о вызывающем абоненте, которую я отправил в приглашении SIP?

3. Если 2 правильно, то каким будет соединение с наземными линиями? знает ли наземная линия связи, что после отправки OK обратно на сервер они прослушивают / запускают сеанс RTP на определенном порту?

Или я все неправильно понял? : - /

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

Спасибо заранее, Адам Зехави.

Добавлено:

Во-первых, спасибо за ваш ответ и время, которое вы потратили, чтобы помочь мне.

Я вернусь к вопросу 2:

как только вы получите ответ Ok, вы узнаете IP-сокет ( вы имеете в виду АДРЕС: ПОРТ правильный? ), который прослушивает сервер агента пользователя SIP (UAS), и какие кодеки он принимает и начать отправку вашего RTP.

Хорошо, я понимаю, я хотел знать еще одну вещь, во время этого разговора, когда я отправляю RTP-пакет в UAS, UAS использует в качестве моста между обоими UAC.

Теперь ... могу ли я создать диалог с использованием SIP, а затем отправить клиентскую информацию от одного к другому и установить P2P между двумя компьютерами без посредников (UAS), а затем утилизировать сеанс SIP?

Надеюсь, теперь я лучше себя объяснил ...

Спасибо, Адам.

Answer 1

Для 1 я ничего не знаю о JMF, поэтому не могу ответить напрямую, но SDP на самом деле не является сложным стандартом, в отличие от SIP, поэтому создание пакета SDP не должно быть таким сложным.Минимум, необходимый для создания пакета SDP, - это кодеки, которые вы предлагаете, и IP-сокет, на котором вы принимаете RTP.

Для 2, как только вы получите ответ Ok, вы узнаете, что IP-сокетсервер агента пользователя SIP (UAS) прослушивает и принимает кодеки и может начать отправку вашего RTP.В то же время вы должны начать получать RTP от UAS, так как он начнет отправлять одновременно с отправкой Ok.Конечно, вам также нужно будет отправить запрос SIP ACK в ответ на ответ Ok, в противном случае некоторые UAS будут считать, что ответ не был получен, и через некоторое время вызов будет прерван.Если вы только начинаете писать свой собственный стек SIP, вам еще предстоит пройти долгий путь!

Для 3 - да, хотя под стационарными телефонами вы действительно подразумеваете шлюз SIP-PSTN (сторона PSTN будетчто-то вроде ISDN, SSL или аналога).Сторона SIP шлюза PSTN такая же, как и любой другой SAS UAS, и как только он примет запрос INVITE, он начнет отправлять RTP через сокет, указанный в запросе, и аналогично начнет прослушивать RTP в сокете, который он поместил в Ok.ответ, который будет отправлен обратно вашему SIP-клиенту.

Обновление

Теперь ... могу ли я создать экземпляр диалога с использованием SIP, а затем отправить клиентовинформацию от одного к другому и установить P2P между двумя компьютерами без посредников (UAS), а затем утилизировать сеанс SIP?

Ответ - да, но вы немного путаете терминологию,Установленный SIP-вызов называется сеансом и всегда находится между клиентским агентом пользователя (UAC) и сервером пользовательского агента (UAS).Предполагается, что каждый агент SIP может выступать в роли UAC или UAS, и основное различие между этими двумя ролями заключается в том, что UAC инициирует вызов, а UAS отвечает на него.Определенное устройство SIP будет выполнять роль UAC для вызовов, которые оно инициирует, и роль UAS для вызовов, на которые оно отвечает.

Почему это описание UAC и UAS имеет значение?Потому что все SIP-коммуникации одноранговые.SIP НЕ является протоколом клиент / сервер.Это одноранговый протокол.Теперь это сбивает с толку, потому что у вас есть провайдеры VoIP, которые работают с SIP Proxy Servers или SIP PSTN Gateways , которые создают впечатление, что SIP работает на модели клиент-сервер, но этоне.

Так что я думаю, что вопрос, который вы на самом деле хотите задать, заключается в том, может ли SIP-вызов между UAC-to-B2BUA-to-UAS (который фактически является двумя отдельными вызовами или сеансами SIP: UAC-to-UAS / UAC-to-UAS) позволяют носителям обходить B2BUA и вместо этого перемещаться непосредственно между UAC и UAS с обоих концов.Ответ на этот вопрос - да.В B2BUA, подобном Asterisk, есть опция конфигурации SIP, называемая canreinvite, которая, если задано значение yes, приведет к отправке повторных сообщений INVITE на любой конец вызова после получения ответа, чтобы поток RTP проходил непосредственно между конечными точками вызова, а не соединялся через себя.Конечно, если требуется перекодирование, запись или эквивалентная функция кодека, она не будет пытаться повторно ПРИГЛАСИТЬ.Другой подход - это традиционный подход SIP Proxy, такой как используемый OpenSER, когда он вообще не предназначен для объединения медиа и все вызовы через него всегда будут приводить к тому, что RTP будет находиться непосредственно между устройствами SIP на любом конце вызова.Работающий способ заключается в том, что OpenSER просто перенаправляет запрос, который он получает от UAC, через UAS, и кроме добавления и / или изменения дополнительного заголовка SIP или двух, запрос INVITE точно такой же, как если бы UAC отправил его непосредственно в UAS.

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

Tech-invit - очень хорошие примеры сценариев SIP,

Примеры обслуживания протокола инициирования сеанса RFC5359 - больше примеров,

SIP Волшебство форумов - форум для публичной службы, на которой я работаю, которую посещают несколько человек, разбирающихся в вопросах SIP, если у вас есть более глубокие вопросы SIP.