Обсуждение:Протокол инициирования сеанса

Это страница обсуждения для обсуждения улучшений в статье Session Initiation Protocol . Это не форум для общего обсуждения темы статьи.

Разместите новый текст под старым текстом. Нажмите здесь, чтобы начать новую тему. Впервые на Википедии? Добро пожаловать! Научитесь редактировать ; получите помощь . Предполагать добросовестность Будьте вежливы и избегайте личных нападок. Будьте приветливы к новичкам При необходимости обращайтесь к урегулированию спора Политика статьи Нейтральная точка зрения Нет оригинального исследования Проверяемость

Найти источники:  Google (книги  · новости  · ученые  · бесплатные изображения  · ссылки WP)  · FENS  · JSTOR  · TWL

Архивы : 1Период автоматического архивирования : 12 месяцев

Эта статья имеет рейтинг B-класса по шкале оценки контента Википедии . Она представляет интерес для нескольких WikiProjects .

Телекоммуникации средней важности Эта статья находится в рамках WikiProject Telecommunications , совместных усилий по улучшению освещения темы «Телекоммуникации» в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и ознакомиться со списком открытых задач.Телекоммуникации Википедия:WikiProject Telecommunications Шаблон:WikiProject Telecommunications Телекоммуникации Середина Данная статья имеет среднюю степень важности по шкале важности проекта . Вычислительная техника : Сетевые технологии средней важности This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by Networking task force (assessed as Mid-importance). Technology This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology

The contents of the SIP registrar page were merged into Session Initiation Protocol on 2011-08-19. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page.

The contents of the sips URI scheme page were merged into Session Initiation Protocol on 2012-04-09. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page.

The contents of the SIP connection page were merged into Session Initiation Protocol on 2012-10-11. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page.

imho большая проблема этой статьи - полное отсутствие аспектов (не)безопасности SIP. RFC3261 упоминает более 20 страниц различных угроз и предложений по решению этой проблемы

У нас есть Session_Initiation_Protocol#Encryption , но было бы желательно более подробное обсуждение вопросов безопасности. ~ Kvng ( обсуждение ) 03:36, 24 августа 2021 (UTC) [ ответить ]

"SIP gleaning" — это статья длиной в один короткий абзац, которая вряд ли станет чем-то большим. Я не вижу никаких причин, почему она не должна быть частью основной статьи SIP. -- GreyCat 11:59, 3 октября 2006 (UTC) [ ответить ]

Я немного запутался в "SIP gleaning". Не могли бы вы назвать RFC, который это определяет? -- Kgfleischmann 12:17, 3 октября 2006 (UTC) [ ответить ]

Похоже, это неологизм или маркетинговый термин. Единственный производитель SIP-устройств, который упоминает эту фразу, — Nortel (см. этот поиск в Google, который выдает всего 14 результатов). Я не думаю, что нам нужно это обсуждать — я собираюсь перенаправить без объединения. Если кто-то хочет объединить информацию, сделайте это любыми способами. Тема, безусловно, не заслуживает своей собственной статьи. Mind matrix 14:51, 3 октября 2006 (UTC) [ ответить ]

Должен согласиться с MindMatrix, вот формулировка из руководства пользователя коммутатора, который они продают (я не из Nortel!):

Поддержка SIP NAT и Gleaning

Конечным точкам IP в сети обычно назначаются частные адреса. Голосовые вызовы из и в публичную сеть должны достигать конечных точек в частной сети. В результате NAT требуется для обеспечения надлежащей маршрутизации медиа к конечным точкам с частными адресами. SIP несет идентификацию конечной точки IP (IP-адрес/порт) в теле сообщения. Голосовые медиа, которые направляются на частный IP-адрес, указанный в сигнальном сообщении, не могут быть маршрутизированы и приводят к одностороннему пути. Поэтому коммутаторы или маршрутизаторы конечных точек должны NAT SDP и создавать сеансы для медиасвязи. Термин «подбор», вероятно, не имеет отношения к контексту, говорит о том, как элемент NW (может) оптимизировать такую ​​функцию/возможность. 81.114.228.2 15:40, 5 декабря 2006 (UTC) Сверхъестественные протоколы Анестезиолог [ ответить ]

Я также согласен объединить его с этой статьей. Sae1962 ( обсуждение ) 10:41, 15 февраля 2011 (UTC) [ ответ ]

SIP gleaning теперь перенаправляет сюда, но SIP gleaning не упоминается в этой статье, что создает ситуацию WP:ASTONISH ING для читателей. Прежнее содержание SIP gleaning было

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

Возможно, кто-то возьмется включить эту информацию в свой текст. ~ Kvng ( обсуждение ) 03:36, 24 августа 2021 (UTC) [ ответить ]

В статье (от 8 июля 2010 г.) говорится, что «SS7 — это централизованный протокол, характеризующийся сложной архитектурой центральной сети и немыми конечными точками (традиционными телефонными трубками)». Это утверждение не является точным, поскольку SS7 на самом деле является протоколом сети передачи данных, предназначенным для передачи различных протоколов сигнализации между узлами (не терминалами) сетей связи общего пользования.

Следовательно, различные интерфейсы NNI (Node-to-Node) могут быть реализованы через SS7 (что указано в серии рекомендаций ITU-T Q.7xx), в то время как интерфейсы UNI (User-to-Node) НЕ МОГУТ быть реализованы через нее.

Однако верно, что в традиционных службах связи общего пользования каждый конкретный NNI обычно имеет соответствующий UNI. Например, ISDN UNI (указанный в рекомендациях Q.93x) соответствовал протоколу ISUP (ISDN User Part) для NNI (указанному в серии рекомендаций Q.73x). Последний протокол предоставляется через SS7, тогда как первый — нет (он фактически предоставляется через протокол доступа Q.921/LAP-D). В этих сетях протоколы UNI обычно были асимметричными (основанными на клиенте/сервере), тогда как протоколы NNI (т. е. основанные на SS7) были симметричными.

Кроме того, в традиционных сетях связи уровень сложности терминалов сильно варьируется в зависимости от того, какую конкретную сеть мы рассматриваем (POTS - Plain Old Telephone System против ISDN) и, в каждой сети, от конкретного типа рассматриваемой услуги/терминала. В качестве примера можно вспомнить, что некоторые терминалы ISDN реализовали возможности видеоконференций (включая мостовое соединение нескольких видеоконференций), высококачественную голосовую связь (широкополосные кодеки 7 кГц и даже 16 кГц) и возможности многосайтовой распределенной PABX (например, на основе Centrex). Они также поддерживали услуги передачи данных (X.25 и Frame Relay) с гибким использованием по требованию доступной полосы пропускания, постепенно объединяя 16kbps D-канал в два 64/56kbps B-канала, доступных в интерфейсе доступа BRI. Большинство этих возможностей (UNI) имели соответствующие аналоги NNI, которые в свою очередь могли быть реализованы как в распределенной форме по всем узлам сети (следуя традиционному телефонному подходу), так и более централизованно в специализированных узлах сети (IN - Intelligent Network), используя общие транспортные возможности, предоставляемые базовой сетью. Последний подход, определенный в конце 90-х, хотя и не широко реализованный, концептуально ближе к телефонным услугам, в настоящее время реализованным по SIP. —Предыдущий неподписанный комментарий добавлен 193.146.123.226 ( talk ) 08:47, 8 июля 2010 (UTC) [ ответить ]

Mazinalzypiry Mazinalzybiry (обсуждение) 17:14, 14 декабря 2018 (UTC) [ ответить ]

SIP rfc 3261 не говорит о SBC. Скорее, это инженерное решение для обхода NAT/Firewall. Я думаю, его следует упомянуть отдельно от других элементов, таких как proxy и registrar. Mvineetmenon ( talk ) 14:34, 19 сентября 2012 (UTC) [ ответить ]

Я добавил упоминание об этом. ~ Kvng ( обсуждение ) 03:36, 24 августа 2021 (UTC) [ ответить ]