> Применение этому вижу, например, в использовании одновременно протокола XMPP и передачи файла (бинарный поток) или медиапоток протокола Jingle в рамках одного соединения TCPJingle - это не просто XEP, это целый набор XEP-ов, один из которых, собственно сам основной Jingle, призван реализовать P2P-сигнализацию поверх XMPP, другой реализует протокол RTP, третий DTMF и так дальше до полной телефонизации.
Сам XMPP при этом не P2P, он клиент-серверный. Так куда ты там собрались слать свои медиапотоки в рамках "одного соединения TCP", на jabber-сервер, а они там нужны? Нет не нужны, там и сессии для этих медиапотоков-то не нужны.
Кроме того, зачем слать голос и видео по TCP? Эта задача исторически ставит в приоритет своевременность, а не гарантированность. При этом есть потоки которые должны иметь гарантированную передачу, файлы, например. Судя по твоему комментарию, для тебя может оказаться сюрпризом, но сессионные данные в Jingle тоже могут проходить по UDP.
Или подожди, может ты решил смешать всё в одно волшебное P2P-шное Jingle соединение?
Приведу пример: три человека разговаривают; первый передает второму файл, пока второй и третий говорят что-то одновременно первому. Пораскинь мозгами, насколько удобна твоя концепция единого соединения для решения такой типовой задачи.
Сам Jingle это, исторически, костыль, пытающийся угнаться за SIP. Да, сигнализация у них разная, но суть одна. Он применяет ту же архитектуру, использует те же технологии, но Jingle в этом случае догоняющий. Признаюсь честно, тот пример который я привел на базе Jingle ты сейчас не сделаешь, нет еще стандарта, XEP-0272 пока экспериментальный. Но твои "применения" сделают появление такого стандарта невозможным.
> NAT
Проблемы с натом решаются через внедрение STUN/TURN (в лучших традициях SIP), а не так как ты там себе придумал. Опаньки, и этот стандарт не вышел из экспериментального статуса (XEP-0278)
> SCTP
Ага. Ну-ну. Сразу после тотального перехода на ipv6.
