у нас на базе пакетов UDP строится протокол RTP, где уже указывается и номер пакета и прочая служебная инфа и данные. Т.е. реально ходят лишь UDP пакеты. Пока правильно понимаю? Как тогда пришедшая куча на удаленный комп UDP пакетов из нескольких UDP (из скольки кстати?) состыковываются в одиин виртуальный пакет RTP? Где- то должен быть маркер что-ли? что дальнейшие пакеты объединяем в один RTP?

http://www.xserver.ru/computer/protokol/tcpip/3/

да, полазал по ссылке, хорошо написано, но про RTP ни слова. Во всяких wiki читал про RTP, но моего вопроса там не понял

Очень правильная фраза

Вашего вопроса не поняли даже Вы, куда уж тут остальным . Сам вопрос, как могу догадываться имеет крайне отдаленное отношение к RTP? Что там виртуальное ума не приложу, в какие пакеты состыковывается?
Поток, в непрерывный поток на "компе" собирается содержимое пакетов.

ок. попробуем ещё раз объяснить что непонятно.
У меня протокол RTP, который реализован на базе UDP. Из скольки пакетов UDP состоит один пакет RTP? Пока я правльно понимаю? Как в череде пакетов UDP мы понимаем, что на самом деле это начало протокола RTP, что это был последний пакет UDP в составе RTP, что этот пакет UDP первый и он -заголовок протокола RTP ?

Один пакет UDP передает один RTP пакет, тк RTP пакет - это уровень более высокий чем UDP в модели ISO-OSI
а вот RTP пакете может быть к примеру 7 кадров MPEG-TS. по 188 байт каждый x 7 = 1316 и + заголовок RTP 12 байт.
Поток, по-определению, не может иметь начала и конца.

возьмите wireshark, и проснифайте ваш генератор RTP. все сразу будет понятно.

да, у меня были подозрения, что один в один идут, т.к. этим wireshark и смотрю. IP телефон общается с удаленным хостом по очереди- пакет от моего IP отправляется, потом пакет принял на мой девайс. и так четко чередуется. Но! если отслеживать с самого начала разговор с момента установления соед., то там норм. все показывается- RTP пишет, а если включиться сниффером в разговор, то поочереди так же приходят пакеты, но уже написано, что UDP ??? Так вот как девайс понимает что пришедший пакет- UDP- трактовать как RTP ?

Начинайте с азов - адресация UDP/IP - порты, потом не худо-бы прежде чем вопросы задавать посмотреть на RTP заголовок, так вот, в отличие о Вас "программы" на него смотрят и даже понимают.

У вас же порт в конце концов определенный используется, который слушает приложение.

А вы бы взяли и выложили свой dump, у RTP до полна приложений использования. может быть чето конкретное сказали бы вам...

00 1f 33 df 40 f6 00 0e 08 dd 86 79 08 00 45 b8
00 3c 42 99 00 00 fa 11 af 18 ac 10 91 0b 3e 29
53 02 40 58 61 22 00 28 37 1f 80 12 38 80 15 41
1e 0d bd 38 59 01 20 e3 45 66 c0 fa 1d 27 47 de
60 ea 85 68 c8 fa 13 2d 07 de


вот дамп одного пакета от моего тлф до рутера, от туда далее
итак,
разница в сниффере что он пишет в одном случае RTP, в другом UDP только в том, что в UDP он после 42 байта пишет payload. А В случае RTP он дальше анализирует.
далее, описание протокла UDP- сначала порт отправителя, порт получателя, длина сообщения, CRC
в перехваченном пакете и IP ещё, т.к. там и мак и IP и прочее. Сам UDP начинается с 35 байта (как я это понял). Уже здесь идет порт источник, порт назнач. длина UDP, CRC. Тут пока ясно все.

Далее пошел уже RTP. Вопрос- какие данные в заголовке говорят, что внутри загрузки UDP находится RTP?
начиная с 43 байта видим 0х80 ??? где обещанная версия протокола 2?

Save as не умеете ?
суть в том чтобы открыть поток и поглядеть, мне эти наборы никак не понять. к сожалению.
____________

00 1f 33 df 40 f6 00 0e 08 dd 86 79 ---MAC
08 00 --sIZE TYPE
45 b8 00 3c 42 99 00 00 fa 11 af 18 ac 10 91 0b 3e 29 53 02 ----IP HEADER
40 58 61 22 00 28 37 1f --UDP

80 - ver2 (согласно http://ru.wikipedia.org/wiki/RTP первые два БИТА - это версия протокола)
12 - PT (7 бит) указывает формат полезной
38 80 -- Порядковый номер
15 41 1e 0d Метка времени
bd 38 59 01 ---SSRC-идентификатор
20 e3 45 66 c0 fa 1d 27 47 de 60 ea 85 68 c8 fa 13 2d 07 de --сами данные


что касается ethernet пакета :
6 - mac dst
6 - mac src
2 - size/type
20 IP заголовок
если тип указан в IP 0x11 кажется идет далее UDP
8 - Заголовок UDP
Дальше только Payload, который отдается приложению, принимающему данные порте dst, указанном в UDP


что не умеет разбирать Wireshark вам придется делать самому.
ищите тип 0x12 данных пейлоада в RFC 3550 для RTP и смежных.

полный цикл от позвонил до отбился


http://files.mail.ru/XCGXVB
выложил сюда

Как ни странно пришет RTP в обе стороны! Попробуйте кликнуть правой на пакете, который просто UDP выберите Decode as... выставьте нужный порт и в списке справа выберите RTP. Но у меня и без этого пакеты интерпретировал как RTP.
Нажмите для просмотра прикрепленного файла

по реализации подключения- на компе на материнке две сетевухи, организован мост из них. IP Телефон воткнут в одну, а другая сетевуха подключена к рутеру. Рутер уже к инету.
Поэтому, думаю, нормально, что пишет в две стороны.
Тут возможно Вы правы, что если уж на тлф пришел UDP пакет, то там ничего кроме как rtp не ждут ничего.

Если вы снифаете сетевой интерфейс, к которому подключен телефон, то все нормально. SIP пакеты в начале сессии, показывают какие порты работают, и организуют двунаправленный обмен по RTP. от телефона до сервера, и наоборот.
Тип данных: ITU-T G.729 (18 или 0x12) - звуковой канал. кусочками по 20 байтиков.
и так какие у вас еще вопросы ?

как узнаем что тип данных RTP?
Тип данных: ITU-T G.729 (18 или 0x12) - звуковой канал -так?

а в составе UDP не могут быть такие же данные, но означать другое?

Могут. RTP может использовать совершенно любой порт, в спецификации не оговорено. При установке соединения используется SIP протокол, там если я не ошибаюсь, устройства договариваются об используемом порте.

это предопределено тем, что в начале идет установка SIP сессии по TCP. Там и указывается какие типы данных будут передаваться в RTP в дальнейшем.


пейлоадом UDP может быть все что угодно, в том числе и данные, похожие на RTP. RTP По сути протокол уже пятого уровня ISO/OSI.

вывод - в данном пакете UDP никак не видно что содержится RTP внутри. Что там будет RTP- договорились в сессии SIP. Правильно понял? По крайней мере, если запустить сниффер в середине разговора, когда данных SIP нет уже- он и не распознает пакеты UDP как RTP.

Да, кроме того может быть так, что в RTP заранее известно, что будет предаваться, но не относительно к SIP.

тогда такой вопрос- как я могу определить, что пошли данные RTP? Если все пакеты смотреть на предмет UDP, то в сессии SIP тоже код 11 проходит, т.е. пэйлоад для IP будет UDP. Короче, они все UDP.

так смотрите заголовок RTP, первые байты - их уже достаточно чтобы определить что пошел голосовой трафик (Поле PayloadType=0x12) и размер кадра всего.

а размер кадра- какой байт именно? И при таких условиях определения случайностей не будет? Т.е. если Поле PayloadType=0x12 то это точно RTP? в других пэйлоудах не может быть? т.е. в протоколе SIP на этом месте не может быть 0x12. А если у меня G.711 ??? или ещё что ?

Полное непонимание основ . Предварительно назначается конкретный UDP порт для RTP и любые UDP фреймы с номером этого конкретного порта это уже RTP и разбираются по правилам RTP а не вообще всех возможных протоколов. Точка.

Метценгерштейн не принято использовать одновременно один порт для нескольких программ! Вам что 2^16 портов мало. У каждой программы определеный набор используемых портов.

Да, запутался я с основами. только сейчас начал разбираться. Сейчас все понятно стало. Всем спасибо. Вопросов больше нет.