SDP протокол сервера Ростелекома
SDP (Session Description Protocol) сервера от Ростелекома представляет собой набор правил, который определяет, как могут быть созданы мультимедийные сеансы, чтобы все элементы эффективно участвовали в сессии. В этом контексте сеанс состоит из устройств и серии взаимодействия между ними. Примером может служить видеоконференция, проводимая крупной корпорацией, которая включает в себя участников из нескольких департаментов в различных географических точках.
Содержание:
SDP протокол серверов Ростелекома
SDP протокол на серверах Ростелекома предназначен в первую очередь для использования в крупных глобальных сетях, включая интернет. Тем не менее протокол также может быть запущен в собственных локальных и городских сетях.
В SDP параметры сеанса включают в себя такую информацию, как его имя, дата и время начала, цель, адреса или порты всех конечных точек, форматы данных, которые будут использоваться, а также скорость передачи для эффективного обмена.
Протокол всегда работает в связке с SIP и RTP.
SIP протокол
SIP (Session Initiation Protocol) отвечает за создание пользовательского сеанса, который включает в себя мультимедийные элементы, такие как видео, голос, чат и игры.
Как и HTTP или SMTP, SIP работает на уровне приложений с моделью взаимодействия открытых систем (OSI). Его основная задача – обеспечение возможности связи. SIP способен создавать мультимедийные сессии и вызовы по IP телефонии, а также изменять или прекращать их. Протокол может приглашать участников одноадресных или многоадресных сессий, которые необязательно включают инициатора. SIP поддерживает отображение имен и перенаправление услуг, что позволяет пользователям отправлять и принимать сообщения, а также идентифицировать участников из любого места.
Узнайте, как настроить различные услуги от Ростелекома на TP Link TD W8968.
О внесении и изменении параметров интернет-подключения на D-Link DSL 2540u можно прочитать здесь.
SIP является протоколом по типу запрос-ответ. Здесь подразумеваются запросы от клиентов и ответы от серверов. Участники определяются по URL-адресам SIP.
Запросы могут быть отправлены через любой транспортный протокол, такой как UDP, SCTP или TCP. SIP определяет конечную систему, которая будет использоваться для сеанса, средства массовой коммуникации, параметры информации, а также желание вызываемой стороны участвовать в разговоре. После того как эти данные выясняются, SIP устанавливает параметры соединения на каждом из оборудования участников и приступает к передаче данных, а затем к прекращению вызова.
Интересно! SDP представляет собой составную часть SIP, в которой содержится подробная информация, для установки соединения.
RTP протокол
RTP представляет собой стандартный протокол интернета, который указывает путь для программы управления передачей мультимедийных данных в реальном времени по однопользовательской или многопользовательской сети.
Первоначально упомянутый в Engineering Task Force (IETF), RTP был разработан для транспорта аудиовидео группы в IETF для поддержки видеоконференций с несколькими, географически удаленными участниками. RTP обычно используется в приложениях интернет-телефонии. Протокол сам по себе не гарантирует доставку в реальном времени мультимедийных данных (так как это зависит от характеристик сети). Однако он обеспечивает необходимые средства для достижения максимально эффективного управления данными.
RTP сочетает в себе передачу данных с протоколом управления (RTCP), что дает возможность контролировать доставку пакетов для больших групповых сетей. Мониторинг позволяет приемнику обнаружить наличие потери данных. Оба протокола работают независимо от параметров базового сетевого уровня. Информация, содержащаяся в заголовке RTP сообщает приемнику о том, как восстановить данные, и описывает, какие кодеки имеют пакеты. Как правило, RTP работает поверх User Datagram Protocol (UDP), хотя используются и другие транспортные средства.
Интересно! Протокол инициирования сеанса связи (SIP) использует информация поступающую от RTP. В свою очередь, SDP работает в составе SIP.
Компоненты RTP включают:
- порядковый номер, который используется для обнаружения потерянных пакетов;
- идентификацию полезной нагрузки, которая описывает конкретные кодирования медиафайлов таким образом, что они могут быть изменены, если должны адаптироваться к пропускной способности;
- кадровую идентификацию, которая сообщает о начале и конце каждого пакета;
- идентификацию источника, которая определяет отправителя пакета;
- синхронизацию фрагментов мультимедиа, которая использует временные метки для обнаружения и компенсации задержек в одном потоке.
Ошибка SDP Ростелекома: services loading failed
Если вы столкнулись при работе в сети Ростелекома с ошибкой SDP – services loading failed, это означает что связь с сервером отсутствует. Чаще всего проблема возникает глобально, то есть не у одного пользователя, а у всего дома или его части. Такое поведение объясняется ремонтными или профилактическими работами, проводимыми провайдером. В этом случае подождите несколько часов до завершения обслуживания оборудования. Если же проблема присутствует на протяжении более одних суток, нужно обращаться к оператору при помощи телефонов горячей линии. Провайдер либо сообщит о проведении работ, либо составит заявку на вызов мастера для ремонта неисправности.
Достоинства, недостатки и особенности прошивки роутера D-Link DPN R5402 от Ростелекома.
О подключении пакета каналов Amedia Premium можно прочитать тут.
Настройка IPTV на DD-WRT: //o-rostelecome.ru/oborudovanie/dd-wrt/.
Протокол SDP является составной частью SIP, которая, в свою очередь, работает на основе данных RTP. Комплект технологий позволяет добиться корректной работы всех услуг, поставляемых через глобальные и местные сети.
Ростелеком sdp service loading failed что делать
- Главная
- Новости
- Рекомендации пользователям
- Настройка оборудования и ПО
- Ответы на вопросы
- Подключение SMART-TV
- Реорганизация зоны альтернативной тарификации
- Ответы на часто задаваемые вопросы
- Работа в сети Интернет
- Работа с почтой
- Личная www-страница пользователя
- Работа с новостями
- Интерактивное общение в Интернет
- Общение голосом в Интернет
- Списки рассылок
- Работа с виртуальным www-сервером
- WiFi. Настройка безопасности сети.
- WiFi. Особенности технологии.
- Коды ошибок подключений в Windows
- Настройка сети WiFi на модеме
- Работа с компьютером
- Безопасность в сети
- Ресурсы сети Интернет
- Услуги и тарифы
- Поиск
- Почтовая рассылка
- Написать письмо в службу технической поддержки Калужского Филиала
Телефоны для обращений:
Внимание, уважаемые зарегистрированные пользователи! Перед обращением будьте готовы назвать свой лицевой счет и учетную запись
Коды ошибок, возникающих при создании подключений удаленного доступа в Windows Vista
Аннотация
В статье перечислены коды ошибок, возникающих при создании подключений удаленного доступа или VPN-подключений на клиентских компьютерах под управлением Microsoft Windows Vista.
Дополнительная информация
Ниже перечислены коды ошибок, возникающих при создании подключений удаленного доступа или VPN-подключений.
600
An operation is pending.
601
The port handle is invalid.
602
The port is already open.
603
Caller’s buffer is too small.
604
Wrong information specified.
606
The port is not connected.
608
The device does not exist.
609
The device type does not exist.
610
The buffer is invalid.
612
The route is not allocated.
615
The port was not found.
616
An asynchronous request is pending.
617
The port or device is already disconnecting.
618
The port is not open.
619
The port is disconnected.
621
Cannot open the phone book file.
622
Cannot load the phone book file.
623
Cannot find the phone book entry.
624
Cannot write the phone book file.
625
Invalid information found in the phone book.
627
Cannot find key.
628
The port was disconnected.
629
The port was disconnected by the remote machine.
630
The port was disconnected due to hardware failure.
631
The port was disconnected by the user.
632
The structure size is incorrect.
633
The port is already in use or is not configured for Remote Access dialout.
Note In this error message, the word «dialout» is a misspelling for the words «dial out.»
635
Unknown error.
636
The wrong device is attached to the port.
638
The request has timed out.
645
Internal authentication error.
646
The account is not permitted to log on at this time of day.
647
648
The password has expired.
649
The account does not have Remote Access permission.
651
Your modem (or other connecting device) has reported an error.
652
Unrecognized response from the device.
653
A macro required by the device was not found in the device .INF file section.
654
A command or response in the device .INF file section refers to an undefined macro
655
The macro was not found in the device .INF file section.
656
The macro in the device .INF file section contains an undefined macro
657
The device .INF file could not be opened.
658
The device name in the device .INF or media .INI file is too long.
659
The media .INI file refers to an unknown device name.
660
The device .INF file contains no responses for the command.
661
The device .INF file is missing a command.
662
Attempted to set a macro not listed in device .INF file section.
663
The media .INI file refers to an unknown device type.
664
Cannot allocate memory.
665
The port is not configured for Remote Access.
666
Your modem (or other connecting device) is not functioning.
667
Cannot read the media .INI file.
668
The connection dropped.
669
The usage parameter in the media .INI file is invalid.
670
Cannot read the section name from the media .INI file.
671
Cannot read the device type from the media .INI file.
672
Cannot read the device name from the media .INI file.
673
Cannot read the usage from the media .INI file.
676
The phone line is busy.
677
A person answered instead of a modem.
678
There is no answer.
679
Cannot detect carrier.
680
There was no dial tone.
691
Access denied because username and/or password is invalid on the domain.
692
Hardware failure in port or attached device.
693
ERROR NOT BINARY MACRO
694
ERROR DCB NOT FOUND
695
ERROR STATE MACHINES NOT STARTED
696
ERROR STATE MACHINES ALREADY STARTED
697
ERROR PARTIAL RESPONSE LOOPING
698
A response keyname in the device .INF file is not in the expected format.
699
The device response caused buffer overflow.
700
The expanded command in the device .INF file is too long.
701
The device moved to a BPS rate not supported by the COM driver.
702
Device response received when none expected.
703
ERROR INTERACTIVE MODE
704
ERROR BAD CALLBACK NUMBER
705
ERROR INVALID AUTH STATE
707
X.25 diagnostic indication.
708
The account has expired.
709
Error changing password on domain.
710
Serial overrun errors were detected while communicating with your modem.
711
RasMan initialization failure. Check the event log.
713
No active ISDN lines are available.
716
The Remote Access IP configuration is unusable.
717
No IP addresses are available in the static pool of Remote Access IP addresses.
718
PPP timeout.
720
No PPP control protocols configured.
721
Remote PPP peer is not responding.
722
The PPP packet is invalid.
723
The phone number, including prefix and suffix, is too long.
726
The IPX protocol cannot be used for dial-out on more than one port at a time.
728
Cannot find an IP adapter bound to Remote Access.
729
SLIP cannot be used unless the IP protocol is installed.
730
Computer registration is not complete.
731
The protocol is not configured.
732
The PPP negotiation is not converging.
733
The PPP control protocol for this network protocol is not available on the server.
734
The PPP link control protocol terminated..
735
The requested address was rejected by the server.
736
The remote computer terminated the control protocol.
737
Loopback detected.
738
The server did not assign an address.
739
The remote server cannot use the Windows NT encrypted password.
740
The TAPI devices configured for Remote Access failed to initialize or were not installed correctly.
741
The local computer does not support encryption.
742
The remote server does not support encryption.
752
A syntax error was encountered while processing a script.
753
The connection could not be disconnected because it was created by the multi-protocol router.
754
The system could not find the multi-link bundle.
755
The system cannot perform automated dial because this connection has a custom dialer specified.
756
This connection is already being dialed.
757
Remote Access Services could not be started automatically. Additional information is provided in the event log.
764
No smart card reader is installed.
765
Internet Connection Sharing cannot be enabled. A LAN connection is already configured with the IP address that is required for automatic IP addressing.
766
A certificate could not be found. Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate.
767
Internet Connection Sharing cannot be enabled. The LAN connection selected as the private network has more than one IP address configured. Please reconfigure the LAN connection with a single IP address before enabling Internet Connection Sharing.
768
The connection attempt failed because of failure to encrypt data.
769
The specified destination is not reachable.
770
The remote computer rejected the connection attempt.
771
The connection attempt failed because the network is busy.
772
The remote computer’s network hardware is incompatible with the type of call requested.
773
The connection attempt failed because the destination number has changed.
774
The connection attempt failed because of a temporary failure. Try connecting again.
775
The call was blocked by the remote computer.
776
The call could not be connected because the remote computer has invoked the Do Not Disturb feature.
777
The connection attempt failed because the modem (or other connecting device on the remote computer is out of order.
778
It was not possible to verify the identity of the server.
780
An attempted function is not valid for this connection.
782
Internet Connection Sharing (ICS and Internet Connection Firewall (ICF cannot be enabled because Routing and Remote Access has been enabled on this computer. To enable ICS or ICF, first disable Routing and Remote Access. For more information about Routing and Remote Access, ICS, or ICF, see Help and Support.
783
Internet Connection Sharing cannot be enabled. The LAN connection selected as the private network is either not present, or is disconnected from the network. Please ensure that the LAN adapter is connected before enabling Internet Connection Sharing.
784
You cannot dial using this connection at logon time, because it is configured to use a user name different than the one on the smart card. If you want to use it at logon time, you must configure it to use the user name on the smart card.
785
You cannot dial using this connection at logon time, because it is not configured to use a smart card. If you want to use it at logon time, you must edit the properties of this connection so that it uses a smart card.
786
The L2TP connection attempt failed because there is no valid machine certificate on your computer for security authentication.
787
The L2TP connection attempt failed because the security layer could not authenticate the remote computer.
788
The L2TP connection attempt failed because the security layer could not negotiate compatible parameters with the remote computer.
789
The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer.
790
The L2TP connection attempt failed because certificate validation on the remote computer failed.
791
The L2TP connection attempt failed because security policy for the connection was not found.
792
The L2TP connection attempt failed because security negotiation timed out.
793
The L2TP connection attempt failed because an error occurred while negotiating security.
794
The Framed Protocol RADIUS attribute for this user is not PPP.
795
The Tunnel Type RADIUS attribute for this user is not correct.
796
The Service Type RADIUS attribute for this user is neither Framed nor Callback Framed.
797
A connection to the remote computer could not be established because the modem was not found or was busy. For further assistance, click More Info or search Help and Support Center for this error number.
798
A certificate could not be found that can be used with this Extensible Authentication Protocol.
799
Internet Connection Sharing (ICS cannot be enabled due to an IP address conflict on the network. ICS requires the host be configured to use 192.168.0.1. Please ensure that no other client on the network is configured to use 192.168.0.1.
800
Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection.
801
This connection is configured to validate the identity of the access server, but Windows cannot verify the digital certificate sent by the server.
802
The card supplied was not recognized. Please check that the card is inserted correctly, and fits tightly.
803
The PEAP configuration stored in the session cookie does not match the current session configuration.
804
The PEAP identity stored in the session cookie does not match the current identity.
805
You cannot dial using this connection at logon time, because it is configured to use logged on user’s credentials.
806
A connection between your computer and the VPN server has been started, but the VPN connection cannot be completed. The most common cause for this is that at least one Internet device (for example, a firewall or a router) between your computer and the VPN server is not configured to allow Generic Routing Encapsulation (GRE) protocol packets. If the problem persists, contact your network administrator or Internet service provider.
807
The network connection between your computer and the VPN server was interrupted. This can be caused by a problem in the VPN transmission and is commonly the result of internet latency or simply that your VPN server has reached capacity. Please try to reconnect to the VPN server. If this problem persists, contact the VPN administrator and analyze quality of network connectivity.
808
The network connection between your computer and the VPN server could not be established because the remote server refused the connection. This is typically caused by a mismatch between the server’s configuration and your connection settings. Please contact the remote server’s Administrator to verify the server configuration and your connection settings.
809
The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g., firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.
810
A network connection between your computer and the VPN server was started, but the VPN connection was not completed. This is typically caused by the use of an incorrect or expired certificate for authentication between the client and the server. Please contact your Administrator to ensure that the certificate being used for authentication is valid.
811
The network connection between your computer and the VPN server could not be established because the remote server is not responding. This is typically caused by a pre-shared key problem between the client and server. A pre-shared key is used to guarantee you are who you say you are in an IP Security (IPSec) communication cycle. Please get the assistance of your administrator to determine where the pre-shared key problem is originating.
812
The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.
813
You have attempted to establish a second broadband connection while a previous broadband connection is already established using the same device or port. Please disconnect the earlier connection and then re-establish the connection.
814
The underlying Ethernet connectivity required for the broadband connection was not found. Please install and enable the Ethernet adapter on your computer via the Network Connections folder before attempting this connection.
815
The broadband network connection could not be established on your computer because the remote server is not responding. This could be caused by an invalid value for the ‘Service Name’ field for this connection. Please contact your Internet Service Provider and inquire about the correct value for this field and update it in the Connection Properties.
816
A feature or setting you have tried to enable is no longer supported by the remote access service.
817
Cannot delete a connection while it is connected.
818
The Network Access Protection (NAP) enforcement client could not create system resources for remote access connections. Some network services or resources might not be available. If the problem persists, disconnect and retry the remote access connection or contact the administrator for the remote access server.
819
The Network Access Protection Agent (NAP Agent) service has been disabled or is not installed on this computer. Some network services or resources might not be available. If the problem persists, disconnect and retry the remote access connection or contact the administrator for the remote access server.
820
The Network Access Protection (NAP) enforcement client failed to register with the Network Access Protection Agent (NAP Agent) service. Some network services or resources might not be available. If the problem persists, disconnect and retry the remote access connection or contact the administrator for the remote access server.
821
The Network Access Protection (NAP) enforcement client was unable to process the request because the remote access connection does not exist. Retry the remote access connection. If the problem persists, make sure that you can connect to the Internet, and then contact the administrator for the remote access server.
822
The Network Access Protection (NAP) enforcement client did not respond. Some network services or resources might not be available. If the problem persists, disconnect and retry the remote access connection or contact the administrator for the remote access server.
823
Received Crypto-Binding TLV is invalid.
824
Crypto-Binding TLV is not received.
825
Point-to-Point Tunnelling Protocol (PPTP) is incompatible with IPv6. Change the type of virtual private network to Layer Two Tunnelling Protocol (L2TP)
Note In this 8255 error message, the word «Tunnelling» is a misspelling for the word «Tunneling.»
826
EAPTLS validation of the cached credentials failed. Please discard cached credentials.
827
The L2TP/IPsec connection cannot be completed because the IKE and AuthIP IPSec Keying Modules service and/or the Base Filtering Engine service is not running. These services are required to establish an L2TP/IPSec connection. Please ensure that these services have been started before dialling the connection
Note In this 827 error message, the word «dialling» is a misspelling for the word «dialing.»
Информация в данной статье относится к следующим продуктам.
• | Windows Vista Business |
• | Windows Vista Enterprise |
• | Windows Vista Home Basic |
• | Windows Vista Home Premium |
• | Windows Vista Ultimate |
Информация взята из базы знаний с сайта корпорации Microsoft
Сегодня, когда вся страна переходит на цифровое телевидение, у пользователей, к сожалению, всё чаще стали возникать какие-либо проблемы с работой телевизоров. Не каждый знает, что делать с возникшими неполадками и почему они появляются, а в обычной инструкции описаны далеко не все возможные случаи. Что делать, если на экране вдруг появилась надпись «SDP services loading failed»? Что такое вообще SDP?
Что делать, если на телевизоре высвечивается sdp services loading failed
С такой проблемой могут столкнуться те, кто пользуется услугами провайдера Ростелеком. В буквальном переводе надпись означает: «загрузка SDP сервисов не удалась». Разберём возможные варианты действий при наличии такой неполадки.
Такая ошибка означает, что связь с сервером была утеряна. В большинстве случаев, это происходит не только у вас, а сразу у нескольких пользователей. Чаще всего у тех, кто находится поблизости — жители одного дома или подъезда. Причин может быть несколько: самая простая и безобидная заключается в ремонтных работах у провайдера. Вполне возможно, что вы просто пропустили предупреждение об этом либо не придали ему значения. Тогда можно подождать некоторое время и всё придёт в норму.
Другой причиной может быть авария или другая неполадка опять же у провайдера. Тогда следует обратиться на горячую линию, чтобы узнать, что случилось и почему потеряна связь с сервером.
ВАЖНО! Обращаться к провайдеру следует, если проблема не устраняется в течение суток. Тогда вы будете уверены, что это не профилактические работы, а неизвестная поломка.
Что такое SDP протокол
Что же такое вообще SPD протокол? Он представляет собой набор правил, контролирующих сессии передачи потоковых данных.
Таким образом описывается сеанс передачи данных. Это описание может включать в себя дату и время его начала, адреса, форматы данных и другие сведения.
SDP является частью SIP-протокола, отвечающего за создание пользовательского сеанса. С его помощью появляется возможность вызовов IP-телефонии, набирающей популярность в последнее время и любое другое обеспечение связи.
SIP работает по схеме «запрос-ответ». Это означает, что от клиентов поступают запросы, а сервер даёт на них ответ.
Обеспечение связи невозможно без SDP, который содержит в себе всю важнейшую информацию, необходимую для установки соединения. Без него телевизор работать не сможет.
Теперь вы знаете, что такое протокол SDP, буквальный перевод которого звучит так: протокол описания сессии, и почему необходима связь с сервером для работы телевизора. Если же на экране появились сведения о том, что такая связь утрачена, паниковать не стоит.
Скорее всего, это не связано с поломкой именно вашего телевизора, а провайдер в ближайшее время устранит все неполадки. Попробуйте обратиться к соседям и выяснить, работает ли у них телевидение, потому что подобные аварии чаще всего затрагивают сразу нескольких пользователей, проживающих поблизости.
SDP (Session Description Protocol) сервера от Ростелекома представляет собой набор правил, который определяет, как могут быть созданы мультимедийные сеансы, чтобы все элементы эффективно участвовали в сессии. В этом контексте сеанс состоит из устройств и серии взаимодействия между ними. Примером может служить видеоконференция, проводимая крупной корпорацией, которая включает в себя участников из нескольких департаментов в различных географических точках.
SDP протокол серверов Ростелекома
SDP протокол на серверах Ростелекома предназначен в первую очередь для использования в крупных глобальных сетях, включая интернет. Тем не менее протокол также может быть запущен в собственных локальных и городских сетях.
В SDP параметры сеанса включают в себя такую информацию, как его имя, дата и время начала, цель, адреса или порты всех конечных точек, форматы данных, которые будут использоваться, а также скорость передачи для эффективного обмена.
Протокол всегда работает в связке с SIP и RTP.
SIP протокол
SIP (Session Initiation Protocol) отвечает за создание пользовательского сеанса, который включает в себя мультимедийные элементы, такие как видео, голос, чат и игры.
Как и HTTP или SMTP, SIP работает на уровне приложений с моделью взаимодействия открытых систем (OSI). Его основная задача – обеспечение возможности связи. SIP способен создавать мультимедийные сессии и вызовы по IP телефонии, а также изменять или прекращать их. Протокол может приглашать участников одноадресных или многоадресных сессий, которые необязательно включают инициатора. SIP поддерживает отображение имен и перенаправление услуг, что позволяет пользователям отправлять и принимать сообщения, а также идентифицировать участников из любого места.
Узнайте, как настроить различные услуги от Ростелекома на TP Link TD W8968.
О внесении и изменении параметров интернет-подключения на D-Link DSL 2540u можно прочитать здесь.
SIP является протоколом по типу запрос-ответ. Здесь подразумеваются запросы от клиентов и ответы от серверов. Участники определяются по URL-адресам SIP.
Запросы могут быть отправлены через любой транспортный протокол, такой как UDP, SCTP или TCP. SIP определяет конечную систему, которая будет использоваться для сеанса, средства массовой коммуникации, параметры информации, а также желание вызываемой стороны участвовать в разговоре. После того как эти данные выясняются, SIP устанавливает параметры соединения на каждом из оборудования участников и приступает к передаче данных, а затем к прекращению вызова.
Интересно! SDP представляет собой составную часть SIP, в которой содержится подробная информация, для установки соединения.
RTP протокол
RTP представляет собой стандартный протокол интернета, который указывает путь для программы управления передачей мультимедийных данных в реальном времени по однопользовательской или многопользовательской сети.
Первоначально упомянутый в Engineering Task Force (IETF), RTP был разработан для транспорта аудиовидео группы в IETF для поддержки видеоконференций с несколькими, географически удаленными участниками. RTP обычно используется в приложениях интернет-телефонии. Протокол сам по себе не гарантирует доставку в реальном времени мультимедийных данных (так как это зависит от характеристик сети). Однако он обеспечивает необходимые средства для достижения максимально эффективного управления данными.
RTP сочетает в себе передачу данных с протоколом управления (RTCP), что дает возможность контролировать доставку пакетов для больших групповых сетей. Мониторинг позволяет приемнику обнаружить наличие потери данных. Оба протокола работают независимо от параметров базового сетевого уровня. Информация, содержащаяся в заголовке RTP сообщает приемнику о том, как восстановить данные, и описывает, какие кодеки имеют пакеты. Как правило, RTP работает поверх User Datagram Protocol (UDP), хотя используются и другие транспортные средства.
Интересно! Протокол инициирования сеанса связи (SIP) использует информация поступающую от RTP. В свою очередь, SDP работает в составе SIP.
Компоненты RTP включают:
- порядковый номер, который используется для обнаружения потерянных пакетов;
- идентификацию полезной нагрузки, которая описывает конкретные кодирования медиафайлов таким образом, что они могут быть изменены, если должны адаптироваться к пропускной способности;
- кадровую идентификацию, которая сообщает о начале и конце каждого пакета;
- идентификацию источника, которая определяет отправителя пакета;
- синхронизацию фрагментов мультимедиа, которая использует временные метки для обнаружения и компенсации задержек в одном потоке.
Ошибка SDP Ростелекома: services loading failed
Если вы столкнулись при работе в сети Ростелекома с ошибкой SDP – services loading failed, это означает что связь с сервером отсутствует. Чаще всего проблема возникает глобально, то есть не у одного пользователя, а у всего дома или его части. Такое поведение объясняется ремонтными или профилактическими работами, проводимыми провайдером. В этом случае подождите несколько часов до завершения обслуживания оборудования. Если же проблема присутствует на протяжении более одних суток, нужно обращаться к оператору при помощи телефонов горячей линии. Провайдер либо сообщит о проведении работ, либо составит заявку на вызов мастера для ремонта неисправности.
Достоинства, недостатки и особенности прошивки роутера D-Link DPN R5402 от Ростелекома.
О подключении пакета каналов Amedia Premium можно прочитать тут.
Протокол SDP является составной частью SIP, которая, в свою очередь, работает на основе данных RTP. Комплект технологий позволяет добиться корректной работы всех услуг, поставляемых через глобальные и местные сети.
Sdp services loading failed ростелеком что значит?
SDP протокол на серверах Ростелекома предназначен в первую очередь для использования в крупных глобальных сетях, включая интернет. Тем не менее протокол также может быть запущен в собственных локальных и городских сетях.
В SDP параметры сеанса включают в себя такую информацию, как его имя, дата и время начала, цель, адреса или порты всех конечных точек, форматы данных, которые будут использоваться, а также скорость передачи для эффективного обмена.
Протокол всегда работает в связке с SIP и RTP.
SIP протокол
SIP (Session Initiation Protocol) отвечает за создание пользовательского сеанса, который включает в себя мультимедийные элементы, такие как видео, голос, чат и игры.
Как и HTTP или SMTP, SIP работает на уровне приложений с моделью взаимодействия открытых систем (OSI). Его основная задача – обеспечение возможности связи. SIP способен создавать мультимедийные сессии и вызовы по IP телефонии, а также изменять или прекращать их. Протокол может приглашать участников одноадресных или многоадресных сессий, которые необязательно включают инициатора. SIP поддерживает отображение имен и перенаправление услуг, что позволяет пользователям отправлять и принимать сообщения, а также идентифицировать участников из любого места.
SIP является протоколом по типу запрос-ответ. Здесь подразумеваются запросы от клиентов и ответы от серверов. Участники определяются по URL-адресам SIP.
Запросы могут быть отправлены через любой транспортный протокол, такой как UDP, SCTP или TCP. SIP определяет конечную систему, которая будет использоваться для сеанса, средства массовой коммуникации, параметры информации, а также желание вызываемой стороны участвовать в разговоре. После того как эти данные выясняются, SIP устанавливает параметры соединения на каждом из оборудования участников и приступает к передаче данных, а затем к прекращению вызова.
RTP протокол
RTP представляет собой стандартный протокол интернета, который указывает путь для программы управления передачей мультимедийных данных в реальном времени по однопользовательской или многопользовательской сети.
Первоначально упомянутый в Engineering Task Force (IETF), RTP был разработан для транспорта аудиовидео группы в IETF для поддержки видеоконференций с несколькими, географически удаленными участниками. RTP обычно используется в приложениях интернет-телефонии. Протокол сам по себе не гарантирует доставку в реальном времени мультимедийных данных (так как это зависит от характеристик сети). Однако он обеспечивает необходимые средства для достижения максимально эффективного управления данными.
RTP сочетает в себе передачу данных с протоколом управления (RTCP), что дает возможность контролировать доставку пакетов для больших групповых сетей. Мониторинг позволяет приемнику обнаружить наличие потери данных. Оба протокола работают независимо от параметров базового сетевого уровня. Информация, содержащаяся в заголовке RTP сообщает приемнику о том, как восстановить данные, и описывает, какие кодеки имеют пакеты. Как правило, RTP работает поверх User Datagram Protocol (UDP), хотя используются и другие транспортные средства.
Компоненты RTP включают:
порядковый номер, который используется для обнаружения потерянных пакетов;
идентификацию полезной нагрузки, которая описывает конкретные кодирования медиафайлов таким образом, что они могут быть изменены, если должны адаптироваться к пропускной способности;
кадровую идентификацию, которая сообщает о начале и конце каждого пакета;
идентификацию источника, которая определяет отправителя пакета;
синхронизацию фрагментов мультимедиа, которая использует временные метки для обнаружения и компенсации задержек в одном потоке.
Ошибка SDP Ростелекома: services loading failed
Если вы столкнулись при работе в сети Ростелекома с ошибкой SDP – services loading failed, это означает что связь с сервером отсутствует. Чаще всего проблема возникает глобально, то есть не у одного пользователя, а у всего дома или его части. Такое поведение объясняется ремонтными или профилактическими работами, проводимыми провайдером. В этом случае подождите несколько часов до завершения обслуживания оборудования. Если же проблема присутствует на протяжении более одних суток, нужно обращаться к оператору при помощи телефонов горячей линии. Провайдер либо сообщит о проведении работ, либо составит заявку на вызов мастера для ремонта неисправности.
Протокол SDP является составной частью SIP, которая, в свою очередь, работает на основе данных RTP. Комплект технологий позволяет добиться корректной работы всех услуг, поставляемых через глобальные и местные сети.
Ответы на часто задаваемые вопросы
Общие сведения о протоколе описания сеанса (SDP)
Невозможно по-настоящему понять протокол SIP без понимания его кузена, протокола описания сеанса (SDP). В то время как SIP занимается установлением, изменением и разрывом сеансов, SDP занимается исключительно носителями в рамках этих сеансов. То, что SIP переводит носители в другой протокол, не случайно. Создатели SIP решили сделать его агностическим для СМИ, и это разделение церкви и государства только усиливает это.SIP делает то, что умеет лучше всего, и оставляет носители для SDP.
Итак, что такое SDP? Ну, это именно то, что написано в названии. Это протокол, который описывает медиа сеанса. Важно понимать, что это не переговоры со СМИ. SIP-клиенты не используют его, чтобы возвращаться и спрашивать: «А вы можете это сделать?» прежде, чем окончательно остановиться на общем медиа-протоколе, таком как G.711. Вместо этого одна сторона говорит другой стороне: «Вот все типы носителей, которые я могу поддерживать — выберите один и используйте его.”
SDP состоит из серии строк
SDP состоит из трех основных разделов — описания сеанса, времени и медиа. Каждое сообщение может содержать несколько описаний хронирования и мультимедиа, но только одно описание сеанса.
Ниже приведены определения этих разделов и их возможное содержание. Важно знать, что не все символы / значения могут присутствовать в сообщении SDP.
Описание сеанса
v = (номер версии протокола, в настоящее время только 0)
o = (инициатор и идентификатор сеанса: имя пользователя, идентификатор, номер версии, сетевой адрес)
s = (имя сеанса: обязательно с хотя бы одним символом в кодировке UTF-8)
i = * (название сеанса или краткая информация)
u = * (URI описания)
e = * (ноль или более адресов электронной почты с дополнительными именами контактов)
p = * (ноль или более телефонных номеров с дополнительными именами контактов)
c = * (информация о подключении — не требуется, если присутствует на всех носителях)
b = * (ноль или более строк информации о пропускной способности)
Одно или несколько описаний времени (строки «t =» и «r =»; см. Ниже)
z = * (корректировка часового пояса)
k = * (ключ шифрования)
a = * (ноль или более строк атрибутов сеанса)
Ноль или более описаний носителей (каждое начинается со строки «m =»; см. Ниже)
Временное описание (обязательно)
t = (время активности сеанса)
r = * (ноль или более повторений)
Описание носителя (при наличии)
m = (имя носителя и транспортный адрес)
i = * (заголовок носителя или информационное поле)
c = * (информация о подключении — необязательно, если включена на уровне сеанса)
b = * (ноль или более строк информации о пропускной способности)
k = * (ключ шифрования)
a = * (ноль или более строк атрибутов мультимедиа — переопределение строк атрибутов сеанса)
Например,
Ниже приведен пример реального сообщения SDP.
v = 0
o = Эндрю 2890844526 2890844526 IN IP4 10.120.42.3
s = Блог SDP
c = IN IP4 10.120.42.3
т = 0 0
m = аудио 49170 RTP / AVP 0 8 97
a = rtpmap: 0 PCMU / 8000
a = rtpmap: 8 PCMA / 8000
a = rtpmap: 97 iLBC / 8000
м = видео 51372 RTP / AVP 31 32
a = rtpmap: 31 ч 361/
Если вы не работали с SIP и SDP какое-то время, это, вероятно, будет выглядеть непонятно.Однако это действительно не так уж и плохо, если вы знаете, что искать, а что можно спокойно игнорировать. Это то, на что я обращаю внимание в сообщении SDP.
c = Это сообщит мне IP-адрес, откуда будет поступать носитель и куда он должен быть отправлен.
m = Для каждого типа носителя будет отдельная строка. Например, если ваш клиент может поддерживать звук в реальном времени, будет строка m = audio. Если ваш клиент может поддерживать видео в реальном времени, будет отдельная строка m = video. Каждая строка мультимедиа указывает количество кодеков, которые будут определены в строках атрибутов.
a = Будет строка атрибутов для каждого кодека, объявленного в строке мультимедиа.
Глядя на приведенный выше пример, я сразу это вижу.
Клиент будет использовать IP версии 4 с адресом 10.120.42.3. Он может поддерживать три аудиокодека и один видеокодек. Аудиокодеки: G.711 uLaw (PCMU), G.711 aLaw (PCMA) и iLBC. Аудиокодеки будут использовать порт 49170 и все будут иметь частоту дискретизации 8000 Гц. Видеокодек — H.261 на порту 51327. В 99,9% случаев я могу спокойно игнорировать любые другие значения SDP, которые могут присутствовать.
После получения сообщения SIP с указанным выше SDP в теле сообщения получатель ответит собственным SDP с указанием своего IP-адреса, портов и значений кодека. Получатель также выберет из списка кодеков отправителя, какие из них он будет использовать, и потенциально запустит медиапотоки в реальном времени. Неписаное правило SDP состоит в том, что если возможно, вы должны использовать первый кодек указанного типа, но это не обязательно. Если отправитель говорит, что может что-то сделать, ему лучше быть готовым к работе с носителями этого типа, независимо от того, в каком порядке они были перечислены.
Надеюсь, это поможет разобраться в том, что может показаться трудным предметом. Если возможно, возьмите несколько следов Wireshark нескольких вызовов SIP и посмотрите, сможете ли вы выяснить, как описываются и используются носители.
Между прочим, это 50-я статья, которую я написал для этого блога. Поздравления мне.
Нравится:
Нравится Загрузка …
Связанные
Что означает SDP?
SDP Описание сеанса Протокол
Вычисления »Сети — и многое другое…
Оцените:
SDP Социал-демократическая партия
Правительственная »Политика
29 2 SDP Процесс разработки программного обеспечения
Вычислительная техника »Программное обеспечение
Оцените это:
SDP 9 — План разработки программного обеспечения для правительства
Правительство…
Оцените:
SDP Стратегический план развития
Правительство »Правительство США
SDP Полуопределенное программирование
Академические и естественные науки »Математика
Оцените это:
9000 SDP Протокол Оценить:
SDP Service Discovery Protocol
Разное »Несекретный
29 29 SDP Доставка программного обеспечения ry Платформа
Вычислительная техника »Программное обеспечение
Оцените:
SDP Социалистическая демократическая партия
Правительство» Политика
it:
SDP Самый крутой спуск
Sports
Оцените его:
SDP 9129 9129 9129 9129 9129 9129
Оцените:
SDP Процесс разработки систем
Правительство »Военное дело
SDP SunSour ce, Inc.
Business »Символы NYSE
Оцените его:
SDP Shelf Discovery Protocol
Computing» Networking Rate
:
SDP Сумма несвязанных продуктов
Разное »Несекретный
Оценить:
Определение сети | Компьютерный протокол | Компьютерные сети
Сетевой протокол — это установленный набор правил, определяющих, как данные передаются между различными устройствами в одной сети.По сути, это позволяет подключенным устройствам обмениваться данными друг с другом, независимо от каких-либо различий в их внутренних процессах, структуре или дизайне. Сетевые протоколы — это причина, по которой вы можете легко общаться с людьми по всему миру, и, таким образом, они играют важную роль в современной цифровой связи.
Подобно тому, как использование одного и того же языка упрощает общение между двумя людьми, сетевые протоколы позволяют устройствам взаимодействовать друг с другом благодаря заранее определенным правилам, встроенным в программное и аппаратное обеспечение устройств.Ни локальные сети (LAN), ни глобальные сети (WAN) не могли бы функционировать так, как они работают сегодня, без использования сетевых протоколов.
Как работают сетевые протоколы
Сетевые протоколы берут крупномасштабные процессы и разбивают их на небольшие конкретные задачи или функции. Это происходит на каждом уровне сети, и каждая функция должна взаимодействовать на каждом уровне для выполнения более крупной задачи. Термин протокол
Пакет относится к набору небольших сетевых протоколов, работающих вместе друг с другом.
Сетевые протоколы обычно создаются в соответствии с отраслевыми стандартами различными организациями, занимающимися сетями или информационными технологиями.
Следующие группы определили и опубликовали различные сетевые протоколы:
Хотя модели сетевых протоколов обычно работают одинаково, каждый протокол уникален и работает определенным образом, определенным организацией, создавшей его.
Кто использует сетевые протоколы?
Сетевые протоколы актуальны не только для сертифицированных сетевых специалистов или ИТ-специалистов.Миллиарды людей ежедневно используют сетевые протоколы, знают ли они
это или нет.
Каждый раз, когда вы пользуетесь Интернетом, вы используете сетевые протоколы. Хотя вы можете не знать, как работают сетевые протоколы или как часто вы с ними сталкиваетесь, они необходимы для использования Интернета или цифровых коммуникаций в любом качестве.
Список сетевых протоколов
Существуют тысячи различных сетевых протоколов, но все они выполняют одно из трех основных действий:
Каждый тип необходим для быстрого и безопасного использования сетевых устройств, и они работают вместе, чтобы облегчить это использование.
Связь
Протоколы связи позволяют различным сетевым устройствам обмениваться данными друг с другом. Они используются как в аналоговой, так и в цифровой связи и могут использоваться для важных процессов, начиная от передачи файлов между устройствами и заканчивая доступом в Интернет.
Общие типы протоколов связи включают следующие:
- Автоматизация : Эти протоколы используются для автоматизации различных процессов как в коммерческих, так и в личных целях, например, в интеллектуальных зданиях, облачных технологиях или беспилотных автомобилях.
- Мгновенный обмен сообщениями : Мгновенное текстовое общение на смартфонах и компьютерах происходит из-за множества различных сетевых протоколов обмена мгновенными сообщениями.
- Маршрутизация : Протоколы маршрутизации разрешают обмен данными между маршрутизаторами и другими сетевыми устройствами. Также существуют протоколы маршрутизации специально для одноранговых сетей.
- Bluetooth : Все популярные устройства Bluetooth, включая гарнитуры, смартфоны и компьютеры, работают благодаря множеству различных протоколов Bluetooth.
- Передача файлов : Если вы когда-либо перемещали файлы с одного устройства на другое через физический или цифровой носитель, вы использовали протоколы передачи файлов (FTP).
- Интернет-протокол : Интернет-протокол (IP) позволяет передавать данные между устройствами через Интернет. Интернет не мог работать, как сейчас, без IP.
Управление сетью
Протоколы управления сетью определяют и описывают различные процедуры, необходимые для эффективной работы компьютерной сети.Эти протоколы влияют на различные устройства в одной сети, включая компьютеры, маршрутизаторы и серверы, чтобы гарантировать, что каждое
one и сеть в целом работают оптимально.
Протоколы управления сетью выполняют следующие функции:
- Соединение : Эти протоколы устанавливают и поддерживают стабильные соединения между различными устройствами в одной сети.
- Объединение каналов : Протоколы объединения каналов позволяют объединить несколько сетевых подключений в одно соединение между двумя устройствами.Это увеличивает надежность соединения и помогает поддерживать соединение в случае сбоя одного из каналов.
- Устранение неполадок : протоколы устранения неполадок позволяют сетевым администраторам выявлять ошибки, влияющие на сеть, оценивать качество сетевого соединения и определять, как администраторы могут исправить любые проблемы.
Безопасность
Протоколы безопасности, также называемые криптографическими протоколами, обеспечивают защиту сети и передаваемых по ней данных от неавторизованных пользователей.
Общие функции сетевых протоколов безопасности включают следующее:
- Шифрование : Протоколы шифрования защищают данные и безопасные области, требуя от пользователей ввода секретного ключа или p
RFC 2327 — SDP: протокол описания сеанса (RFC2327 )
Сетевая рабочая группа М. Хэндли
Запрос комментариев: 2327 В. Якобсон
Категория: Стандарты Track ISI / LBNL
Апрель 1998 SDP: протокол описания сеанса Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
Официальные стандарты протокола »(STD 1) для состояния стандартизации
и статус этого протокола. Распространение памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Аннотация Этот документ определяет протокол описания сеанса SDP. SDP - это
предназначен для описания мультимедийных сеансов в целях
объявление о сеансе, приглашение на сеанс и другие формы
инициирование мультимедийной сессии.Этот документ является продуктом многосторонней мультимедийной сессии.
Контрольная (MMUSIC) рабочая группа инженерного задания Интернета
Force. Комментарии запрашиваются и должны быть адресованы работающим
список рассылки группы по адресу [email protected] и / или авторов. 1. Введение В магистрали многоадресной передачи в Интернете (Mbone), инструмент каталога сеансов
используется для рекламы мультимедийных конференций и сообщения
адреса конференций и информация о средствах конференции
необходимо для участия.Этот документ определяет сеанс
протокол описания для этой цели и для общего режима реального времени
цели описания мультимедийной сессии. Эта памятка не описывает
выделение многоадресных адресов или распространение сообщений SDP в
деталь. Они описаны в сопроводительных памятках. SDP не
предназначен для согласования кодировок медиа. 2. Справочная информация Mbone - это часть Интернета, которая поддерживает многоадресную IP-рассылку, и
таким образом, обеспечивается эффективная связь "многие ко многим".Это использовано
широко используется для мультимедийных конференций. Такие конференции обычно
обладают тем свойством, что тесная координация членства в конференции
не обязательно; для приема конференции пользователь только на сайте Mbone
должен знать адрес многоадресной группы конференции и UDP
порты для потоков данных конференции. Каталоги сеансов помогают рекламировать сеансы конференции
и передать соответствующую информацию о настройке конференции
потенциальные участники.SDP предназначен для передачи такой информации
получателям. SDP - это чисто формат описания сеанса - это
не включает транспортный протокол и предназначен для использования
различные транспортные протоколы в зависимости от ситуации, включая сеанс
Протокол объявления [4], Протокол инициирования сеанса [11], Real-
Протокол потоковой передачи времени [12], электронная почта с использованием MIME
расширения и протокол передачи гипертекста. SDP предназначен для общего назначения, поэтому его можно использовать для
более широкий спектр сетевых сред и приложений, чем просто
каталоги многоадресных сеансов.Однако он не предназначен для
поддерживать согласование содержимого сеанса или кодировок мультимедиа - это
рассматривается как выходящий за рамки описания сеанса. 3. Глоссарий терминов Следующие термины используются в этом документе и имеют определенные
значение в контексте этого документа. Конференция
Мультимедийная конференция - это набор двух или более общающихся пользователей.
вместе с программным обеспечением, которое они используют для общения. Сессия
Мультимедийный сеанс - это набор отправителей и получателей мультимедиа.
и потоки данных, текущие от отправителей к получателям.А
мультимедийная конференция - это пример мультимедийного сеанса. Реклама сеанса
См. Объявление о сеансе. Объявление о сессии
Объявление сеанса - это механизм, с помощью которого сеанс
описание передается пользователям в упреждающем режиме, т. е.
Описание сеанса не было запрошено пользователем явным образом. Описание сеанса
Четко определенный формат для передачи достаточной информации
открыть для себя мультимедийный сеанс и участвовать в нем. 3.1. Терминология Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
документ следует интерпретировать, как описано в RFC 2119. 4. Использование SDP 4.1. Объявления Multicast SDP - это протокол описания сеанса для мультимедийных сеансов. А
общий режим использования - объявление клиентом сеанса конференции
путем периодической многоадресной рассылки пакета объявлений общеизвестному
многоадресный адрес и порт с использованием протокола объявления сеанса
(SAP).Пакеты SAP - это пакеты UDP со следующим форматом: | -------------------- |
| Заголовок SAP |
| -------------------- |
| текстовые данные |
| ////////// Заголовок - это заголовок протокола объявления сеанса. SAP - это
более подробно описано в сопроводительной записке [4] Текстовые данные - это описание сеанса SDP, как описано в этом
памятка. Текстовые данные не должны превышать 1 Кбайт в длину.
Если объявлено SAP, только одно объявление сеанса разрешено в
один пакет.4.2. Объявления по электронной почте и в Интернете Альтернативные средства передачи описаний сеансов включают:
электронная почта и всемирная паутина. И для электронной почты, и для WWW
распространение, использование типа содержимого MIME "application / sdp"
должен быть использован. Это позволяет автоматически запускать приложения.
для участия в сеансе из WWW клиента или читателя почты
стандартным образом. Обратите внимание, что объявления о многоадресных сеансах делаются только по электронной почте или
Всемирная паутина (WWW) не имеет свойства, что получатель
объявления сеанса может обязательно получить сеанс, потому что
многоадресные сеансы могут быть ограничены по объему, и доступ к
За пределами этой области возможен WWW-сервер или прием электронной почты.SAP
объявления не страдают от этого несоответствия. 5. Требования и рекомендации Цель SDP - передать информацию о медиапотоках в
мультимедийные сеансы, чтобы позволить получателям описания сеанса
участвовать в сеансе. SDP в первую очередь предназначен для использования в
межсетевое взаимодействие, хотя оно достаточно общее, чтобы
описывать конференции в других сетевых средах. Мультимедийный сеанс для этих целей определяется как набор
медиапотоки, существующие в течение некоторого времени.Медиа потоки
может быть "многие ко многим". Время, в течение которого сеанс активен
не обязательно быть непрерывным. До сих пор сеансы многоадресной рассылки в Интернете отличались от
многие другие формы конференц-связи, в которых каждый получает трафик
может присоединиться к сеансу (если трафик сеанса не зашифрован). В
В такой среде SDP служит двум основным целям. Это средство
сообщить о существовании сеанса и является средством передачи
достаточная информация, чтобы можно было присоединиться и участвовать в
сеанс.В одноадресной среде вероятна только последняя цель.
быть актуальным. Таким образом, SDP включает: o Название и цель сеанса o Время (а) активности сеанса o СМИ, составляющие сессию o Информация для получения этих носителей (адреса, порты, форматы и
скоро) Поскольку ресурсы, необходимые для участия в сеансе, могут быть ограничены,
Также может потребоваться дополнительная информация: o Информация о пропускной способности, которая будет использоваться конференцией o Контактная информация лица, ответственного за сеанс Как правило, SDP должен передавать достаточно информации, чтобы иметь возможность присоединиться
сеанс (с возможным исключением ключей шифрования) и
объявлять ресурсы, которые будут использоваться неучастниками, которые могут нуждаться в
знать.5.1. Информация для СМИ SDP включает: o Тип носителя (видео, аудио и т. д.) o Транспортный протокол (RTP / UDP / IP, H.320 и т. д.) o Формат носителя (видео H.261, видео MPEG и т. д.) Для сеанса многоадресной IP-рассылки также передаются следующие данные: o Многоадресный адрес для СМИ o Транспортный порт для СМИ Этот адрес и порт являются адресом и местом назначения.
порт многоадресного потока, будь то отправленный, полученный или и то, и другое. Для одноадресного IP-сеанса передаются следующие данные: o Удаленный адрес для СМИ o Транспортный порт для контактного адреса Семантика этого адреса и порта зависит от носителя и
транспортный протокол определен.По умолчанию это удаленный адрес
и удаленный порт, на который отправляются данные, а также удаленный адрес и
локальный порт для приема данных. Однако некоторые СМИ могут определять
использовать их для создания канала управления фактическими медиа
течь. 5.2. Информация о времени Сеансы могут быть как ограниченными, так и неограниченными по времени. Так или иначе
они ограничены, они могут быть активны только в определенное время. SDP может передавать: o Произвольный список времени начала и окончания сеанса o Для каждого маршрута повторите раз, например «каждую среду в 10:00 для
один час" Эта информация о времени согласована на глобальном уровне, независимо от местного
часовой пояс или летнее время.5.3. Частные сеансы Можно создавать как открытые, так и частные сеансы.
Частные сеансы обычно передаются путем шифрования сеанса
описание для распространения. Детали того, как шифрование
выполняются, зависят от механизма, используемого для передачи SDP - см. [4]
как это делается для объявлений о сеансе. Если объявление о сеансе является частным, можно использовать это
частное объявление для передачи ключей шифрования, необходимых для декодирования
каждое из средств массовой информации на конференции, включая достаточно информации, чтобы
знать, какая схема шифрования используется для каждого носителя.5.4. Получение дополнительной информации о сеансе Описание сеанса должно содержать достаточно информации, чтобы решить
стоит ли участвовать в сеансе. SDP может включать
дополнительные указатели в виде универсальных идентификаторов ресурсов
(URI) для получения дополнительной информации о сеансе. 5.5. Категоризация Когда многие описания сеансов распространяются SAP или какой-либо другой
другой рекламный механизм, может быть желательно фильтровать
объявления, которые представляют интерес, от тех, кого нет.SDP
поддерживает механизм категоризации для сеансов, способный
автоматизируется. 5.6. Интернационализация Спецификация SDP рекомендует использовать символ ISO 10646.
устанавливает в кодировке UTF-8 (RFC 2044), чтобы разрешить множество различных
представляемые языки. Однако, чтобы помочь в компактном
представления, SDP также допускает другие наборы символов, такие как ISO
8859-1 для использования при желании. Интернационализация применяется только к
поля произвольного текста (имя сеанса и справочная информация), а не
к SDP в целом.6. Спецификация SDP Описания сеансов SDP полностью текстовые с использованием ISO 10646
набор символов в кодировке UTF-8. Имена полей SDP и имена атрибутов
использовать только US-ASCII подмножество UTF-8, но текстовые поля и
значения атрибутов могут использовать полный набор символов ISO 10646. В
текстовая форма, в отличие от двоичной кодировки, такой как ASN / 1 или XDR, был выбран для повышения мобильности, чтобы можно было использовать различные виды транспорта.
для использования (например, описание сеанса в сообщении электронной почты MIME) и для
позволяют гибкие текстовые наборы инструментов (например,g., Tcl / Tk) для использования
генерировать и обрабатывать описания сеансов. Однако поскольку
общая пропускная способность, выделенная для всех объявлений SAP, строго
ограничено, кодировка намеренно компактна. Кроме того, поскольку
объявления могут передаваться очень ненадежными средствами (например,
email) или поврежден промежуточным сервером кэширования, кодировка была
разработан с соблюдением строгих правил порядка и форматирования, поэтому большинство ошибок
приведет к искаженным объявлениям, которые могут быть обнаружены
легко и выбрасывается.Это также позволяет быстро отбрасывать зашифрованные
объявления, для которых у получателя нет правильного ключа. Описание сеанса SDP состоит из нескольких строк текста
форма = всегда состоит из одного символа и
регистрационный. <значение> - это структурированная текстовая строка, формат которой
зависит от <тип>. Это также будет иметь регистр, если
конкретное поле определяет иное. Пробелы также не допускаются
сторона знака `= '.В общем, <значение> - это либо количество полей
разделенные одним пробелом или строкой свободного формата. Описание сеанса состоит из описания уровня сеанса
(подробности, относящиеся ко всему сеансу и всем медиапотокам) и
необязательно несколько описаний на уровне носителя (подробности, относящиеся к
в один медиапоток). Объявление состоит из раздела уровня сеанса, за которым следует ноль
или несколько разделов на уровне СМИ. Часть уровня сеанса начинается с
`v = 'и продолжается до первого раздела уровня носителя.СМИ
описание начинается со строки `m = 'и продолжается до следующего носителя
описание или конец всего описания сеанса. В общем,
значения уровня сеанса являются значениями по умолчанию для всех носителей, если они не переопределены
эквивалентным значением на уровне СМИ. Когда SDP передается SAP, допускается только одно описание сеанса
за пакет. Когда SDP передается другими способами, многие сеансы SDP
описания могут быть объединены вместе (строка `v = 'указывает
начало описания сеанса завершает предыдущий
описание).Некоторые строки в каждом описании являются обязательными, а некоторые
являются необязательными, но все они должны появляться в точном порядке, указанном здесь (
фиксированный порядок значительно улучшает обнаружение ошибок и позволяет
парсер). Необязательные элементы отмечены знаком «*». Описание сеанса
v = (версия протокола)
o = (владелец / создатель и идентификатор сеанса).
s = (имя сеанса)
i = * (информация о сеансе) u = * (URI описания)
e = * (адрес электронной почты)
p = * (номер телефона)
c = * (информация о подключении - не требуется, если присутствует на всех носителях)
b = * (информация о пропускной способности)
Одно или несколько временных описаний (см. Ниже)
z = * (настройки часового пояса)
k = * (ключ шифрования)
a = * (ноль или более строк атрибутов сеанса)
Ноль или более описаний носителей (см. Ниже) Описание времени
t = (время активности сеанса)
r = * (ноль или более повторений) Описание СМИ
m = (имя носителя и транспортный адрес)
i = * (заголовок медиа)
c = * (информация о подключении - необязательно, если включена на уровне сеанса)
b = * (информация о пропускной способности)
k = * (ключ шифрования)
a = * (ноль или более строк атрибутов мультимедиа) Набор "типовых" букв намеренно маленький и не предназначен для
быть расширяемыми - парсеры SDP должны полностью игнорировать любые объявления
который содержит "типичную" букву, которую он не понимает.В
механизм "attribute" ("a =", описанный ниже) является основным средством для
расширение SDP и адаптация его к конкретным приложениям или носителям.
Некоторые атрибуты (перечисленные в этом документе) имеют определенные
значение, но другие могут быть добавлены в приложении, медиа или
сессионно-зависимая основа. Каталог сеанса должен игнорировать любые
атрибут не понимает. Информация о соединении (`c = ') и атрибуте (` a =') в
Раздел уровня сеанса применяется ко всем носителям этого сеанса, если только
переопределено информацией о соединении или одноименным атрибутом
в описании СМИ.Например, в приведенном ниже примере каждый
media ведет себя так, как если бы ему был присвоен атрибут recvonly. Пример описания SDP: v = 0
o = mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s = Семинар SDP
i = Семинар по протоколу описания сеанса
u = http: //www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected] (Марк Хэндли)
c = В IP4 224.2.17.12/127 т = 2873397496 2873404696
a = recvonly
m = аудио 49170 RTP / AVP 0
m = видео 51372 RTP / AVP 31
m = приложение 32416 udp wb
a = orient: портрет Текстовые записи, такие как имя сеанса и информация, являются байтами.
строки, которые могут содержать любой байт, за исключением 0x00 (Nul),
0x0a (перевод строки ASCII) и 0x0d (возврат каретки ASCII).Последовательность
CRLF (0x0d0a) используется для завершения записи, хотя парсеры должны быть
толерантный, а также принимать записи, заканчивающиеся одной новой строкой
персонаж. По умолчанию эти байтовые строки содержат ISO-10646
символы в кодировке UTF-8, но это значение по умолчанию можно изменить с помощью
атрибут charset. Версия протокола v = 0 В поле «v =» указывается версия протокола описания сеанса.
Дополнительного номера версии нет. Происхождение o = <имя пользователя> <идентификатор сеанса> <версия> <тип сети> <тип адреса> <адрес> В поле «o =» указывается инициатор сеанса (его имя пользователя
и адрес хоста пользователя) плюс идентификатор сеанса и сеанс
номер версии. - логин пользователя на исходном хосте, или это "-"
если исходный хост не поддерживает концепцию идентификаторов пользователей. <имя пользователя> не должно содержать пробелов. <идентификатор сеанса> - числовая строка
так что кортеж , , , <тип адреса> и <адрес> образуют глобальный уникальный идентификатор для
сессия. Метод выделения зависит от инструмента создания, но
было предложено, чтобы временная метка сетевого протокола времени (NTP) была
используется для обеспечения уникальности [1].<версия> - это номер версии этого объявления. Необходимо
для объявлений прокси, чтобы определить, какое из нескольких объявлений для
тот же сеанс является самым последним. И снова его использование зависит от инструмент создания, если <версия> увеличивается при модификации
вносится в данные сеанса. Опять же, рекомендуется (но не
обязательно), что используется метка времени NTP. <тип сети> - это текстовая строка, указывающая тип сети.
Первоначально «IN» означает «Интернет».<адрес
type> - текстовая строка, указывающая тип следующего адреса.
Изначально определены «IP4» и «IP6». <адрес> - это глобальный
уникальный адрес машины, с которой был создан сеанс.
Для типа адреса IP4 это либо полный домен
имя машины или десятичное представление IP с разделителями
версия 4 адрес машины. Для типа адреса IP6 это
- это либо полное доменное имя машины, либо
сжатое текстовое представление IP-адреса версии 6
машина.И для IP4, и для IP6 полное доменное имя
форма, которую ДОЛЖЕН быть предоставлен, если он не доступен, в котором
В этом случае может быть заменен глобально уникальный адрес. Локальный IP
адрес НЕ ДОЛЖЕН использоваться в любом контексте, где описание SDP
может покинуть область, в которой адрес имеет смысл. Как правило, поле «o =» служит глобальным уникальным идентификатором для
эта версия этого описания сеанса и подполя, кроме
вместе взятые версии идентифицируют сеанс независимо от
модификации.Имя сеанса s = <имя сеанса> Поле «s =» - это имя сеанса. Должен быть один и только один
Поле "s =" для описания сеанса, и оно должно содержать ISO 10646.
символы (но см. также атрибут charset ниже). Информация о сессии и СМИ i = <описание сеанса> Поле «i =» - это информация о сеансе. Может быть в
максимум одно поле "i =" уровня сеанса на описание сеанса, и на
максимум одно поле "i =" на носитель. Хотя его можно опустить, это
не рекомендуется для объявлений о сеансах, а пользовательские интерфейсы для
создание сессий должно требовать ввода текста.Если это
присутствует он должен содержать символы ISO 10646 (но см. также
атрибут charset ниже). Для каждого определения мультимедиа также можно использовать одно поле «i =». В
определения мультимедиа, поля "i =" в первую очередь предназначены для маркировки
медиапотоки. Таким образом, они, скорее всего, будут полезны, когда один сеанс имеет более одного отдельного медиапотока одного и того же
тип носителя. Примером могут служить две разные доски, одна для
слайды и один для отзывов и вопросов.URI u = o URI - это универсальный идентификатор ресурса, используемый клиентами WWW. o URI должен быть указателем на дополнительную информацию о
конференция o Это поле не является обязательным, но если оно есть, его следует указать
перед первым медиа-полем o В описании сеанса допускается не более одного поля URI. Адрес электронной почты и номер телефона e = <адрес электронной почты> p = <номер телефона> o В них указывается контактная информация лица, ответственного за
конференция.Это не обязательно тот же человек, что
создал анонс конференции. o Необходимо указать либо поле электронной почты, либо поле телефона.
Допускаются дополнительные поля электронной почты и телефона. o Если они есть, их следует указать перед первым
медиа-поле. o Для сеанса можно указать несколько полей электронной почты или телефона
описание. o Номера телефонов следует указывать в общепринятом международном формате. формат - перед знаком "+" и международным кодом страны.Между кодом страны должен быть пробел или дефис ("-").
и остальной телефонный номер. Можно использовать пробелы и дефисы
чтобы при желании разделить поле телефона для облегчения чтения. За
пример: p = + 44-171-380-7777 или p = + 1 617 253 6011 o Как для адресов электронной почты, так и для номеров телефонов могут быть установлены дополнительные бесплатные
текстовая строка, связанная с ними, обычно дающая имя
человек, с которым можно связаться. Это должно быть заключено в
круглые скобки, если они есть.Например: [email protected] (Марк Хэндли) Альтернативное соглашение о цитировании имен RFC822 также разрешено для
адреса электронной почты и номера телефонов. Например, e = Марк Хэндли Свободная текстовая строка должна быть в наборе символов ISO-10646 с
Кодировка UTF-8 или, альтернативно, в ISO-8859-1 или других кодировках
если установлен соответствующий атрибут charset уровня сеанса. Данные подключения c = <тип сети> <тип адреса> <адрес подключения> Поле «c =» содержит данные подключения.Объявление сеанса должно содержать одно поле «c =» в каждом носителе.
описание (см. ниже) или поле «c =» на уровне сеанса. Это может
содержать поле "c =" уровня сеанса и одно дополнительное поле "c =" на
описание мультимедиа, и в этом случае значения для каждого носителя имеют приоритет над
настройки уровня сеанса для соответствующих носителей. Первое подполе - это тип сети, который представляет собой текстовую строку.
с указанием типа сети. Первоначально "IN" определяется как
что означает «Интернет». Второе подполе - это тип адреса.Это позволяет использовать SDP
для сеансов, не основанных на IP. В настоящее время определен только IP4. Третье подполе - это адрес подключения. Дополнительная опция
подполя могут быть добавлены после адреса подключения в зависимости от
значение поля <тип адреса>. Для адресов IP4 адрес подключения определяется следующим образом: o Обычно адрес подключения представляет собой многоадресную IP-рассылку класса D. групповой адрес. Если сеанс не является многоадресным, то
адрес подключения содержит полное доменное имя или
одноадресный IP-адрес ожидаемого источника данных или ретранслятора данных, или
приемник данных, определяемый дополнительными полями атрибутов.Нет
ожидается, что полные доменные имена или одноадресные адреса будет дан в описании сеанса, которое передается
многоадресное объявление, хотя это не запрещено. Если
одноадресный поток данных должен проходить через сетевой адрес
переводчик, использование полного доменного имени, а не
РЕКОМЕНДУЕТСЯ одноадресный IP-адрес. В остальных случаях использование
IP-адрес для указания конкретного интерфейса на многосетевом хосте
может потребоваться.Таким образом, эта спецификация оставляет решение как
к которому использовать до отдельного приложения, но все
приложения ДОЛЖНЫ поддерживать прием обоих форматов. o Конференции, использующие адрес многоадресного IP-соединения, также должны иметь
значение времени жизни (TTL) присутствует в дополнение к многоадресной рассылке
адрес. TTL и адрес вместе определяют область действия
какие многоадресные пакеты, отправленные в этой конференции, будут отправлены. TTL
значения должны быть в диапазоне 0–255.TTL для сеанса добавляется к адресу с помощью косой черты как
разделитель. Пример: c = IN IP4 224.2.1.1/127 Иерархические или многоуровневые схемы кодирования - это потоки данных, в которых
кодирование из одного медиаисточника разбито на несколько
слои. Ресивер может выбрать желаемое качество (а значит
пропускная способность), подписавшись только на подмножество этих уровней. Такие
многоуровневые кодировки обычно передаются в многоадресной рассылке
группы, чтобы разрешить удаление многоадресной рассылки.Этот метод сохраняет нежелательные
трафик с сайтов, требующих только определенных уровней иерархии.
Для приложений, требующих нескольких групп многоадресной рассылки, мы разрешаем
Для адреса подключения следует использовать следующие обозначения: <базовый адрес многоадресной рассылки> / / <количество адресов> Если количество адресов не указано, предполагается, что оно равно одному.
Назначенные таким образом многоадресные адреса непрерывно выделяются выше
базовый адрес, например: c = ВХОД IP4 224.2.1.1 / 127/3 укажет, что адреса 224.2.1.1, 224.2.1.2 и 224.2.1.3 являются
для использования с ttl 127. Это семантически идентично
включение нескольких строк "c =" в описание мультимедиа: c = IN IP4 224.2.1.1/127
c = ВХОД IP4 224.2.1.2/127
c = ВХОД IP4 224.2.1.3/127 Несколько адресов или строк "c =" можно указать только для каждого
медиа, а не для поля «c =» уровня сеанса. Использование обозначения косой черты, описанное выше, для
Одноадресные IP-адреса.Пропускная способность b = <модификатор>: <значение-пропускной способности> o Это указывает предлагаемую полосу пропускания, которая будет использоваться сеансом или
media и не является обязательным. o в килобитах в секунду o <модификатор> - это одно буквенно-цифровое слово, дающее значение
показатель пропускной способности. o Изначально определены два модификатора: CT Conference Total: неявная максимальная полоса пропускания связана с
каждый TTL на Mbone или в рамках конкретной многоадресной рассылки
область административной области (пропускная способность в мегабайтах vs.Пределы TTL
приведено в FAQ MBone). Если пропускная способность сеанса или медиа в
сеанс отличается от пропускной способности, неявной из области видимости,
строка `b = CT: ... 'должна быть предоставлена для сеанса, дающего
предлагаемый верхний предел используемой полосы пропускания. Основная цель
это должно дать приблизительное представление о том, два или более
конференции могут сосуществовать одновременно. Максимум, зависящий от приложения AS: полоса пропускания интерпретируется как
для конкретного приложения, т.е.е., будет концепция приложения
максимальная пропускная способность. Обычно это будет совпадать с тем, что установлено на
контроль "максимальной пропускной способности" приложения, если применимо. Обратите внимание, что CT дает общее значение пропускной способности для всех носителей на
все сайты. AS дает показатель пропускной способности для одного носителя при
один сайт, хотя может быть много сайтов, отправляющих
одновременно. o Механизм расширения: авторы инструментов могут определять экспериментальную полосу пропускания
модификаторы, добавив к их модификатору префикс «X-».Например: б = X-YZ: 128 Парсеры SDP должны игнорировать поля пропускной способности с неизвестными модификаторами.
Модификаторы должны быть буквенно-цифровыми и, хотя ограничение по длине
учитывая, они рекомендуется быть короткими. Время, время повтора и часовые пояса t = <время начала> <время окончания> o поля "t =" указывают время начала и окончания конференции.
сеанс. Если сеанс активен, можно использовать несколько полей "t ="
в несколько нерегулярных интервалов времени; каждое дополнительное поле "t ="
указывает дополнительный период времени, в течение которого сеанс будет
быть активным.Если сеанс активен в обычное время, отображается "r ="
поле (см. ниже) следует использовать в дополнение и после
поле "t =" - в этом случае поле "t =" указывает начало и
время остановки повторяющейся последовательности. o Первое и второе подполя указывают время начала и окончания для
конференции соответственно. Эти значения являются десятичными
представление значений времени протокола сетевого времени (NTP) в
секунды [1]. Чтобы преобразовать эти значения во время UNIX, вычтите
десятичный 2208988800.o Если время остановки установлено на ноль, то сеанс не ограничен,
хотя он не станет активным до истечения времени запуска. Если
время начала также равно нулю, сеанс считается постоянным. Пользовательские интерфейсы должны категорически препятствовать созданию
неограниченные и постоянные сеансы, поскольку они не дают информации о
когда сеанс фактически завершится, и поэтому сделайте
планирование сложно. Можно сделать общее предположение при отображении неограниченного
сеансы, для которых не истекло время ожидания для пользователя, неограниченное
сеанс будет активен только через полчаса с текущего
время или время начала сеанса, в зависимости от того, что будет позже.Если
требуется другое поведение, необходимо указать время окончания
и при необходимости изменяются при появлении новой информации
о том, когда сессия действительно должна закончиться. Постоянные сеансы могут отображаться пользователю как никогда неактивные.
если нет связанных времен повтора, которые точно указывают, когда
сеанс будет активным. Как правило, постоянные сессии должны
не создаваться ни для одного сеанса, продолжительность которого должна быть меньше
более 2 месяцев, и не рекомендуется проводить сеансы,
иметь продолжительность менее 6 месяцев.r = <интервал повтора> <активная продолжительность> <список смещений от начала-
время> o Поля "r =" определяют время повтора для сеанса. Например, если
сессия активна в 10 утра в понедельник и в 11 утра во вторник для одного час каждую неделю в течение трех месяцев, затем <время начала> в
соответствующее поле "t =" будет представлением NTP 10 утра на
в первый понедельник <интервал повтора> будет 1 неделя, <активная продолжительность> будет 1 час, а смещения будут нулевыми
и 25 часов.Соответствующее время окончания поля "t =" будет
Представление NTP конца последней сессии три месяца
позже. По умолчанию все поля указаны в секундах, поэтому символы «r =» и «t =»
поля могут быть: т = 3034423619 3042462419
г = 604800 3600 0 Чтобы объявления были более компактными, время также может быть указано в единицах.
дней, часов или минут. Синтаксис для них - число
сразу за которым следует один чувствительный к регистру символ.Использование дробных единиц не допускается - следует использовать меньшие единицы.
вместо. Допускаются следующие символы спецификации устройства: d - дни (86400 секунд)
h - минуты (3600 секунд)
м - минуты (60 секунд)
s - секунды (разрешено для полноты, но не рекомендуется) Таким образом, это объявление также могло быть написано: г = 7д 1ч 0 25ч Ежемесячные и ежегодные повторы в настоящее время нельзя напрямую указать
с одним временем повтора SDP - вместо этого должны быть отдельные поля "t"
использоваться для явного перечисления времени сеанса.z = <время настройки> <смещение> <время настройки> <смещение> .... o Чтобы запланировать повторный сеанс, который охватывает смену дневного света-
экономя время к стандартному времени или наоборот, необходимо
укажите смещения от базового времени повторения. Это необходимо
потому что разные часовые пояса меняют время в разное время суток,
разные страны переходят на летнее время или наоборот
даты, а в некоторых странах летнее время вообще отсутствует.Таким образом, чтобы запланировать сеанс в одно и то же время зимой
и летом должна быть возможность однозначно указать,
часовой пояс, в котором запланирован сеанс. Чтобы упростить эту задачу для
получателям, мы позволяем отправителю указывать время NTP, которое
происходит регулировка зоны и смещение от времени, когда
сеанс был впервые запланирован Поле "z" позволяет отправителю
укажите список этих времен регулировки и смещений от базы
время.Примером может быть: z = 2882844526 -1ч 2898848070 0 Это указывает, что в момент времени 2882844526 развертка времени, по которой
рассчитывается время повтора сеанса смещено на 1 час назад,
и что в момент времени 2898848070 исходная временная база сеанса
восстановлен. Корректировки всегда относятся к указанному началу
время - они не суммируются. o Если сеанс, вероятно, продлится несколько лет, ожидается
тот
объявление о сеансе будет периодически изменяться, а не
передать корректировки за несколько лет в одном объявлении.Ключи шифрования k = <метод> k = <метод>: <ключ шифрования> o Протокол описания сеанса может использоваться для передачи шифрования
ключи. Ключевое поле допускается перед первой медиа-записью (в
в этом случае он применяется ко всем носителям в сеансе) или для каждого
запись в СМИ по мере необходимости. o Формат ключей и их использование выходят за рамки настоящего
документ, но см. [3]. o Метод указывает механизм, который будет использоваться для получения полезного
ключ внешними средствами или из заданного зашифрованного ключа шифрования.Определены следующие методы: k = clear: <ключ шифрования> Ключ шифрования (как описано в [3] для медиапотоков RTP
под AV-профилем) включается без преобразования в этот ключ
поле. k = base64: <закодированный ключ шифрования> Ключ шифрования (как описано в [3] для медиапотоков RTP
под профилем AV) включен в это ключевое поле, но был
кодируется base64, потому что он включает символы, которые
запрещено в SDP.k = uri: Универсальный идентификатор ресурса, используемый клиентами WWW:
включены в это ключевое поле. URI относится к данным
содержащий ключ, и может потребоваться дополнительная аутентификация прежде, чем ключ можно будет вернуть. Когда поступает запрос в
заданный URI, тип содержимого MIME ответа определяет
кодировка ключа в ответе. Ключ не должен быть
получается, пока пользователь не захочет присоединиться к сеансу, чтобы уменьшить
синхронизация запросов к серверу (-ам) WWW.k = подсказка
В это описание SDP не включен ключ, но сеанс или
медиапоток, на который ссылается это ключевое поле, зашифрован. В
у пользователя должен быть запрошен ключ при попытке присоединиться к
сеанс, и этот пользовательский ключ следует затем использовать для
расшифровать медиапотоки. Атрибуты a = <атрибут> a = <атрибут>: <значение> Атрибуты являются основным средством расширения SDP. Атрибуты могут
быть определенными для использования в качестве атрибутов "уровня сеанса", "уровня носителя"
атрибуты или и то, и другое.Медиа-описание может иметь любое количество атрибутов (поля "a =")
которые специфичны для СМИ. Их называют «медиа-уровнем».
атрибуты и добавить информацию о медиапотоке. Атрибут
поля также могут быть добавлены перед первым медиа-полем; эти
Атрибуты "уровня сеанса" передают дополнительную информацию, которая применяется
к конференции в целом, а не к отдельным СМИ; ан
примером может быть политика управления конференц-залом. Поля атрибутов могут быть двух форм: o атрибуты собственности.Атрибут свойства просто имеет форму
"а = <флаг>". Это бинарные атрибуты, и наличие
Атрибут означает, что атрибут является свойством сеанса.
Примером может быть «a = recvonly». o значения атрибутов. Атрибут значения имеет форму
"a = <атрибут>: <значение>". Примером может служить доска
может иметь значение атрибута "a = orient: landscape" Интерпретация атрибутов зависит от вызываемого медиаинструмента.
Таким образом, получатели описаний сеансов должны быть настроены в
их интерпретация объявлений в целом и атрибутов в
частности.Имена атрибутов должны быть в подмножестве US-ASCII стандарта ISO-10646 / UTF-8. Значения атрибутов представляют собой байтовые строки и МОГУТ использовать любое байтовое значение, кроме
0x00 (Nul), 0x0A (LF) и 0x0D (CR). По умолчанию значения атрибутов
должны интерпретироваться как в наборе символов ISO-10646 с UTF-8
кодирование. В отличие от других текстовых полей, значения атрибутов НЕ
обычно зависит от атрибута `charset ', так как при этом
сравнение с известными значениями проблематично. Однако когда
атрибут определен, он может быть определен как зависящий от кодировки, в
в этом случае его значение следует интерпретировать в кодировке сеанса
а не в ISO-10646.Атрибуты, которые будут обычно использоваться, могут быть зарегистрированы в IANA.
(см. Приложение B). Незарегистрированные атрибуты должны начинаться с "X-", чтобы
предотвращать непреднамеренное столкновение с зарегистрированными атрибутами. В любом
случае, если получен непонятный атрибут, он должен
просто игнорируется получателем. Объявления СМИ m = Описание сеанса может содержать несколько описаний мультимедиа.
Каждое описание мультимедиа начинается с поля «m =» и заканчивается
либо по следующему полю "m =", либо к концу сеанса
описание.Медиа-поле также имеет несколько подполей: o Первое подполе - это тип носителя. В настоящее время определенные медиа
"аудио", "видео", "приложение", "данные" и "управление", хотя это
список может быть расширен по мере появления новых способов общения (например,
телеприсутствие). Разница между «приложением» и «данными» заключается в
что первое - это поток мультимедиа, такой как информация с доски, и
последний - это передача больших объемов данных, например, многоадресная передача программы
исполняемые файлы, которые обычно не отображаются пользователю."control" используется для указания дополнительного управления конференцией
канал для сеанса. o Второе подполе - это транспортный порт, к которому медиа
поток будет отправлен. Значение транспортного порта зависит от
сеть используется, как указано в соответствующем поле "c" и
на транспортном протоколе, определенном в третьем подполе. разное
порты, используемые мультимедийным приложением (например, порт RTCP, см.
[2]) должен быть получен алгоритмически из базового медиа-порта.Примечание. Для транспортов, основанных на UDP, значение должно быть в диапазоне
От 1024 до 65535 включительно. Для соответствия RTP это должно быть
количество. Для приложений, в которых используются иерархически закодированные потоки.
отправлено на одноадресный адрес, может потребоваться указать несколько
транспортные порты. Это делается с использованием обозначений, аналогичных этой
используется для IP-адресов многоадресной рассылки в поле "c =": m = / <количество портов> В таком случае используемые порты зависят от транспортного протокола.Для RTP для данных используются только четные порты, а
соответствующий нечетный порт на единицу больше используется для RTCP. Например: m = видео 49170/2 RTP / AVP 31 будет указывать, что порты 49170 и 49171 образуют одну пару RTP / RTCP и
49172 и 49173 образуют вторую пару RTP / RTCP. RTP / AVP - это
транспортный протокол, а 31 - формат (см. ниже). Недопустимо указывать оба нескольких адреса в
поле "c =" и для указания нескольких портов в поле "m ="
в том же описании сеанса.o Третье подполе - транспортный протокол. Транспорт
значения протокола зависят от поля типа адреса в "c ="
поля. Таким образом, поле «c =» IP4 определяет, что транспортный
протокол работает по IP4. Для IP4 обычно ожидается, что большинство
Медиа-трафик будет передаваться как RTP через UDP. Следующее
транспортные протоколы определены предварительно, но могут быть расширены
путем регистрации новых протоколов в IANA: - RTP / AVP - транспортный протокол IETF в реальном времени, использующий
Аудио / видео профиль переносится через UDP.- udp - Протокол дейтаграмм пользователя Если приложение использует один комбинированный частный медиаформат
и транспортный протокол через UDP, просто указав
транспортный протокол как udp и с использованием поля формата для различения
рекомендуется комбинированный протокол. Если транспортный протокол
используется через UDP для передачи нескольких различных типов мультимедиа, которые необходимо
определяется каталогом сеанса, затем указывается транспорт
протокол и медиаформат отдельно необходимо.RTP - это
пример транспортного протокола, который несет множественную полезную нагрузку
форматы, которые должны различаться по каталогу сеанса для него
знать, как запустить соответствующие инструменты, реле, смесители или
рекордеры. Основная причина указать транспортный протокол в дополнение к
формат мультимедиа состоит в том, что те же стандартные форматы мультимедиа могут быть
переносится по различным транспортным протоколам, даже если сеть
протокол тот же - исторический пример - аудио PCM и
Аудио RTP PCM.Кроме того, реле и средства контроля, которые
возможны специфичные для транспортного протокола, но не зависящие от формата. Для медиапотоков RTP, работающих под профилем аудио / видео RTP
[3] поле протокола - «RTP / AVP». Если другие профили RTP
определены в будущем, их профили будут указаны в том же
путь. Например, в поле протокола "RTP / XYZ" указывается RTP.
работает под профилем с кратким названием «XYZ». o Четвертое и последующие подполя - это медиа-форматы.Для аудио
и видео, это обычно будет тип полезной нагрузки мультимедиа, как определено
в профиле аудио / видео RTP. Когда приводится список форматов полезной нагрузки, это означает, что все
эти форматы могут использоваться в сеансе, но первый из них
форматы - это формат по умолчанию для сеанса. Для носителей, транспортный протокол которых не является RTP или UDP, формат
поле зависит от протокола. Такие форматы должны быть определены в
документ дополнительной спецификации. Для носителей, транспортным протоколом которых является RTP, SDP может использоваться для
обеспечивают динамическую привязку кодирования мультимедиа к типу полезной нагрузки RTP.Имена кодировок в профиле RTP AV не указывают уникальные
кодировки аудио (с точки зрения тактовой частоты и количества аудио
каналы), поэтому они не используются непосредственно в полях формата SDP.
Вместо этого следует использовать номер типа полезной нагрузки, чтобы указать
формат для статических типов полезной нагрузки и номер типа полезной нагрузки вместе
с дополнительной информацией о кодировке следует использовать для динамического
выделенные типы полезной нагрузки. Примером статического типа полезной нагрузки является одиночный кодированный PCM по закону u.
канальный звук с дискретизацией 8 кГц.Это полностью определено в
Профиль аудио / видео RTP как тип полезной нагрузки 0, поэтому поле мультимедиа для
такой поток, отправляемый на порт UDP 49232: m = видео 49232 RTP / AVP 0 Пример динамического типа полезной нагрузки - это 16-битное линейное кодирование.
стереозвук с частотой дискретизации 16 кГц. Если мы хотим использовать динамический RTP / AVP
тип полезной нагрузки 98 для такого потока, дополнительная информация
требуется для его декодирования: m = видео 49232 RTP / AVP 98 a = об / мин: 98 L16 / 16000/2 Общая форма атрибута rtpmap: a = rtpmap: <тип полезной нагрузки> <название кодировки> / <тактовая частота> [/ <кодировка
параметры>] Для аудиопотоков <параметры кодирования> могут указывать количество
аудиоканалы.Этот параметр можно не указывать, если количество
Каналы - один при условии, что дополнительных параметров не требуется. За
видеопотоки, параметры кодирования на данный момент не указаны. Дополнительные параметры могут быть определены в будущем, но
Параметры, специфичные для кода, добавлять не следует. Параметры добавлены в
атрибут rtpmap должен быть только тем, что требуется для сеанса
каталог, чтобы выбрать подходящий носитель.
участвовать в сеансе. Параметры кодека должны быть
добавлены другие атрибуты.Для каждого формата мультимедиа можно определить до одного атрибута rtpmap.
указано. Таким образом, мы могли бы иметь: m = аудио 49230 RTP / AVP 96 97 98
а = об / мин: 96 L8 / 8000
а = об / мин: 97 L16 / 8000
а = об / мин: 98 L16 / 11025/2 Профили RTP, которые определяют использование динамических типов полезной нагрузки, должны
определить набор допустимых имен кодировки и / или средства для регистрации
имена кодировок, если этот профиль будет использоваться с SDP.Экспериментальные форматы кодирования также можно указать с помощью rtpmap.
Форматы RTP, которые не зарегистрированы как имена стандартных форматов, должны
ему предшествует "X-". Таким образом, новый экспериментальный избыточный звук
поток под названием GSMLPC с использованием типа динамической полезной нагрузки 99 может быть
указано как: m = видео 49232 RTP / AVP 99
a = rtpmap: 99 X-GSMLPC / 8000 Такая экспериментальная кодировка требует, чтобы любой сайт, желающий
получить медиапоток имеет соответствующее настроенное состояние в его
каталог сеанса, чтобы узнать, какие инструменты подходят.Обратите внимание, что аудиоформаты RTP обычно не содержат информации
о количестве образцов в пакете. Если не по умолчанию (как
определено в профиле аудио / видео RTP) требуется пакетизация,
атрибут «ptime» используется, как указано ниже. Подробнее об аудио- и видеоформатах RTP см. [3]. o Форматы для носителей без RTP должны быть зарегистрированы как контент MIME.
типы, как описано в Приложении B. Например, доска LBL
приложение может быть зарегистрировано как приложение типа содержимого MIME / wb
с учетом требований кодирования, указывающих, что он работает через UDP,
без соответствующего формата файла.В SDP это будет
выражается с помощью комбинации поля "media" и "fmt"
поле, как показано ниже: m = приложение 32416 udp wb Предлагаемые атрибуты Предлагаются следующие атрибуты. Поскольку авторы приложений
могут добавлять новые атрибуты по мере необходимости, этот список не
исчерпывающий. a = cat: <категория> Этот атрибут дает разделенную точками иерархическую категорию
сессия. Это необходимо для того, чтобы приемник мог фильтровать нежелательные
сеансы по категориям.Вероятно, это было бы обязательным
отдельное поле, за исключением его экспериментального характера в настоящее время.
Это атрибут уровня сеанса, не зависящий от кодировки. a = keywds: <ключевые слова> Как и атрибут кота, это помогает идентифицировать разыскиваемых
сеансы на приемнике. Это позволяет получателю выбрать
интересная сессия на основе ключевых слов, описывающих цель
сессия. Это атрибут уровня сеанса. Это кодировка
зависимый атрибут, то есть его значение следует интерпретировать
в кодировке, указанной для описания сеанса, если
указан или по умолчанию в ISO 10646 / UTF-8.a = инструмент: <название и версия инструмента> Это дает имя и номер версии инструмента, используемого для создания
описание сеанса. Это атрибут уровня сеанса и
не зависит от кодировки. a = ptime: <время пакета> Это дает время в миллисекундах, представленное
медиа в пакете. Это, вероятно, имеет значение только для аудио
данные. Не обязательно знать ptime для декодирования RTP или
ндс аудио, и он предназначен как рекомендация для
кодирование / пакетирование аудио.Это медиа-атрибут,
не зависит от кодировки. a = recvonly
Это указывает, что инструменты должны запускаться в режиме только получения.
режим, если применимо. Это может быть сеанс или медиа
атрибут и не зависит от кодировки. a = sendrecv
Это указывает, что инструменты должны запускаться при отправке и
режим приема. Это необходимо для интерактивных конференций с
такие инструменты, как wb, который по умолчанию работает в режиме только приема. Это может быть
либо атрибут сеанса, либо медиа, и не зависит от
кодировка.a = sendonly
Это указывает, что инструменты должны запускаться в режиме только для отправки
Режим. Примером может быть другой одноадресный адрес для
использоваться для пункта назначения трафика, чем для источника трафика. В
В таком случае можно использовать два описания мультимедиа, одно только для отправки и
один recvonly. Это может быть атрибут сеанса или медиа, но
обычно используется только как атрибут мультимедиа, а не
зависит от кодировки. a = orient: <ориентация доски> Обычно это используется только в спецификации носителя для интерактивной доски.Он определяет ориентацию доски на экране.
Это медиа-атрибут. Допустимые значения - "портрет",
«пейзаж» и «морской пейзаж» (перевернутый пейзаж). Нет
зависит от кодировки a = type: <тип конференции> Это определяет тип конференции. Предлагаемые значения:
"трансляция", "встреча", "модерируемый", "тест" и "h432".
`recvonly 'должен быть значением по умолчанию для сеансов` type: broadcast',
"type: meeting" должен подразумевать "sendrecv" и "type: moderated"
должен указывать на использование инструмента для контроля пола и что
медиа-инструменты запускаются, чтобы «отключить» новые сайты, присоединяющиеся к
конференция.Указание типа атрибута: h432 указывает, что это вольно
связанный сеанс является частью сеанса H.332, как определено в ITU
Спецификация H.332 [10]. Медиа-инструменты должны быть запущены
`recvonly '. Указание типа атрибута: test предлагается в качестве подсказки, что,
если явно не указано иное, получатели могут безопасно избегать
отображение этого описания сеанса для пользователей. Атрибут type является атрибутом уровня сеанса и не является
зависит от кодировки.a = набор символов: <набор символов> Это определяет набор символов, который будет использоваться для отображения
имя сеанса и информационные данные. По умолчанию ISO-10646
используется набор символов в кодировке UTF-8. Если более компактный
требуется представление, могут использоваться другие наборы символов, например
как ISO-8859-1 для языков Северной Европы. В частности,
ISO 8859-1 определяется следующим атрибутом SDP: a = кодировка: ISO-8859-1 Это атрибут уровня сеанса; если этот атрибут присутствует,
он должен быть перед первым медиа-полем.Указанная кодировка
ДОЛЖЕН быть одним из зарегистрированных в IANA, например ISO-8859-1.
Идентификатор набора символов представляет собой строку US-ASCII и ДОЛЖЕН быть
сравнивается с идентификаторами IANA, используя регистронезависимый
сравнение. Если идентификатор не распознан или нет
поддерживается, все строки, на которые он влияет, ДОЛЖНЫ рассматриваться
как байтовые строки. Обратите внимание, что указанный набор символов ДОЛЖЕН все же запрещать использование
байтов 0x00 (Nul), 0x0A (LF) и 0x0d (CR).Наборы символов
требование использования этих символов ДОЛЖНО определять кавычки
механизм, который предотвращает появление этих байтов в текстовых полях. a = sdplang: <языковой тег> Это может быть атрибут уровня сеанса или атрибут уровня мультимедиа.
В качестве атрибута уровня сеанса он определяет язык для
описание сеанса. В качестве атрибута уровня мультимедиа он определяет
язык для любого связанного поля информации SDP на уровне носителя
с этими СМИ.Можно указать несколько атрибутов sdplang
либо на уровне сеанса, либо на уровне СМИ, если в
описание сеанса или медиа используют несколько языков, на которых
случае порядок атрибутов указывает порядок
важность различных языков в сеансе или СМИ из
от наиболее важного до наименее важного. Как правило, отправка описаний сеансов, состоящих из нескольких
языки не следует поощрять. Вместо этого несколько описаний
должны быть отправлены с описанием сеанса, по одному на каждом языке.Однако это невозможно со всеми транспортными механизмами, и
поэтому несколько атрибутов sdplang разрешены, но не
рекомендуемые. Значение атрибута sdplang должно соответствовать одному языку RFC 1766.
тег в US-ASCII. Это не зависит от атрибута charset.
Атрибут sdplang ДОЛЖЕН быть указан, если сеанс достаточный простор для пересечения географических границ, где
язык получателей не может быть принят, или где сеанс
на языке, отличном от принятой в данной местности нормы.a = lang: <языковой тег> Это может быть атрибут уровня сеанса или атрибут уровня мультимедиа.
В качестве атрибута уровня сеанса он определяет язык по умолчанию.
для описываемого сеанса. В качестве атрибута уровня носителя он
определяет язык для этого носителя, отменяя любой сеанс -
указанный уровень языка. Можно указать несколько атрибутов языка.
предоставляется либо на уровне сеанса, либо на уровне носителя, если несколько языков
если в описании сеанса или мультимедиа используется несколько языков, в
в этом случае порядок атрибутов указывает порядок
важность различных языков в сеансе или СМИ из
от наиболее важного до наименее важного.Значение атрибута lang должно быть одним тегом языка RFC 1766.
в US-ASCII. Это не зависит от атрибута charset. А
атрибут lang СЛЕДУЕТ указывать, если сеанс
достаточный простор для пересечения географических границ, где
язык получателей не может быть принят, или где сеанс
на языке, отличном от принятой в данной местности нормы. a = частота кадров: <частота кадров> Это дает максимальную частоту кадров видео в кадрах / сек.это
предназначена как рекомендация по кодированию видеоданных.
Десятичные представления дробных значений с использованием нотации
"<целое число>. <фракция>" разрешены. Это медиа-атрибут,
определен только для видео носителей и не зависит от кодировки. a = качество: <качество> Это дает представление о качестве кодирования как
целочисленное значение. Назначение атрибута качества для видео - указать
нестандартный компромисс между частотой кадров и качеством неподвижного изображения.Для видео значение в диапазоне от 0 до 10 со следующими
предполагаемое значение: 10 - лучшее качество неподвижного изображения, которое может обеспечить схема сжатия
дайте. 5 - поведение по умолчанию без предложения качества. 0 - худшее качество неподвижного изображения, по мнению разработчика кодека
все еще можно использовать. Это медиа-атрибут, не зависящий от кодировки. a = fmtp: <формат> <параметры формата> Этот атрибут позволяет параметры, специфичные для
конкретный формат, который должен передаваться таким образом, что SDP не имеет
понять их.Формат должен быть одним из форматов
указано для СМИ. Параметры, зависящие от формата, могут быть любыми
набор параметров, которые должны быть переданы SDP и предоставлены
без изменений для медиа-инструмента, который будет использовать этот формат. Это медиа-атрибут, не зависящий от кодировки. 6.1. Политика управления конференц-связью Есть некоторые дебаты по поводу того, как должна быть политика управления конференциями.
общались. В целом авторы считают, что неявный
декларативный стиль указания управления конференцией желателен там, где
возможно.В простом декларативном стиле используется одно поле атрибута конференции.
перед первым медиа-полем, возможно, дополненное свойствами
например recvonly для некоторых медиа-инструментов. Эта конференция
Атрибут передает политику управления конференцией. Примером может быть: a = type: модерируемый Однако в некоторых случаях этого может быть недостаточно.
чтобы сообщить подробности необычной политики управления конференцией.
Если это так, то атрибут конференции, указывающий внешний
может быть установлен, и тогда может быть установлено одно или несколько полей "медиа"
используется для указания инструментов управления конференцией и данных конфигурации
для этих инструментов.Примером является сеанс ITU H.332: c = ВХОД IP4 224.5.6.7
a = тип: h432
m = аудио 49230 RTP / AVP 0
m = видео 49232 RTP / AVP 31
m = приложение 12349 udp wb
m = контроль 49234 h423 mc
c = В IP4 134.134.157.81 В этом примере атрибутом общей конференции (тип: h432) является
указано, что управление конференцией будет обеспечиваться
внешний инструмент H.332 и контактные адреса для сеанса H.323
дан многоточечный контроллер.В этом документе только декларативный стиль управления конференцией
декларация указана. Другие формы управления конференцией должны
указать соответствующий атрибут типа и определить
последствия этого для управляющих СМИ. 7. Соображения безопасности SDP - это формат описания сеанса, который описывает мультимедиа
сеансы. Не следует доверять описанию сеанса, если в нем нет
был получен аутентифицированным транспортным протоколом от доверенного
источник. Для распространения можно использовать множество различных транспортных протоколов.
описание сеанса, и характер аутентификации будет отличаться
от транспорта до транспорта.Один транспорт, который будет часто использоваться для распространения сеанса
descriptions - это протокол объявления сеанса (SAP). SAP
предоставляет механизмы шифрования и аутентификации, но из-за
характер объявлений о сессиях вполне вероятно, что есть много
случаи, когда отправитель объявления сеанса не может быть
аутентифицированы, потому что они ранее неизвестны получателю
объявление и поскольку нет общей инфраструктуры открытого ключа
имеется в наличии.При получении описания сеанса через неаутентифицированный транспорт
механизм или от ненадежной стороны, программное обеспечение, анализирующее сеанс
следует принять некоторые меры предосторожности. Описание сеанса содержит
информация, необходимая для запуска программного обеспечения в системе приемников.
Программное обеспечение, которое анализирует описание сеанса, НЕ ДОЛЖНО запускаться
другое программное обеспечение, кроме того, которое специально настроено как
соответствующее программное обеспечение для участия в мультимедийных сеансах. это
обычно считается НЕПРАВИЛЬНЫМ для программного анализа сеанса
описание для запуска в системе пользователя программного обеспечения, которое
подходит для участия в мультимедийных сеансах без участия пользователя
сначала получить информацию о том, что такое программное обеспечение будет запущено, и
их согласие.Таким образом, описание сеанса поступает по сеансу
объявление, электронное письмо, приглашение на сеанс или веб-страницу НЕ ДОЛЖНЫ
доставить пользователя в {it интерактивный} мультимедийный сеанс без
пользователь знает, что это произойдет. Как это не всегда
просто определить, является ли сеанс интерактивным или нет, приложения
которые не уверены, следует предполагать, что сеансы интерактивны. В этой спецификации нет атрибутов, которые позволили бы
получатель описания сеанса должен быть проинформирован о запуске мультимедиа
инструменты в режиме, в котором они по умолчанию передают.Под некоторыми
обстоятельства, возможно, уместно определить такие атрибуты. Если
это делается приложением, анализирующим описание сеанса, содержащее
такие атрибуты ДОЛЖНЫ либо игнорировать их, либо сообщать пользователю, что
присоединение к этой сессии приведет к автоматической передаче
мультимедийные данные. Поведение по умолчанию для неизвестного атрибута:
игнорировать это. Описания сеансов могут быть проанализированы в промежуточных системах, таких как
брандмауэры для открытия дыры в брандмауэре, чтобы позволить
участие в мультимедийных сессиях.Считается
НЕПРАВИЛЬНО для брандмауэра открывать такие дыры для одноадресных данных
потоки, если описание сеанса не входит в запрос изнутри
брандмауэр. Для многоадресных сеансов локальные администраторы могут
применять свои собственные политики, но исключительное использование «локальных» или «сайтов»
локальная "административная область внутри брандмауэра и отказ от
брандмауэр для открытия дыры для таких прицелов обеспечит разделение
глобальных многоадресных сессий из локальных.Приложение A. Грамматика SDP В этом приложении представлена грамматика расширенного BNF для SDP. ABNF - это
определено в RFC 2234. объявление = прото-версия
поле происхождения
поле имени сеанса
информационное поле
поле uri
email-поля
телефонные поля
поле связи
поля пропускной способности
временные поля
ключевое поле
поля атрибутов
медиа-описания proto-version = "v =" 1 * ЦИФРОВОЙ CRLF
; эта памятка описывает версию 0 origin-field = "o =" пространство для имени пользователя
пространство сесс-идентификаторов пространство сессионных версий
пространство nettype пространство addrtype
адрес CRLF session-name-field = "s =" текст CRLF информация-поле = ["i =" текст CRLF] uri-field = ["u =" uri CRLF] email-fields = * ("e =" адрес электронной почты CRLF) phone-fields = * ("p =" номер телефона CRLF) connection-field = ["c =" пробел nettype пробел addrtype
адрес-соединения CRLF]
; поле подключения должно присутствовать
; в каждом описании СМИ или в
; уровень сеанса bandwidth-fields = * ("b =" bwtype ":" пропускная способность CRLF) поля времени = 1 * ("t =" время начала пространство время остановки
* (Повторяющиеся поля CRLF) CRLF)
[настройки зоны CRLF] repeat-fields = "r =" интервал повторения пробел, время ввода
1 * (пробел - время) zone-adjustments = time space ["-"] типизированное время
* (пространство-время-пространство ["-"] типизированное время) key-field = ["k =" CRLF типа ключа] key-type = "подсказка" |
"clear:" ключевые данные |
"base64:" ключевые данные |
"ури:" ури ключевые данные = безопасная для электронной почты | "~" | " attribute-fields = * ("a =" атрибут CRLF) media-descriptions = * (медиа-поле
информационное поле
* (поле подключения)
поля пропускной способности
ключевое поле
поля атрибутов) media-field = "m =" порт медиа-пространства ["/" целое число]
пробел прото 1 * (пробел fmt) CRLF media = 1 * (буквенно-цифровой)
; обычно "аудио", "видео", "приложение"
; или "данные" fmt = 1 * (буквенно-цифровой)
; обычно тип полезной нагрузки RTP для аудио
; и видео СМИ proto = 1 * (буквенно-цифровой)
; обычно "RTP / AVP" или "udp" для IP4 порт = 1 * (ЦИФРА)
; должно быть в диапазоне от "1024" до "65535" включительно
; для медиа на основе UDP атрибут = (поле атрибута ":" значение атрибута) | att-поле att-field = 1 * (буквенно-цифровой) значение атрибута = строка байтов сесс-идентификатор = 1 * (ЦИФРА)
; должен быть уникальным для этого исходного имени пользователя / хоста сесс-версия = 1 * (ЦИФРА)
; 0 - новый сеанс адрес-соединения = многоадресный-адрес
| адрес групповой-адрес = 3 * (десятичный-учар ".") десятичный-учар" / "ттл
["/" целое число]
; адреса многоадресной рассылки могут быть в диапазоне
; С 224.0.0.0 до 239.255.255.255 ttl = десятичный-uchar время начала = время | «0» время остановки = время | «0» время = ЦИФРА ПОЛОЖЕНИЯ 9 * (ЦИФРА)
; хватит еще на 2 века интервал повторения = набранное время типизированное время = 1 * (ЦИФРА) [фиксированная-лен-единица времени] фиксированная-лен-время-единица = "д" | "h" | "м" | "s" bwtype = 1 * (буквенно-цифровой) пропускная способность = 1 * (ЦИФРА) имя пользователя = безопасно
; довольно широкое определение, но без пробелов адрес электронной почты = адрес электронной почты | электронная почта "(" безопасна для электронной почты ")" |
безопасный для электронной почты "<" email ">" email =; определено в RFC822 uri =; определено в RFC1630 phone-number = телефон | телефон "(" безопасный для электронной почты ")" |
безопасный для электронной почты "<" phone ">" phone = "+" POS-DIGIT 1 * (пробел | "-" | DIGIT)
; между ними должен быть пробел или дефис.
; международный код и остальная часть номера.nettype = "IN"
; список будет расширен addrtype = "IP4" | «IP6»
; список будет расширен addr = FQDN | одноадресный адрес FQDN = 4 * (буквенно-цифровое | "-" | ".")
; полное доменное имя, как указано в RFC1035 unicast-address = IP4-адрес | IP6-адрес IP4-адрес = b1 "." десятичный-учар "." десятичный-учар "." b4
b1 = десятичный-учар
; меньше "224"; не «0» или «127»
b4 = десятичный-учар
; не "0" IP6-адрес =; подлежит определению текст = байтовая строка
; по умолчанию это интерпретируется как IS0-10646 UTF8
; ISO 8859-1 требует "a = charset: ISO-8859-1"
; атрибут уровня сеанса, который будет использоваться байтовая строка = 1 * (0x01..0x09 | 0x0b | 0x0c | 0x0e..0xff)
; любой байт кроме NUL, CR или LF десятичный-uchar = ЦИФРА
| ПОС-ЦИФРА
| ("1" 2 * (ЦИФРА))
| («2» («0» | «1» | «2» | «3» | «4») ЦИФРА)
| («2» «5» («0» | «1» | «2» | «3» | «4» | «5»)) целое = ПОЗ-ЦИФРА * (ЦИФРА) буквенно-числовой = АЛЬФА | ЦИФРА ЦИФРА = "0" | ПОС-ЦИФРА POS-DIGIT = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" АЛЬФА = «a» | «b» | «c» | «d» | «e» | «f» | «g» | «h» | «i» | «j» | «k» |
«l» | «m» | «n» | «o» | «p» | «q» | «r» | «s» | «t» | «u» | «v» |
«w» | «x» | «y» | «z» | «A» | «B» | «C» | «D» | «E» | «F» | «G» |
«H» | «I» | «J» | «K» | «L» | «M» | «N» | «O» | «P» | «Q» | «R» |
«S» | «T» | «U» | «V» | «W» | «X» | «Y» | «Z» email-safe = safe | пространство | вкладка сейф = буквенно-цифровой |
"'" | "'" | "-" | "."|" _ "|" `" | "{" | "|" | "}" | "+" |
"~" | " пробел =% d32
tab =% d9
CRLF =% d13.10 Приложение B: Рекомендации по регистрации имен SDP в IANA Есть семь имен полей, которые могут быть зарегистрированы в IANA. С помощью
терминология в спецификации SDP BNF, они «медиа»,
«proto», «fmt», «att-field», «bwtype», «nettype» и «addrtype». «медиа» (например, аудио, видео, приложение, данные). Типы пакетированных носителей, такие как те, что используются RTP, совместно используют
пространство имен, используемое реестром типов носителей [RFC 2048] (т.е. "MIME
типы "). Список допустимых имен медиа - это набор верхнего уровня
Типы содержимого MIME. Набор средств массовой информации должен быть небольшим и
не подлежит продлению, за исключением редких случаев. (MIME
подтип соответствует параметру "fmt" ниже). "прото" В общем, это должен быть транспорт по стандартам IETF.
идентификатор протокола, такой как RTP / AVP (rfc 1889 под rfc 1890
профиль). Однако люди захотят изобрести собственные запатентованные
транспортные протоколы.Некоторые из них должны быть зарегистрированы как
"fmt" с использованием "udp" в качестве протокола, и некоторые из них, вероятно,
не может быть. Если протокол и приложение тесно связаны,
например, с доской LBL wb, на которой использовались проприетарные и
протокол специального назначения через UDP, имя протокола должно быть
«udp», а имя формата, которое необходимо зарегистрировать, - «wb». В
к такой регистрации применяются правила для форматов (см. ниже). Где проприетарный транспортный протокол действительно несет много
разные форматы данных, есть возможность зарегистрировать новый протокол
имя с IANA.В таком случае ДОЛЖЕН быть подготовлен RFC.
описание протокола и ссылка на него при регистрации. Такие
RFC МОЖЕТ быть информационным, хотя предпочтительнее, если он
стандарты-трек. "fmt" Пространство имен формата зависит от контекста "proto"
поле, поэтому формат не может быть зарегистрирован без указания одного или
больше транспортных протоколов, к которым он применяется. Форматы охватывают все возможные кодировки, которые могут быть
переносится в мультимедийном сеансе.Для форматов RTP, которым были назначены статические типы полезной нагрузки,
используется номер типа полезной нагрузки. Для форматов RTP с использованием динамического
номер типа полезной нагрузки, номер динамического типа полезной нагрузки задается как
формат и дополнительный атрибут "rtpmap" определяют
формат и параметры. Для форматов, отличных от RTP, любое имя незарегистрированного формата может быть
зарегистрированы в процессе регистрации MIME-типа [RFC 2048].
Приведенный здесь тип является только подтипом MIME (MIME верхнего уровня
тип содержимого указывается параметром media).Тип MIME
регистрация ДОЛЖНА содержать ссылку на RFC для отслеживания стандартов, который
описывает транспортный протокол для этого типа носителя. Если там
является существующим типом MIME для этого формата, регистрация MIME
должны быть дополнены ссылкой на транспортную спецификацию для
этот тип носителя. Если для этого не существует существующего типа MIME
формат, и не существует подходящего формата файла, это должно
быть отмеченным в вопросах кодирования как "нет подходящего файла
формат"."att-field" (названия атрибутов) Имена полей атрибутов МОГУТ быть зарегистрированы в IANA, хотя это
не является обязательным, и неизвестные атрибуты просто игнорируются. Когда атрибут зарегистрирован, он должен сопровождаться
краткая спецификация, указывающая следующее: o контактное имя, адрес электронной почты и номер телефона o имя-атрибута (как оно будет отображаться в SDP) o полное имя атрибута на английском языке o тип атрибута (уровень сеанса, уровень мультимедиа или оба) o подчиняется ли значение атрибута кодировке
атрибут.o Объяснение назначения атрибута в один абзац. o спецификация соответствующих значений атрибутов для этого
атрибут. IANA не будет проверять такие регистрации атрибутов, за исключением
убедитесь, что они не конфликтуют с существующими регистрациями. Хотя приведенное выше является минимумом, который IANA примет, если
ожидается, что атрибут будет широко использоваться и взаимодействовать
является проблемой, авторам рекомендуется создать стандартную версию
RFC, более точно определяющий атрибут.Лица, подающие заявки на регистрацию, должны убедиться, что спецификация
в духе атрибутов SDP, в первую очередь то, что
атрибут не зависит от платформы в том смысле, что он не
неявные предположения об операционных системах и не называет
определенные части программного обеспечения, которые могут препятствовать
совместимость. "bwtype" (спецификаторы пропускной способности) Настоятельно не рекомендуется распространение спецификаторов полосы пропускания. Новые спецификаторы полосы пропускания могут быть зарегистрированы в IANA.В
отправка ДОЛЖНА содержать ссылку на RFC для отслеживания стандартов, определяющий
точная семантика спецификатора полосы пропускания и указание
когда его следует использовать и почему существующая зарегистрированная пропускная способность
спецификаторов не хватает. "nettype" (Тип сети) Новые типы сетей могут быть зарегистрированы в IANA, если требуется SDP.
используется в контексте неинтернет-среды. Пока эти
обычно не являются прерогативой IANA, могут быть обстоятельства
когда интернет-приложению необходимо взаимодействовать с не-
Интернет-приложение, например, при подключении к Интернету
телефонный звонок в PSTN.Количество типов сети должно
быть маленькими и редко расширять. Новый тип сети
нельзя зарегистрироваться без регистрации хотя бы одного адреса
тип, который будет использоваться с этим типом сети. Новый тип сети
регистрация ДОЛЖНА содержать ссылку на RFC, в котором подробно описаны
тип сети и тип адреса и указывает, как и когда они
будет использоваться. Такой RFC МОЖЕТ быть информационным. "addrtype" (Тип адреса) Новые типы адресов могут быть зарегистрированы в IANA.Тип адреса
имеет смысл только в контексте типа сети, и любой
регистрация типа адреса ДОЛЖНА указывать зарегистрированную сеть
type, или быть отправленным вместе с регистрацией сетевого типа. А
регистрация нового типа адреса ДОЛЖНА ссылаться на RFC, дающий
подробности синтаксиса типа адреса. Такой RFC МОЖЕТ быть
Информационный. Типы адресов не должны регистрироваться
часто. Процедура регистрации Чтобы зарегистрировать имя, необходимо следовать приведенным выше инструкциям относительно
необходимый уровень документации, которая требуется.В
саму регистрацию следует отправить в IANA. Регистрация атрибутов
должен включать информацию, указанную выше. Другие регистрации
должен включать следующую дополнительную информацию: o контактное имя, адрес электронной почты и номер телефона o регистрируемое имя (как оно появится в SDP) o полное имя на английском языке o тип имени («media», «proto», «fmt», «bwtype», «nettype» или
"addrtype") o объяснение цели зарегистрированного имени в одном абзаце.o ссылку на спецификацию (например, номер RFC) зарегистрированного
имя. IANA может передать любую регистрацию в IESG или в любой соответствующий
Рабочая группа IETF для проверки и может потребовать внесения изменений
до того, как будет произведена регистрация. Приложение C: Адреса авторов Марк Хэндли
Институт информационных наук
c / o MIT Лаборатория компьютерных наук
545 Площадь Технологий
Кембридж, Массачусетс 02139
Соединенные Штаты
электронная почта: [email protected] Ван Якобсон
МС 46а-1121
Лаборатория Лоуренса Беркли
Беркли, Калифорния 94720
Соединенные Штаты
электронная почта: van @ ee.lbl.gov Благодарности Многие люди в рабочей группе IETF MMUSIC оставили комментарии и
предложения по этому документу. В частности, мы бы
хотел бы поблагодарить Еву Шулер, Стива Каснера, Билла Феннера, Эллисон
Манкин, Росс Финлейсон, Питер Парнс, Йорг Отт, Карстен Борман, Роб
Ланфье и Стив Ханна. Рекомендации [1] Миллс Д., "Спецификация сетевого протокола времени (версия 3) и
реализация », RFC 1305, март 1992 г. [2] Шульцринн, Х., Каснер, С., Фредерик, Р.и В. Якобсон, "RTP:
Транспортный протокол для приложений реального времени », RFC 1889, январь
1996 г. [3] Шульцринн, Х., "Профиль RTP для аудио- и видеоконференций.
с минимальным контролем », RFC 1890, январь 1996 г. [4] Хэндли, М., «SAP - протокол объявления сеанса», Работа в
Прогресс. [5] В. Якобсон, С. Макканн, «НДС - аудиоконференцсвязь на базе X11.
инструмент », страница руководства по чанам, Лаборатория Лоуренса Беркли, 1994. [6] Консорциум Unicode, «Стандарт Unicode - версия 2.0 ",
Аддисон-Уэсли, 1996. [7] ИСО / МЭК 10646-1: 1993. Международный стандарт - Информация
технология - Универсальный набор символов с несколькими октетами (UCS) -
Часть 1: Архитектура и базовая многоязычная плоскость. Пять поправок
и техническое исправление опубликовано к настоящему времени. UTF-8
описан в Приложении R, опубликованном как Поправка 2. [8] Голдсмит Д. и М. Дэвис, «Использование Unicode с MIME», RFC 1641,
Июль 1994 г. [9] Йерго, Ф., «UTF-8, формат преобразования Unicode и ISO.
10646 ", RFC 2044, октябрь 1996 г.[10] Рекомендация ITU-T H.332 (1998): «Мультимедийный терминал для
Прием Интернет-конференций H.323 », ITU, Женева. [11] Хэндли, М., Школьник, Э. и Х. Шульцринн, "Сессия
Протокол инициации (SIP) », Работа в процессе. [12] Шульцринн, Х., Рао, А., и Р. Ланфьер, "Потоковая передача в реальном времени
Протокол (RTSP) », RFC 2326, апрель 1998 г. Полное заявление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Этот документ и его переводы могут быть скопированы и предоставлены
другие и производные работы, которые комментируют или иным образом объясняют это
или помочь в его реализации могут быть подготовлены, скопированы, опубликованы
и распространяется, полностью или частично, без ограничения каких-либо
вида, при условии, что указанное выше уведомление об авторских правах и этот абзац
включены во все такие копии и производные работы.Однако это
сам документ не может быть изменен каким-либо образом, например, путем удаления
уведомление об авторских правах или ссылки на Internet Society или другие
Интернет-организации, за исключением случаев, когда это необходимо для
разработки Интернет-стандартов, в этом случае процедуры для
авторские права, определенные в процессе разработки стандартов Интернета, должны быть
следовали, или по мере необходимости перевести его на другие языки, кроме
Английский.
Что означает SDP?
Описание сеанса Протокол
Вычисления »Сети — и многое другое…
Социал-демократическая партия
Правительственная »Политика
Процесс разработки программного обеспечения
Вычислительная техника »Программное обеспечение
9 — План разработки программного обеспечения для правительства
Правительство…
Стратегический план развития
Правительство »Правительство США
Полуопределенное программирование
Академические и естественные науки »Математика
Service Discovery Protocol
Разное »Несекретный
Доставка программного обеспечения ry Платформа
Вычислительная техника »Программное обеспечение
Социалистическая демократическая партия
Правительство» Политика
Самый крутой спуск
Sports
9129 9129 9129 9129 9129 9129
Процесс разработки систем
Правительство »Военное дело
SunSour ce, Inc.
Business »Символы NYSE
Shelf Discovery Protocol
Computing» Networking Rate
Сумма несвязанных продуктов
Разное »Несекретный
RFC 2327 — SDP: протокол описания сеанса (RFC2327 )
Сетевая рабочая группа М. Хэндли Запрос комментариев: 2327 В. Якобсон Категория: Стандарты Track ISI / LBNL Апрель 1998 SDP: протокол описания сеанса Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола. Распространение памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Аннотация Этот документ определяет протокол описания сеанса SDP. SDP - это предназначен для описания мультимедийных сеансов в целях объявление о сеансе, приглашение на сеанс и другие формы инициирование мультимедийной сессии.Этот документ является продуктом многосторонней мультимедийной сессии. Контрольная (MMUSIC) рабочая группа инженерного задания Интернета Force. Комментарии запрашиваются и должны быть адресованы работающим список рассылки группы по адресу [email protected] и / или авторов. 1. Введение В магистрали многоадресной передачи в Интернете (Mbone), инструмент каталога сеансов используется для рекламы мультимедийных конференций и сообщения адреса конференций и информация о средствах конференции необходимо для участия.Этот документ определяет сеанс протокол описания для этой цели и для общего режима реального времени цели описания мультимедийной сессии. Эта памятка не описывает выделение многоадресных адресов или распространение сообщений SDP в деталь. Они описаны в сопроводительных памятках. SDP не предназначен для согласования кодировок медиа. 2. Справочная информация Mbone - это часть Интернета, которая поддерживает многоадресную IP-рассылку, и таким образом, обеспечивается эффективная связь "многие ко многим".Это использовано широко используется для мультимедийных конференций. Такие конференции обычно обладают тем свойством, что тесная координация членства в конференции не обязательно; для приема конференции пользователь только на сайте Mbone должен знать адрес многоадресной группы конференции и UDP порты для потоков данных конференции. Каталоги сеансов помогают рекламировать сеансы конференции и передать соответствующую информацию о настройке конференции потенциальные участники.SDP предназначен для передачи такой информации получателям. SDP - это чисто формат описания сеанса - это не включает транспортный протокол и предназначен для использования различные транспортные протоколы в зависимости от ситуации, включая сеанс Протокол объявления [4], Протокол инициирования сеанса [11], Real- Протокол потоковой передачи времени [12], электронная почта с использованием MIME расширения и протокол передачи гипертекста. SDP предназначен для общего назначения, поэтому его можно использовать для более широкий спектр сетевых сред и приложений, чем просто каталоги многоадресных сеансов.Однако он не предназначен для поддерживать согласование содержимого сеанса или кодировок мультимедиа - это рассматривается как выходящий за рамки описания сеанса. 3. Глоссарий терминов Следующие термины используются в этом документе и имеют определенные значение в контексте этого документа. Конференция Мультимедийная конференция - это набор двух или более общающихся пользователей. вместе с программным обеспечением, которое они используют для общения. Сессия Мультимедийный сеанс - это набор отправителей и получателей мультимедиа. и потоки данных, текущие от отправителей к получателям.А мультимедийная конференция - это пример мультимедийного сеанса. Реклама сеанса См. Объявление о сеансе. Объявление о сессии Объявление сеанса - это механизм, с помощью которого сеанс описание передается пользователям в упреждающем режиме, т. е. Описание сеанса не было запрошено пользователем явным образом. Описание сеанса Четко определенный формат для передачи достаточной информации открыть для себя мультимедийный сеанс и участвовать в нем. 3.1. Терминология Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документ следует интерпретировать, как описано в RFC 2119. 4. Использование SDP 4.1. Объявления Multicast SDP - это протокол описания сеанса для мультимедийных сеансов. А общий режим использования - объявление клиентом сеанса конференции путем периодической многоадресной рассылки пакета объявлений общеизвестному многоадресный адрес и порт с использованием протокола объявления сеанса (SAP).Пакеты SAP - это пакеты UDP со следующим форматом: | -------------------- | | Заголовок SAP | | -------------------- | | текстовые данные | | ////////// Заголовок - это заголовок протокола объявления сеанса. SAP - это более подробно описано в сопроводительной записке [4] Текстовые данные - это описание сеанса SDP, как описано в этом памятка. Текстовые данные не должны превышать 1 Кбайт в длину. Если объявлено SAP, только одно объявление сеанса разрешено в один пакет.4.2. Объявления по электронной почте и в Интернете Альтернативные средства передачи описаний сеансов включают: электронная почта и всемирная паутина. И для электронной почты, и для WWW распространение, использование типа содержимого MIME "application / sdp" должен быть использован. Это позволяет автоматически запускать приложения. для участия в сеансе из WWW клиента или читателя почты стандартным образом. Обратите внимание, что объявления о многоадресных сеансах делаются только по электронной почте или Всемирная паутина (WWW) не имеет свойства, что получатель объявления сеанса может обязательно получить сеанс, потому что многоадресные сеансы могут быть ограничены по объему, и доступ к За пределами этой области возможен WWW-сервер или прием электронной почты.SAP объявления не страдают от этого несоответствия. 5. Требования и рекомендации Цель SDP - передать информацию о медиапотоках в мультимедийные сеансы, чтобы позволить получателям описания сеанса участвовать в сеансе. SDP в первую очередь предназначен для использования в межсетевое взаимодействие, хотя оно достаточно общее, чтобы описывать конференции в других сетевых средах. Мультимедийный сеанс для этих целей определяется как набор медиапотоки, существующие в течение некоторого времени.Медиа потоки может быть "многие ко многим". Время, в течение которого сеанс активен не обязательно быть непрерывным. До сих пор сеансы многоадресной рассылки в Интернете отличались от многие другие формы конференц-связи, в которых каждый получает трафик может присоединиться к сеансу (если трафик сеанса не зашифрован). В В такой среде SDP служит двум основным целям. Это средство сообщить о существовании сеанса и является средством передачи достаточная информация, чтобы можно было присоединиться и участвовать в сеанс.В одноадресной среде вероятна только последняя цель. быть актуальным. Таким образом, SDP включает: o Название и цель сеанса o Время (а) активности сеанса o СМИ, составляющие сессию o Информация для получения этих носителей (адреса, порты, форматы и скоро) Поскольку ресурсы, необходимые для участия в сеансе, могут быть ограничены, Также может потребоваться дополнительная информация: o Информация о пропускной способности, которая будет использоваться конференцией o Контактная информация лица, ответственного за сеанс Как правило, SDP должен передавать достаточно информации, чтобы иметь возможность присоединиться сеанс (с возможным исключением ключей шифрования) и объявлять ресурсы, которые будут использоваться неучастниками, которые могут нуждаться в знать.5.1. Информация для СМИ SDP включает: o Тип носителя (видео, аудио и т. д.) o Транспортный протокол (RTP / UDP / IP, H.320 и т. д.) o Формат носителя (видео H.261, видео MPEG и т. д.) Для сеанса многоадресной IP-рассылки также передаются следующие данные: o Многоадресный адрес для СМИ o Транспортный порт для СМИ Этот адрес и порт являются адресом и местом назначения. порт многоадресного потока, будь то отправленный, полученный или и то, и другое. Для одноадресного IP-сеанса передаются следующие данные: o Удаленный адрес для СМИ o Транспортный порт для контактного адреса Семантика этого адреса и порта зависит от носителя и транспортный протокол определен.По умолчанию это удаленный адрес и удаленный порт, на который отправляются данные, а также удаленный адрес и локальный порт для приема данных. Однако некоторые СМИ могут определять использовать их для создания канала управления фактическими медиа течь. 5.2. Информация о времени Сеансы могут быть как ограниченными, так и неограниченными по времени. Так или иначе они ограничены, они могут быть активны только в определенное время. SDP может передавать: o Произвольный список времени начала и окончания сеанса o Для каждого маршрута повторите раз, например «каждую среду в 10:00 для один час" Эта информация о времени согласована на глобальном уровне, независимо от местного часовой пояс или летнее время.5.3. Частные сеансы Можно создавать как открытые, так и частные сеансы. Частные сеансы обычно передаются путем шифрования сеанса описание для распространения. Детали того, как шифрование выполняются, зависят от механизма, используемого для передачи SDP - см. [4] как это делается для объявлений о сеансе. Если объявление о сеансе является частным, можно использовать это частное объявление для передачи ключей шифрования, необходимых для декодирования каждое из средств массовой информации на конференции, включая достаточно информации, чтобы знать, какая схема шифрования используется для каждого носителя.5.4. Получение дополнительной информации о сеансе Описание сеанса должно содержать достаточно информации, чтобы решить стоит ли участвовать в сеансе. SDP может включать дополнительные указатели в виде универсальных идентификаторов ресурсов (URI) для получения дополнительной информации о сеансе. 5.5. Категоризация Когда многие описания сеансов распространяются SAP или какой-либо другой другой рекламный механизм, может быть желательно фильтровать объявления, которые представляют интерес, от тех, кого нет.SDP поддерживает механизм категоризации для сеансов, способный автоматизируется. 5.6. Интернационализация Спецификация SDP рекомендует использовать символ ISO 10646. устанавливает в кодировке UTF-8 (RFC 2044), чтобы разрешить множество различных представляемые языки. Однако, чтобы помочь в компактном представления, SDP также допускает другие наборы символов, такие как ISO 8859-1 для использования при желании. Интернационализация применяется только к поля произвольного текста (имя сеанса и справочная информация), а не к SDP в целом.6. Спецификация SDP Описания сеансов SDP полностью текстовые с использованием ISO 10646 набор символов в кодировке UTF-8. Имена полей SDP и имена атрибутов использовать только US-ASCII подмножество UTF-8, но текстовые поля и значения атрибутов могут использовать полный набор символов ISO 10646. В текстовая форма, в отличие от двоичной кодировки, такой как ASN / 1 или XDR, был выбран для повышения мобильности, чтобы можно было использовать различные виды транспорта. для использования (например, описание сеанса в сообщении электронной почты MIME) и для позволяют гибкие текстовые наборы инструментов (например,g., Tcl / Tk) для использования генерировать и обрабатывать описания сеансов. Однако поскольку общая пропускная способность, выделенная для всех объявлений SAP, строго ограничено, кодировка намеренно компактна. Кроме того, поскольку объявления могут передаваться очень ненадежными средствами (например, email) или поврежден промежуточным сервером кэширования, кодировка была разработан с соблюдением строгих правил порядка и форматирования, поэтому большинство ошибок приведет к искаженным объявлениям, которые могут быть обнаружены легко и выбрасывается.Это также позволяет быстро отбрасывать зашифрованные объявления, для которых у получателя нет правильного ключа. Описание сеанса SDP состоит из нескольких строк текста форма= всегда состоит из одного символа и регистрационный. <значение> - это структурированная текстовая строка, формат которой зависит от <тип>. Это также будет иметь регистр, если конкретное поле определяет иное. Пробелы также не допускаются сторона знака `= '.В общем, <значение> - это либо количество полей разделенные одним пробелом или строкой свободного формата. Описание сеанса состоит из описания уровня сеанса (подробности, относящиеся ко всему сеансу и всем медиапотокам) и необязательно несколько описаний на уровне носителя (подробности, относящиеся к в один медиапоток). Объявление состоит из раздела уровня сеанса, за которым следует ноль или несколько разделов на уровне СМИ. Часть уровня сеанса начинается с `v = 'и продолжается до первого раздела уровня носителя.СМИ описание начинается со строки `m = 'и продолжается до следующего носителя описание или конец всего описания сеанса. В общем, значения уровня сеанса являются значениями по умолчанию для всех носителей, если они не переопределены эквивалентным значением на уровне СМИ. Когда SDP передается SAP, допускается только одно описание сеанса за пакет. Когда SDP передается другими способами, многие сеансы SDP описания могут быть объединены вместе (строка `v = 'указывает начало описания сеанса завершает предыдущий описание).Некоторые строки в каждом описании являются обязательными, а некоторые являются необязательными, но все они должны появляться в точном порядке, указанном здесь ( фиксированный порядок значительно улучшает обнаружение ошибок и позволяет парсер). Необязательные элементы отмечены знаком «*». Описание сеанса v = (версия протокола) o = (владелец / создатель и идентификатор сеанса). s = (имя сеанса) i = * (информация о сеансе) u = * (URI описания) e = * (адрес электронной почты) p = * (номер телефона) c = * (информация о подключении - не требуется, если присутствует на всех носителях) b = * (информация о пропускной способности) Одно или несколько временных описаний (см. Ниже) z = * (настройки часового пояса) k = * (ключ шифрования) a = * (ноль или более строк атрибутов сеанса) Ноль или более описаний носителей (см. Ниже) Описание времени t = (время активности сеанса) r = * (ноль или более повторений) Описание СМИ m = (имя носителя и транспортный адрес) i = * (заголовок медиа) c = * (информация о подключении - необязательно, если включена на уровне сеанса) b = * (информация о пропускной способности) k = * (ключ шифрования) a = * (ноль или более строк атрибутов мультимедиа) Набор "типовых" букв намеренно маленький и не предназначен для быть расширяемыми - парсеры SDP должны полностью игнорировать любые объявления который содержит "типичную" букву, которую он не понимает.В механизм "attribute" ("a =", описанный ниже) является основным средством для расширение SDP и адаптация его к конкретным приложениям или носителям. Некоторые атрибуты (перечисленные в этом документе) имеют определенные значение, но другие могут быть добавлены в приложении, медиа или сессионно-зависимая основа. Каталог сеанса должен игнорировать любые атрибут не понимает. Информация о соединении (`c = ') и атрибуте (` a =') в Раздел уровня сеанса применяется ко всем носителям этого сеанса, если только переопределено информацией о соединении или одноименным атрибутом в описании СМИ.Например, в приведенном ниже примере каждый media ведет себя так, как если бы ему был присвоен атрибут recvonly. Пример описания SDP: v = 0 o = mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s = Семинар SDP i = Семинар по протоколу описания сеанса u = http: //www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Марк Хэндли) c = В IP4 224.2.17.12/127 т = 2873397496 2873404696 a = recvonly m = аудио 49170 RTP / AVP 0 m = видео 51372 RTP / AVP 31 m = приложение 32416 udp wb a = orient: портрет Текстовые записи, такие как имя сеанса и информация, являются байтами. строки, которые могут содержать любой байт, за исключением 0x00 (Nul), 0x0a (перевод строки ASCII) и 0x0d (возврат каретки ASCII).Последовательность CRLF (0x0d0a) используется для завершения записи, хотя парсеры должны быть толерантный, а также принимать записи, заканчивающиеся одной новой строкой персонаж. По умолчанию эти байтовые строки содержат ISO-10646 символы в кодировке UTF-8, но это значение по умолчанию можно изменить с помощью атрибут charset. Версия протокола v = 0 В поле «v =» указывается версия протокола описания сеанса. Дополнительного номера версии нет. Происхождение o = <имя пользователя> <идентификатор сеанса> <версия> <тип сети> <тип адреса> <адрес> В поле «o =» указывается инициатор сеанса (его имя пользователя и адрес хоста пользователя) плюс идентификатор сеанса и сеанс номер версии. - логин пользователя на исходном хосте, или это "-" если исходный хост не поддерживает концепцию идентификаторов пользователей. <имя пользователя> не должно содержать пробелов. <идентификатор сеанса> - числовая строка так что кортеж , , , <тип адреса> и <адрес> образуют глобальный уникальный идентификатор для сессия. Метод выделения зависит от инструмента создания, но было предложено, чтобы временная метка сетевого протокола времени (NTP) была используется для обеспечения уникальности [1].<версия> - это номер версии этого объявления. Необходимо для объявлений прокси, чтобы определить, какое из нескольких объявлений для тот же сеанс является самым последним. И снова его использование зависит от инструмент создания, если <версия> увеличивается при модификации вносится в данные сеанса. Опять же, рекомендуется (но не обязательно), что используется метка времени NTP. <тип сети> - это текстовая строка, указывающая тип сети. Первоначально «IN» означает «Интернет».<адрес type> - текстовая строка, указывающая тип следующего адреса. Изначально определены «IP4» и «IP6». <адрес> - это глобальный уникальный адрес машины, с которой был создан сеанс. Для типа адреса IP4 это либо полный домен имя машины или десятичное представление IP с разделителями версия 4 адрес машины. Для типа адреса IP6 это - это либо полное доменное имя машины, либо сжатое текстовое представление IP-адреса версии 6 машина.И для IP4, и для IP6 полное доменное имя форма, которую ДОЛЖЕН быть предоставлен, если он не доступен, в котором В этом случае может быть заменен глобально уникальный адрес. Локальный IP адрес НЕ ДОЛЖЕН использоваться в любом контексте, где описание SDP может покинуть область, в которой адрес имеет смысл. Как правило, поле «o =» служит глобальным уникальным идентификатором для эта версия этого описания сеанса и подполя, кроме вместе взятые версии идентифицируют сеанс независимо от модификации.Имя сеанса s = <имя сеанса> Поле «s =» - это имя сеанса. Должен быть один и только один Поле "s =" для описания сеанса, и оно должно содержать ISO 10646. символы (но см. также атрибут charset ниже). Информация о сессии и СМИ i = <описание сеанса> Поле «i =» - это информация о сеансе. Может быть в максимум одно поле "i =" уровня сеанса на описание сеанса, и на максимум одно поле "i =" на носитель. Хотя его можно опустить, это не рекомендуется для объявлений о сеансах, а пользовательские интерфейсы для создание сессий должно требовать ввода текста.Если это присутствует он должен содержать символы ISO 10646 (но см. также атрибут charset ниже). Для каждого определения мультимедиа также можно использовать одно поле «i =». В определения мультимедиа, поля "i =" в первую очередь предназначены для маркировки медиапотоки. Таким образом, они, скорее всего, будут полезны, когда один сеанс имеет более одного отдельного медиапотока одного и того же тип носителя. Примером могут служить две разные доски, одна для слайды и один для отзывов и вопросов.URI u = o URI - это универсальный идентификатор ресурса, используемый клиентами WWW. o URI должен быть указателем на дополнительную информацию о конференция o Это поле не является обязательным, но если оно есть, его следует указать перед первым медиа-полем o В описании сеанса допускается не более одного поля URI. Адрес электронной почты и номер телефона e = <адрес электронной почты> p = <номер телефона> o В них указывается контактная информация лица, ответственного за конференция.Это не обязательно тот же человек, что создал анонс конференции. o Необходимо указать либо поле электронной почты, либо поле телефона. Допускаются дополнительные поля электронной почты и телефона. o Если они есть, их следует указать перед первым медиа-поле. o Для сеанса можно указать несколько полей электронной почты или телефона описание. o Номера телефонов следует указывать в общепринятом международном формате. формат - перед знаком "+" и международным кодом страны.Между кодом страны должен быть пробел или дефис ("-"). и остальной телефонный номер. Можно использовать пробелы и дефисы чтобы при желании разделить поле телефона для облегчения чтения. За пример: p = + 44-171-380-7777 или p = + 1 617 253 6011 o Как для адресов электронной почты, так и для номеров телефонов могут быть установлены дополнительные бесплатные текстовая строка, связанная с ними, обычно дающая имя человек, с которым можно связаться. Это должно быть заключено в круглые скобки, если они есть.Например: [email protected] (Марк Хэндли) Альтернативное соглашение о цитировании имен RFC822 также разрешено для адреса электронной почты и номера телефонов. Например, e = Марк Хэндли Свободная текстовая строка должна быть в наборе символов ISO-10646 с Кодировка UTF-8 или, альтернативно, в ISO-8859-1 или других кодировках если установлен соответствующий атрибут charset уровня сеанса. Данные подключения c = <тип сети> <тип адреса> <адрес подключения> Поле «c =» содержит данные подключения.Объявление сеанса должно содержать одно поле «c =» в каждом носителе. описание (см. ниже) или поле «c =» на уровне сеанса. Это может содержать поле "c =" уровня сеанса и одно дополнительное поле "c =" на описание мультимедиа, и в этом случае значения для каждого носителя имеют приоритет над настройки уровня сеанса для соответствующих носителей. Первое подполе - это тип сети, который представляет собой текстовую строку. с указанием типа сети. Первоначально "IN" определяется как что означает «Интернет». Второе подполе - это тип адреса.Это позволяет использовать SDP для сеансов, не основанных на IP. В настоящее время определен только IP4. Третье подполе - это адрес подключения. Дополнительная опция подполя могут быть добавлены после адреса подключения в зависимости от значение поля <тип адреса>. Для адресов IP4 адрес подключения определяется следующим образом: o Обычно адрес подключения представляет собой многоадресную IP-рассылку класса D. групповой адрес. Если сеанс не является многоадресным, то адрес подключения содержит полное доменное имя или одноадресный IP-адрес ожидаемого источника данных или ретранслятора данных, или приемник данных, определяемый дополнительными полями атрибутов.Нет ожидается, что полные доменные имена или одноадресные адреса будет дан в описании сеанса, которое передается многоадресное объявление, хотя это не запрещено. Если одноадресный поток данных должен проходить через сетевой адрес переводчик, использование полного доменного имени, а не РЕКОМЕНДУЕТСЯ одноадресный IP-адрес. В остальных случаях использование IP-адрес для указания конкретного интерфейса на многосетевом хосте может потребоваться.Таким образом, эта спецификация оставляет решение как к которому использовать до отдельного приложения, но все приложения ДОЛЖНЫ поддерживать прием обоих форматов. o Конференции, использующие адрес многоадресного IP-соединения, также должны иметь значение времени жизни (TTL) присутствует в дополнение к многоадресной рассылке адрес. TTL и адрес вместе определяют область действия какие многоадресные пакеты, отправленные в этой конференции, будут отправлены. TTL значения должны быть в диапазоне 0–255.TTL для сеанса добавляется к адресу с помощью косой черты как разделитель. Пример: c = IN IP4 224.2.1.1/127 Иерархические или многоуровневые схемы кодирования - это потоки данных, в которых кодирование из одного медиаисточника разбито на несколько слои. Ресивер может выбрать желаемое качество (а значит пропускная способность), подписавшись только на подмножество этих уровней. Такие многоуровневые кодировки обычно передаются в многоадресной рассылке группы, чтобы разрешить удаление многоадресной рассылки.Этот метод сохраняет нежелательные трафик с сайтов, требующих только определенных уровней иерархии. Для приложений, требующих нескольких групп многоадресной рассылки, мы разрешаем Для адреса подключения следует использовать следующие обозначения: <базовый адрес многоадресной рассылки> / / <количество адресов> Если количество адресов не указано, предполагается, что оно равно одному. Назначенные таким образом многоадресные адреса непрерывно выделяются выше базовый адрес, например: c = ВХОД IP4 224.2.1.1 / 127/3 укажет, что адреса 224.2.1.1, 224.2.1.2 и 224.2.1.3 являются для использования с ttl 127. Это семантически идентично включение нескольких строк "c =" в описание мультимедиа: c = IN IP4 224.2.1.1/127 c = ВХОД IP4 224.2.1.2/127 c = ВХОД IP4 224.2.1.3/127 Несколько адресов или строк "c =" можно указать только для каждого медиа, а не для поля «c =» уровня сеанса. Использование обозначения косой черты, описанное выше, для Одноадресные IP-адреса.Пропускная способность b = <модификатор>: <значение-пропускной способности> o Это указывает предлагаемую полосу пропускания, которая будет использоваться сеансом или media и не является обязательным. o в килобитах в секунду o <модификатор> - это одно буквенно-цифровое слово, дающее значение показатель пропускной способности. o Изначально определены два модификатора: CT Conference Total: неявная максимальная полоса пропускания связана с каждый TTL на Mbone или в рамках конкретной многоадресной рассылки область административной области (пропускная способность в мегабайтах vs.Пределы TTL приведено в FAQ MBone). Если пропускная способность сеанса или медиа в сеанс отличается от пропускной способности, неявной из области видимости, строка `b = CT: ... 'должна быть предоставлена для сеанса, дающего предлагаемый верхний предел используемой полосы пропускания. Основная цель это должно дать приблизительное представление о том, два или более конференции могут сосуществовать одновременно. Максимум, зависящий от приложения AS: полоса пропускания интерпретируется как для конкретного приложения, т.е.е., будет концепция приложения максимальная пропускная способность. Обычно это будет совпадать с тем, что установлено на контроль "максимальной пропускной способности" приложения, если применимо. Обратите внимание, что CT дает общее значение пропускной способности для всех носителей на все сайты. AS дает показатель пропускной способности для одного носителя при один сайт, хотя может быть много сайтов, отправляющих одновременно. o Механизм расширения: авторы инструментов могут определять экспериментальную полосу пропускания модификаторы, добавив к их модификатору префикс «X-».Например: б = X-YZ: 128 Парсеры SDP должны игнорировать поля пропускной способности с неизвестными модификаторами. Модификаторы должны быть буквенно-цифровыми и, хотя ограничение по длине учитывая, они рекомендуется быть короткими. Время, время повтора и часовые пояса t = <время начала> <время окончания> o поля "t =" указывают время начала и окончания конференции. сеанс. Если сеанс активен, можно использовать несколько полей "t =" в несколько нерегулярных интервалов времени; каждое дополнительное поле "t =" указывает дополнительный период времени, в течение которого сеанс будет быть активным.Если сеанс активен в обычное время, отображается "r =" поле (см. ниже) следует использовать в дополнение и после поле "t =" - в этом случае поле "t =" указывает начало и время остановки повторяющейся последовательности. o Первое и второе подполя указывают время начала и окончания для конференции соответственно. Эти значения являются десятичными представление значений времени протокола сетевого времени (NTP) в секунды [1]. Чтобы преобразовать эти значения во время UNIX, вычтите десятичный 2208988800.o Если время остановки установлено на ноль, то сеанс не ограничен, хотя он не станет активным до истечения времени запуска. Если время начала также равно нулю, сеанс считается постоянным. Пользовательские интерфейсы должны категорически препятствовать созданию неограниченные и постоянные сеансы, поскольку они не дают информации о когда сеанс фактически завершится, и поэтому сделайте планирование сложно. Можно сделать общее предположение при отображении неограниченного сеансы, для которых не истекло время ожидания для пользователя, неограниченное сеанс будет активен только через полчаса с текущего время или время начала сеанса, в зависимости от того, что будет позже.Если требуется другое поведение, необходимо указать время окончания и при необходимости изменяются при появлении новой информации о том, когда сессия действительно должна закончиться. Постоянные сеансы могут отображаться пользователю как никогда неактивные. если нет связанных времен повтора, которые точно указывают, когда сеанс будет активным. Как правило, постоянные сессии должны не создаваться ни для одного сеанса, продолжительность которого должна быть меньше более 2 месяцев, и не рекомендуется проводить сеансы, иметь продолжительность менее 6 месяцев.r = <интервал повтора> <активная продолжительность> <список смещений от начала- время> o Поля "r =" определяют время повтора для сеанса. Например, если сессия активна в 10 утра в понедельник и в 11 утра во вторник для одного час каждую неделю в течение трех месяцев, затем <время начала> в соответствующее поле "t =" будет представлением NTP 10 утра на в первый понедельник <интервал повтора> будет 1 неделя, <активная продолжительность> будет 1 час, а смещения будут нулевыми и 25 часов.Соответствующее время окончания поля "t =" будет Представление NTP конца последней сессии три месяца позже. По умолчанию все поля указаны в секундах, поэтому символы «r =» и «t =» поля могут быть: т = 3034423619 3042462419 г = 604800 3600 0 Чтобы объявления были более компактными, время также может быть указано в единицах. дней, часов или минут. Синтаксис для них - число сразу за которым следует один чувствительный к регистру символ.Использование дробных единиц не допускается - следует использовать меньшие единицы. вместо. Допускаются следующие символы спецификации устройства: d - дни (86400 секунд) h - минуты (3600 секунд) м - минуты (60 секунд) s - секунды (разрешено для полноты, но не рекомендуется) Таким образом, это объявление также могло быть написано: г = 7д 1ч 0 25ч Ежемесячные и ежегодные повторы в настоящее время нельзя напрямую указать с одним временем повтора SDP - вместо этого должны быть отдельные поля "t" использоваться для явного перечисления времени сеанса.z = <время настройки> <смещение> <время настройки> <смещение> .... o Чтобы запланировать повторный сеанс, который охватывает смену дневного света- экономя время к стандартному времени или наоборот, необходимо укажите смещения от базового времени повторения. Это необходимо потому что разные часовые пояса меняют время в разное время суток, разные страны переходят на летнее время или наоборот даты, а в некоторых странах летнее время вообще отсутствует.Таким образом, чтобы запланировать сеанс в одно и то же время зимой и летом должна быть возможность однозначно указать, часовой пояс, в котором запланирован сеанс. Чтобы упростить эту задачу для получателям, мы позволяем отправителю указывать время NTP, которое происходит регулировка зоны и смещение от времени, когда сеанс был впервые запланирован Поле "z" позволяет отправителю укажите список этих времен регулировки и смещений от базы время.Примером может быть: z = 2882844526 -1ч 2898848070 0 Это указывает, что в момент времени 2882844526 развертка времени, по которой рассчитывается время повтора сеанса смещено на 1 час назад, и что в момент времени 2898848070 исходная временная база сеанса восстановлен. Корректировки всегда относятся к указанному началу время - они не суммируются. o Если сеанс, вероятно, продлится несколько лет, ожидается тот объявление о сеансе будет периодически изменяться, а не передать корректировки за несколько лет в одном объявлении.Ключи шифрования k = <метод> k = <метод>: <ключ шифрования> o Протокол описания сеанса может использоваться для передачи шифрования ключи. Ключевое поле допускается перед первой медиа-записью (в в этом случае он применяется ко всем носителям в сеансе) или для каждого запись в СМИ по мере необходимости. o Формат ключей и их использование выходят за рамки настоящего документ, но см. [3]. o Метод указывает механизм, который будет использоваться для получения полезного ключ внешними средствами или из заданного зашифрованного ключа шифрования.Определены следующие методы: k = clear: <ключ шифрования> Ключ шифрования (как описано в [3] для медиапотоков RTP под AV-профилем) включается без преобразования в этот ключ поле. k = base64: <закодированный ключ шифрования> Ключ шифрования (как описано в [3] для медиапотоков RTP под профилем AV) включен в это ключевое поле, но был кодируется base64, потому что он включает символы, которые запрещено в SDP.k = uri:
Универсальный идентификатор ресурса, используемый клиентами WWW: включены в это ключевое поле. URI относится к данным содержащий ключ, и может потребоваться дополнительная аутентификация прежде, чем ключ можно будет вернуть. Когда поступает запрос в заданный URI, тип содержимого MIME ответа определяет кодировка ключа в ответе. Ключ не должен быть получается, пока пользователь не захочет присоединиться к сеансу, чтобы уменьшить синхронизация запросов к серверу (-ам) WWW.k = подсказка В это описание SDP не включен ключ, но сеанс или медиапоток, на который ссылается это ключевое поле, зашифрован. В у пользователя должен быть запрошен ключ при попытке присоединиться к сеанс, и этот пользовательский ключ следует затем использовать для расшифровать медиапотоки. Атрибуты a = <атрибут> a = <атрибут>: <значение> Атрибуты являются основным средством расширения SDP. Атрибуты могут быть определенными для использования в качестве атрибутов "уровня сеанса", "уровня носителя" атрибуты или и то, и другое.Медиа-описание может иметь любое количество атрибутов (поля "a =") которые специфичны для СМИ. Их называют «медиа-уровнем». атрибуты и добавить информацию о медиапотоке. Атрибут поля также могут быть добавлены перед первым медиа-полем; эти Атрибуты "уровня сеанса" передают дополнительную информацию, которая применяется к конференции в целом, а не к отдельным СМИ; ан примером может быть политика управления конференц-залом. Поля атрибутов могут быть двух форм: o атрибуты собственности.Атрибут свойства просто имеет форму "а = <флаг>". Это бинарные атрибуты, и наличие Атрибут означает, что атрибут является свойством сеанса. Примером может быть «a = recvonly». o значения атрибутов. Атрибут значения имеет форму "a = <атрибут>: <значение>". Примером может служить доска может иметь значение атрибута "a = orient: landscape" Интерпретация атрибутов зависит от вызываемого медиаинструмента. Таким образом, получатели описаний сеансов должны быть настроены в их интерпретация объявлений в целом и атрибутов в частности.Имена атрибутов должны быть в подмножестве US-ASCII стандарта ISO-10646 / UTF-8. Значения атрибутов представляют собой байтовые строки и МОГУТ использовать любое байтовое значение, кроме 0x00 (Nul), 0x0A (LF) и 0x0D (CR). По умолчанию значения атрибутов должны интерпретироваться как в наборе символов ISO-10646 с UTF-8 кодирование. В отличие от других текстовых полей, значения атрибутов НЕ обычно зависит от атрибута `charset ', так как при этом сравнение с известными значениями проблематично. Однако когда атрибут определен, он может быть определен как зависящий от кодировки, в в этом случае его значение следует интерпретировать в кодировке сеанса а не в ISO-10646.Атрибуты, которые будут обычно использоваться, могут быть зарегистрированы в IANA. (см. Приложение B). Незарегистрированные атрибуты должны начинаться с "X-", чтобы предотвращать непреднамеренное столкновение с зарегистрированными атрибутами. В любом случае, если получен непонятный атрибут, он должен просто игнорируется получателем. Объявления СМИ m = Описание сеанса может содержать несколько описаний мультимедиа. Каждое описание мультимедиа начинается с поля «m =» и заканчивается либо по следующему полю "m =", либо к концу сеанса описание.Медиа-поле также имеет несколько подполей: o Первое подполе - это тип носителя. В настоящее время определенные медиа "аудио", "видео", "приложение", "данные" и "управление", хотя это список может быть расширен по мере появления новых способов общения (например, телеприсутствие). Разница между «приложением» и «данными» заключается в что первое - это поток мультимедиа, такой как информация с доски, и последний - это передача больших объемов данных, например, многоадресная передача программы исполняемые файлы, которые обычно не отображаются пользователю."control" используется для указания дополнительного управления конференцией канал для сеанса. o Второе подполе - это транспортный порт, к которому медиа поток будет отправлен. Значение транспортного порта зависит от сеть используется, как указано в соответствующем поле "c" и на транспортном протоколе, определенном в третьем подполе. разное порты, используемые мультимедийным приложением (например, порт RTCP, см. [2]) должен быть получен алгоритмически из базового медиа-порта.Примечание. Для транспортов, основанных на UDP, значение должно быть в диапазоне От 1024 до 65535 включительно. Для соответствия RTP это должно быть количество. Для приложений, в которых используются иерархически закодированные потоки. отправлено на одноадресный адрес, может потребоваться указать несколько транспортные порты. Это делается с использованием обозначений, аналогичных этой используется для IP-адресов многоадресной рассылки в поле "c =": m = / <количество портов> В таком случае используемые порты зависят от транспортного протокола.Для RTP для данных используются только четные порты, а соответствующий нечетный порт на единицу больше используется для RTCP. Например: m = видео 49170/2 RTP / AVP 31 будет указывать, что порты 49170 и 49171 образуют одну пару RTP / RTCP и 49172 и 49173 образуют вторую пару RTP / RTCP. RTP / AVP - это транспортный протокол, а 31 - формат (см. ниже). Недопустимо указывать оба нескольких адреса в поле "c =" и для указания нескольких портов в поле "m =" в том же описании сеанса.o Третье подполе - транспортный протокол. Транспорт значения протокола зависят от поля типа адреса в "c =" поля. Таким образом, поле «c =» IP4 определяет, что транспортный протокол работает по IP4. Для IP4 обычно ожидается, что большинство Медиа-трафик будет передаваться как RTP через UDP. Следующее транспортные протоколы определены предварительно, но могут быть расширены путем регистрации новых протоколов в IANA: - RTP / AVP - транспортный протокол IETF в реальном времени, использующий Аудио / видео профиль переносится через UDP.- udp - Протокол дейтаграмм пользователя Если приложение использует один комбинированный частный медиаформат и транспортный протокол через UDP, просто указав транспортный протокол как udp и с использованием поля формата для различения рекомендуется комбинированный протокол. Если транспортный протокол используется через UDP для передачи нескольких различных типов мультимедиа, которые необходимо определяется каталогом сеанса, затем указывается транспорт протокол и медиаформат отдельно необходимо.RTP - это пример транспортного протокола, который несет множественную полезную нагрузку форматы, которые должны различаться по каталогу сеанса для него знать, как запустить соответствующие инструменты, реле, смесители или рекордеры. Основная причина указать транспортный протокол в дополнение к формат мультимедиа состоит в том, что те же стандартные форматы мультимедиа могут быть переносится по различным транспортным протоколам, даже если сеть протокол тот же - исторический пример - аудио PCM и Аудио RTP PCM.Кроме того, реле и средства контроля, которые возможны специфичные для транспортного протокола, но не зависящие от формата. Для медиапотоков RTP, работающих под профилем аудио / видео RTP [3] поле протокола - «RTP / AVP». Если другие профили RTP определены в будущем, их профили будут указаны в том же путь. Например, в поле протокола "RTP / XYZ" указывается RTP. работает под профилем с кратким названием «XYZ». o Четвертое и последующие подполя - это медиа-форматы.Для аудио и видео, это обычно будет тип полезной нагрузки мультимедиа, как определено в профиле аудио / видео RTP. Когда приводится список форматов полезной нагрузки, это означает, что все эти форматы могут использоваться в сеансе, но первый из них форматы - это формат по умолчанию для сеанса. Для носителей, транспортный протокол которых не является RTP или UDP, формат поле зависит от протокола. Такие форматы должны быть определены в документ дополнительной спецификации. Для носителей, транспортным протоколом которых является RTP, SDP может использоваться для обеспечивают динамическую привязку кодирования мультимедиа к типу полезной нагрузки RTP.Имена кодировок в профиле RTP AV не указывают уникальные кодировки аудио (с точки зрения тактовой частоты и количества аудио каналы), поэтому они не используются непосредственно в полях формата SDP. Вместо этого следует использовать номер типа полезной нагрузки, чтобы указать формат для статических типов полезной нагрузки и номер типа полезной нагрузки вместе с дополнительной информацией о кодировке следует использовать для динамического выделенные типы полезной нагрузки. Примером статического типа полезной нагрузки является одиночный кодированный PCM по закону u. канальный звук с дискретизацией 8 кГц.Это полностью определено в Профиль аудио / видео RTP как тип полезной нагрузки 0, поэтому поле мультимедиа для такой поток, отправляемый на порт UDP 49232: m = видео 49232 RTP / AVP 0 Пример динамического типа полезной нагрузки - это 16-битное линейное кодирование. стереозвук с частотой дискретизации 16 кГц. Если мы хотим использовать динамический RTP / AVP тип полезной нагрузки 98 для такого потока, дополнительная информация требуется для его декодирования: m = видео 49232 RTP / AVP 98 a = об / мин: 98 L16 / 16000/2 Общая форма атрибута rtpmap: a = rtpmap: <тип полезной нагрузки> <название кодировки> / <тактовая частота> [/ <кодировка параметры>] Для аудиопотоков <параметры кодирования> могут указывать количество аудиоканалы.Этот параметр можно не указывать, если количество Каналы - один при условии, что дополнительных параметров не требуется. За видеопотоки, параметры кодирования на данный момент не указаны. Дополнительные параметры могут быть определены в будущем, но Параметры, специфичные для кода, добавлять не следует. Параметры добавлены в атрибут rtpmap должен быть только тем, что требуется для сеанса каталог, чтобы выбрать подходящий носитель. участвовать в сеансе. Параметры кодека должны быть добавлены другие атрибуты.Для каждого формата мультимедиа можно определить до одного атрибута rtpmap. указано. Таким образом, мы могли бы иметь: m = аудио 49230 RTP / AVP 96 97 98 а = об / мин: 96 L8 / 8000 а = об / мин: 97 L16 / 8000 а = об / мин: 98 L16 / 11025/2 Профили RTP, которые определяют использование динамических типов полезной нагрузки, должны определить набор допустимых имен кодировки и / или средства для регистрации имена кодировок, если этот профиль будет использоваться с SDP.Экспериментальные форматы кодирования также можно указать с помощью rtpmap. Форматы RTP, которые не зарегистрированы как имена стандартных форматов, должны ему предшествует "X-". Таким образом, новый экспериментальный избыточный звук поток под названием GSMLPC с использованием типа динамической полезной нагрузки 99 может быть указано как: m = видео 49232 RTP / AVP 99 a = rtpmap: 99 X-GSMLPC / 8000 Такая экспериментальная кодировка требует, чтобы любой сайт, желающий получить медиапоток имеет соответствующее настроенное состояние в его каталог сеанса, чтобы узнать, какие инструменты подходят.Обратите внимание, что аудиоформаты RTP обычно не содержат информации о количестве образцов в пакете. Если не по умолчанию (как определено в профиле аудио / видео RTP) требуется пакетизация, атрибут «ptime» используется, как указано ниже. Подробнее об аудио- и видеоформатах RTP см. [3]. o Форматы для носителей без RTP должны быть зарегистрированы как контент MIME. типы, как описано в Приложении B. Например, доска LBL приложение может быть зарегистрировано как приложение типа содержимого MIME / wb с учетом требований кодирования, указывающих, что он работает через UDP, без соответствующего формата файла.В SDP это будет выражается с помощью комбинации поля "media" и "fmt" поле, как показано ниже: m = приложение 32416 udp wb Предлагаемые атрибуты Предлагаются следующие атрибуты. Поскольку авторы приложений могут добавлять новые атрибуты по мере необходимости, этот список не исчерпывающий. a = cat: <категория> Этот атрибут дает разделенную точками иерархическую категорию сессия. Это необходимо для того, чтобы приемник мог фильтровать нежелательные сеансы по категориям.Вероятно, это было бы обязательным отдельное поле, за исключением его экспериментального характера в настоящее время. Это атрибут уровня сеанса, не зависящий от кодировки. a = keywds: <ключевые слова> Как и атрибут кота, это помогает идентифицировать разыскиваемых сеансы на приемнике. Это позволяет получателю выбрать интересная сессия на основе ключевых слов, описывающих цель сессия. Это атрибут уровня сеанса. Это кодировка зависимый атрибут, то есть его значение следует интерпретировать в кодировке, указанной для описания сеанса, если указан или по умолчанию в ISO 10646 / UTF-8.a = инструмент: <название и версия инструмента> Это дает имя и номер версии инструмента, используемого для создания описание сеанса. Это атрибут уровня сеанса и не зависит от кодировки. a = ptime: <время пакета> Это дает время в миллисекундах, представленное медиа в пакете. Это, вероятно, имеет значение только для аудио данные. Не обязательно знать ptime для декодирования RTP или ндс аудио, и он предназначен как рекомендация для кодирование / пакетирование аудио.Это медиа-атрибут, не зависит от кодировки. a = recvonly Это указывает, что инструменты должны запускаться в режиме только получения. режим, если применимо. Это может быть сеанс или медиа атрибут и не зависит от кодировки. a = sendrecv Это указывает, что инструменты должны запускаться при отправке и режим приема. Это необходимо для интерактивных конференций с такие инструменты, как wb, который по умолчанию работает в режиме только приема. Это может быть либо атрибут сеанса, либо медиа, и не зависит от кодировка.a = sendonly Это указывает, что инструменты должны запускаться в режиме только для отправки Режим. Примером может быть другой одноадресный адрес для использоваться для пункта назначения трафика, чем для источника трафика. В В таком случае можно использовать два описания мультимедиа, одно только для отправки и один recvonly. Это может быть атрибут сеанса или медиа, но обычно используется только как атрибут мультимедиа, а не зависит от кодировки. a = orient: <ориентация доски> Обычно это используется только в спецификации носителя для интерактивной доски.Он определяет ориентацию доски на экране. Это медиа-атрибут. Допустимые значения - "портрет", «пейзаж» и «морской пейзаж» (перевернутый пейзаж). Нет зависит от кодировки a = type: <тип конференции> Это определяет тип конференции. Предлагаемые значения: "трансляция", "встреча", "модерируемый", "тест" и "h432". `recvonly 'должен быть значением по умолчанию для сеансов` type: broadcast', "type: meeting" должен подразумевать "sendrecv" и "type: moderated" должен указывать на использование инструмента для контроля пола и что медиа-инструменты запускаются, чтобы «отключить» новые сайты, присоединяющиеся к конференция.Указание типа атрибута: h432 указывает, что это вольно связанный сеанс является частью сеанса H.332, как определено в ITU Спецификация H.332 [10]. Медиа-инструменты должны быть запущены `recvonly '. Указание типа атрибута: test предлагается в качестве подсказки, что, если явно не указано иное, получатели могут безопасно избегать отображение этого описания сеанса для пользователей. Атрибут type является атрибутом уровня сеанса и не является зависит от кодировки.a = набор символов: <набор символов> Это определяет набор символов, который будет использоваться для отображения имя сеанса и информационные данные. По умолчанию ISO-10646 используется набор символов в кодировке UTF-8. Если более компактный требуется представление, могут использоваться другие наборы символов, например как ISO-8859-1 для языков Северной Европы. В частности, ISO 8859-1 определяется следующим атрибутом SDP: a = кодировка: ISO-8859-1 Это атрибут уровня сеанса; если этот атрибут присутствует, он должен быть перед первым медиа-полем.Указанная кодировка ДОЛЖЕН быть одним из зарегистрированных в IANA, например ISO-8859-1. Идентификатор набора символов представляет собой строку US-ASCII и ДОЛЖЕН быть сравнивается с идентификаторами IANA, используя регистронезависимый сравнение. Если идентификатор не распознан или нет поддерживается, все строки, на которые он влияет, ДОЛЖНЫ рассматриваться как байтовые строки. Обратите внимание, что указанный набор символов ДОЛЖЕН все же запрещать использование байтов 0x00 (Nul), 0x0A (LF) и 0x0d (CR).Наборы символов требование использования этих символов ДОЛЖНО определять кавычки механизм, который предотвращает появление этих байтов в текстовых полях. a = sdplang: <языковой тег> Это может быть атрибут уровня сеанса или атрибут уровня мультимедиа. В качестве атрибута уровня сеанса он определяет язык для описание сеанса. В качестве атрибута уровня мультимедиа он определяет язык для любого связанного поля информации SDP на уровне носителя с этими СМИ.Можно указать несколько атрибутов sdplang либо на уровне сеанса, либо на уровне СМИ, если в описание сеанса или медиа используют несколько языков, на которых случае порядок атрибутов указывает порядок важность различных языков в сеансе или СМИ из от наиболее важного до наименее важного. Как правило, отправка описаний сеансов, состоящих из нескольких языки не следует поощрять. Вместо этого несколько описаний должны быть отправлены с описанием сеанса, по одному на каждом языке.Однако это невозможно со всеми транспортными механизмами, и поэтому несколько атрибутов sdplang разрешены, но не рекомендуемые. Значение атрибута sdplang должно соответствовать одному языку RFC 1766. тег в US-ASCII. Это не зависит от атрибута charset. Атрибут sdplang ДОЛЖЕН быть указан, если сеанс достаточный простор для пересечения географических границ, где язык получателей не может быть принят, или где сеанс на языке, отличном от принятой в данной местности нормы.a = lang: <языковой тег> Это может быть атрибут уровня сеанса или атрибут уровня мультимедиа. В качестве атрибута уровня сеанса он определяет язык по умолчанию. для описываемого сеанса. В качестве атрибута уровня носителя он определяет язык для этого носителя, отменяя любой сеанс - указанный уровень языка. Можно указать несколько атрибутов языка. предоставляется либо на уровне сеанса, либо на уровне носителя, если несколько языков если в описании сеанса или мультимедиа используется несколько языков, в в этом случае порядок атрибутов указывает порядок важность различных языков в сеансе или СМИ из от наиболее важного до наименее важного.Значение атрибута lang должно быть одним тегом языка RFC 1766. в US-ASCII. Это не зависит от атрибута charset. А атрибут lang СЛЕДУЕТ указывать, если сеанс достаточный простор для пересечения географических границ, где язык получателей не может быть принят, или где сеанс на языке, отличном от принятой в данной местности нормы. a = частота кадров: <частота кадров> Это дает максимальную частоту кадров видео в кадрах / сек.это предназначена как рекомендация по кодированию видеоданных. Десятичные представления дробных значений с использованием нотации "<целое число>. <фракция>" разрешены. Это медиа-атрибут, определен только для видео носителей и не зависит от кодировки. a = качество: <качество> Это дает представление о качестве кодирования как целочисленное значение. Назначение атрибута качества для видео - указать нестандартный компромисс между частотой кадров и качеством неподвижного изображения.Для видео значение в диапазоне от 0 до 10 со следующими предполагаемое значение: 10 - лучшее качество неподвижного изображения, которое может обеспечить схема сжатия дайте. 5 - поведение по умолчанию без предложения качества. 0 - худшее качество неподвижного изображения, по мнению разработчика кодека все еще можно использовать. Это медиа-атрибут, не зависящий от кодировки. a = fmtp: <формат> <параметры формата> Этот атрибут позволяет параметры, специфичные для конкретный формат, который должен передаваться таким образом, что SDP не имеет понять их.Формат должен быть одним из форматов указано для СМИ. Параметры, зависящие от формата, могут быть любыми набор параметров, которые должны быть переданы SDP и предоставлены без изменений для медиа-инструмента, который будет использовать этот формат. Это медиа-атрибут, не зависящий от кодировки. 6.1. Политика управления конференц-связью Есть некоторые дебаты по поводу того, как должна быть политика управления конференциями. общались. В целом авторы считают, что неявный декларативный стиль указания управления конференцией желателен там, где возможно.В простом декларативном стиле используется одно поле атрибута конференции. перед первым медиа-полем, возможно, дополненное свойствами например recvonly для некоторых медиа-инструментов. Эта конференция Атрибут передает политику управления конференцией. Примером может быть: a = type: модерируемый Однако в некоторых случаях этого может быть недостаточно. чтобы сообщить подробности необычной политики управления конференцией. Если это так, то атрибут конференции, указывающий внешний может быть установлен, и тогда может быть установлено одно или несколько полей "медиа" используется для указания инструментов управления конференцией и данных конфигурации для этих инструментов.Примером является сеанс ITU H.332: c = ВХОД IP4 224.5.6.7 a = тип: h432 m = аудио 49230 RTP / AVP 0 m = видео 49232 RTP / AVP 31 m = приложение 12349 udp wb m = контроль 49234 h423 mc c = В IP4 134.134.157.81 В этом примере атрибутом общей конференции (тип: h432) является указано, что управление конференцией будет обеспечиваться внешний инструмент H.332 и контактные адреса для сеанса H.323 дан многоточечный контроллер.В этом документе только декларативный стиль управления конференцией декларация указана. Другие формы управления конференцией должны указать соответствующий атрибут типа и определить последствия этого для управляющих СМИ. 7. Соображения безопасности SDP - это формат описания сеанса, который описывает мультимедиа сеансы. Не следует доверять описанию сеанса, если в нем нет был получен аутентифицированным транспортным протоколом от доверенного источник. Для распространения можно использовать множество различных транспортных протоколов. описание сеанса, и характер аутентификации будет отличаться от транспорта до транспорта.Один транспорт, который будет часто использоваться для распространения сеанса descriptions - это протокол объявления сеанса (SAP). SAP предоставляет механизмы шифрования и аутентификации, но из-за характер объявлений о сессиях вполне вероятно, что есть много случаи, когда отправитель объявления сеанса не может быть аутентифицированы, потому что они ранее неизвестны получателю объявление и поскольку нет общей инфраструктуры открытого ключа имеется в наличии.При получении описания сеанса через неаутентифицированный транспорт механизм или от ненадежной стороны, программное обеспечение, анализирующее сеанс следует принять некоторые меры предосторожности. Описание сеанса содержит информация, необходимая для запуска программного обеспечения в системе приемников. Программное обеспечение, которое анализирует описание сеанса, НЕ ДОЛЖНО запускаться другое программное обеспечение, кроме того, которое специально настроено как соответствующее программное обеспечение для участия в мультимедийных сеансах. это обычно считается НЕПРАВИЛЬНЫМ для программного анализа сеанса описание для запуска в системе пользователя программного обеспечения, которое подходит для участия в мультимедийных сеансах без участия пользователя сначала получить информацию о том, что такое программное обеспечение будет запущено, и их согласие.Таким образом, описание сеанса поступает по сеансу объявление, электронное письмо, приглашение на сеанс или веб-страницу НЕ ДОЛЖНЫ доставить пользователя в {it интерактивный} мультимедийный сеанс без пользователь знает, что это произойдет. Как это не всегда просто определить, является ли сеанс интерактивным или нет, приложения которые не уверены, следует предполагать, что сеансы интерактивны. В этой спецификации нет атрибутов, которые позволили бы получатель описания сеанса должен быть проинформирован о запуске мультимедиа инструменты в режиме, в котором они по умолчанию передают.Под некоторыми обстоятельства, возможно, уместно определить такие атрибуты. Если это делается приложением, анализирующим описание сеанса, содержащее такие атрибуты ДОЛЖНЫ либо игнорировать их, либо сообщать пользователю, что присоединение к этой сессии приведет к автоматической передаче мультимедийные данные. Поведение по умолчанию для неизвестного атрибута: игнорировать это. Описания сеансов могут быть проанализированы в промежуточных системах, таких как брандмауэры для открытия дыры в брандмауэре, чтобы позволить участие в мультимедийных сессиях.Считается НЕПРАВИЛЬНО для брандмауэра открывать такие дыры для одноадресных данных потоки, если описание сеанса не входит в запрос изнутри брандмауэр. Для многоадресных сеансов локальные администраторы могут применять свои собственные политики, но исключительное использование «локальных» или «сайтов» локальная "административная область внутри брандмауэра и отказ от брандмауэр для открытия дыры для таких прицелов обеспечит разделение глобальных многоадресных сессий из локальных.Приложение A. Грамматика SDP В этом приложении представлена грамматика расширенного BNF для SDP. ABNF - это определено в RFC 2234. объявление = прото-версия поле происхождения поле имени сеанса информационное поле поле uri email-поля телефонные поля поле связи поля пропускной способности временные поля ключевое поле поля атрибутов медиа-описания proto-version = "v =" 1 * ЦИФРОВОЙ CRLF ; эта памятка описывает версию 0 origin-field = "o =" пространство для имени пользователя пространство сесс-идентификаторов пространство сессионных версий пространство nettype пространство addrtype адрес CRLF session-name-field = "s =" текст CRLF информация-поле = ["i =" текст CRLF] uri-field = ["u =" uri CRLF] email-fields = * ("e =" адрес электронной почты CRLF) phone-fields = * ("p =" номер телефона CRLF) connection-field = ["c =" пробел nettype пробел addrtype адрес-соединения CRLF] ; поле подключения должно присутствовать ; в каждом описании СМИ или в ; уровень сеанса bandwidth-fields = * ("b =" bwtype ":" пропускная способность CRLF) поля времени = 1 * ("t =" время начала пространство время остановки * (Повторяющиеся поля CRLF) CRLF) [настройки зоны CRLF] repeat-fields = "r =" интервал повторения пробел, время ввода 1 * (пробел - время) zone-adjustments = time space ["-"] типизированное время * (пространство-время-пространство ["-"] типизированное время) key-field = ["k =" CRLF типа ключа] key-type = "подсказка" | "clear:" ключевые данные | "base64:" ключевые данные | "ури:" ури ключевые данные = безопасная для электронной почты | "~" | " attribute-fields = * ("a =" атрибут CRLF) media-descriptions = * (медиа-поле информационное поле * (поле подключения) поля пропускной способности ключевое поле поля атрибутов) media-field = "m =" порт медиа-пространства ["/" целое число] пробел прото 1 * (пробел fmt) CRLF media = 1 * (буквенно-цифровой) ; обычно "аудио", "видео", "приложение" ; или "данные" fmt = 1 * (буквенно-цифровой) ; обычно тип полезной нагрузки RTP для аудио ; и видео СМИ proto = 1 * (буквенно-цифровой) ; обычно "RTP / AVP" или "udp" для IP4 порт = 1 * (ЦИФРА) ; должно быть в диапазоне от "1024" до "65535" включительно ; для медиа на основе UDP атрибут = (поле атрибута ":" значение атрибута) | att-поле att-field = 1 * (буквенно-цифровой) значение атрибута = строка байтов сесс-идентификатор = 1 * (ЦИФРА) ; должен быть уникальным для этого исходного имени пользователя / хоста сесс-версия = 1 * (ЦИФРА) ; 0 - новый сеанс адрес-соединения = многоадресный-адрес | адрес групповой-адрес = 3 * (десятичный-учар ".") десятичный-учар" / "ттл ["/" целое число] ; адреса многоадресной рассылки могут быть в диапазоне ; С 224.0.0.0 до 239.255.255.255 ttl = десятичный-uchar время начала = время | «0» время остановки = время | «0» время = ЦИФРА ПОЛОЖЕНИЯ 9 * (ЦИФРА) ; хватит еще на 2 века интервал повторения = набранное время типизированное время = 1 * (ЦИФРА) [фиксированная-лен-единица времени] фиксированная-лен-время-единица = "д" | "h" | "м" | "s" bwtype = 1 * (буквенно-цифровой) пропускная способность = 1 * (ЦИФРА) имя пользователя = безопасно ; довольно широкое определение, но без пробелов адрес электронной почты = адрес электронной почты | электронная почта "(" безопасна для электронной почты ")" | безопасный для электронной почты "<" email ">" email =; определено в RFC822 uri =; определено в RFC1630 phone-number = телефон | телефон "(" безопасный для электронной почты ")" | безопасный для электронной почты "<" phone ">" phone = "+" POS-DIGIT 1 * (пробел | "-" | DIGIT) ; между ними должен быть пробел или дефис. ; международный код и остальная часть номера.nettype = "IN" ; список будет расширен addrtype = "IP4" | «IP6» ; список будет расширен addr = FQDN | одноадресный адрес FQDN = 4 * (буквенно-цифровое | "-" | ".") ; полное доменное имя, как указано в RFC1035 unicast-address = IP4-адрес | IP6-адрес IP4-адрес = b1 "." десятичный-учар "." десятичный-учар "." b4 b1 = десятичный-учар ; меньше "224"; не «0» или «127» b4 = десятичный-учар ; не "0" IP6-адрес =; подлежит определению текст = байтовая строка ; по умолчанию это интерпретируется как IS0-10646 UTF8 ; ISO 8859-1 требует "a = charset: ISO-8859-1" ; атрибут уровня сеанса, который будет использоваться байтовая строка = 1 * (0x01..0x09 | 0x0b | 0x0c | 0x0e..0xff) ; любой байт кроме NUL, CR или LF десятичный-uchar = ЦИФРА | ПОС-ЦИФРА | ("1" 2 * (ЦИФРА)) | («2» («0» | «1» | «2» | «3» | «4») ЦИФРА) | («2» «5» («0» | «1» | «2» | «3» | «4» | «5»)) целое = ПОЗ-ЦИФРА * (ЦИФРА) буквенно-числовой = АЛЬФА | ЦИФРА ЦИФРА = "0" | ПОС-ЦИФРА POS-DIGIT = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" АЛЬФА = «a» | «b» | «c» | «d» | «e» | «f» | «g» | «h» | «i» | «j» | «k» | «l» | «m» | «n» | «o» | «p» | «q» | «r» | «s» | «t» | «u» | «v» | «w» | «x» | «y» | «z» | «A» | «B» | «C» | «D» | «E» | «F» | «G» | «H» | «I» | «J» | «K» | «L» | «M» | «N» | «O» | «P» | «Q» | «R» | «S» | «T» | «U» | «V» | «W» | «X» | «Y» | «Z» email-safe = safe | пространство | вкладка сейф = буквенно-цифровой | "'" | "'" | "-" | "."|" _ "|" `" | "{" | "|" | "}" | "+" | "~" | " пробел =% d32 tab =% d9 CRLF =% d13.10 Приложение B: Рекомендации по регистрации имен SDP в IANA Есть семь имен полей, которые могут быть зарегистрированы в IANA. С помощью терминология в спецификации SDP BNF, они «медиа», «proto», «fmt», «att-field», «bwtype», «nettype» и «addrtype». «медиа» (например, аудио, видео, приложение, данные). Типы пакетированных носителей, такие как те, что используются RTP, совместно используют пространство имен, используемое реестром типов носителей [RFC 2048] (т.е. "MIME типы "). Список допустимых имен медиа - это набор верхнего уровня Типы содержимого MIME. Набор средств массовой информации должен быть небольшим и не подлежит продлению, за исключением редких случаев. (MIME подтип соответствует параметру "fmt" ниже). "прото" В общем, это должен быть транспорт по стандартам IETF. идентификатор протокола, такой как RTP / AVP (rfc 1889 под rfc 1890 профиль). Однако люди захотят изобрести собственные запатентованные транспортные протоколы.Некоторые из них должны быть зарегистрированы как "fmt" с использованием "udp" в качестве протокола, и некоторые из них, вероятно, не может быть. Если протокол и приложение тесно связаны, например, с доской LBL wb, на которой использовались проприетарные и протокол специального назначения через UDP, имя протокола должно быть «udp», а имя формата, которое необходимо зарегистрировать, - «wb». В к такой регистрации применяются правила для форматов (см. ниже). Где проприетарный транспортный протокол действительно несет много разные форматы данных, есть возможность зарегистрировать новый протокол имя с IANA.В таком случае ДОЛЖЕН быть подготовлен RFC. описание протокола и ссылка на него при регистрации. Такие RFC МОЖЕТ быть информационным, хотя предпочтительнее, если он стандарты-трек. "fmt" Пространство имен формата зависит от контекста "proto" поле, поэтому формат не может быть зарегистрирован без указания одного или больше транспортных протоколов, к которым он применяется. Форматы охватывают все возможные кодировки, которые могут быть переносится в мультимедийном сеансе.Для форматов RTP, которым были назначены статические типы полезной нагрузки, используется номер типа полезной нагрузки. Для форматов RTP с использованием динамического номер типа полезной нагрузки, номер динамического типа полезной нагрузки задается как формат и дополнительный атрибут "rtpmap" определяют формат и параметры. Для форматов, отличных от RTP, любое имя незарегистрированного формата может быть зарегистрированы в процессе регистрации MIME-типа [RFC 2048]. Приведенный здесь тип является только подтипом MIME (MIME верхнего уровня тип содержимого указывается параметром media).Тип MIME регистрация ДОЛЖНА содержать ссылку на RFC для отслеживания стандартов, который описывает транспортный протокол для этого типа носителя. Если там является существующим типом MIME для этого формата, регистрация MIME должны быть дополнены ссылкой на транспортную спецификацию для этот тип носителя. Если для этого не существует существующего типа MIME формат, и не существует подходящего формата файла, это должно быть отмеченным в вопросах кодирования как "нет подходящего файла формат"."att-field" (названия атрибутов) Имена полей атрибутов МОГУТ быть зарегистрированы в IANA, хотя это не является обязательным, и неизвестные атрибуты просто игнорируются. Когда атрибут зарегистрирован, он должен сопровождаться краткая спецификация, указывающая следующее: o контактное имя, адрес электронной почты и номер телефона o имя-атрибута (как оно будет отображаться в SDP) o полное имя атрибута на английском языке o тип атрибута (уровень сеанса, уровень мультимедиа или оба) o подчиняется ли значение атрибута кодировке атрибут.o Объяснение назначения атрибута в один абзац. o спецификация соответствующих значений атрибутов для этого атрибут. IANA не будет проверять такие регистрации атрибутов, за исключением убедитесь, что они не конфликтуют с существующими регистрациями. Хотя приведенное выше является минимумом, который IANA примет, если ожидается, что атрибут будет широко использоваться и взаимодействовать является проблемой, авторам рекомендуется создать стандартную версию RFC, более точно определяющий атрибут.Лица, подающие заявки на регистрацию, должны убедиться, что спецификация в духе атрибутов SDP, в первую очередь то, что атрибут не зависит от платформы в том смысле, что он не неявные предположения об операционных системах и не называет определенные части программного обеспечения, которые могут препятствовать совместимость. "bwtype" (спецификаторы пропускной способности) Настоятельно не рекомендуется распространение спецификаторов полосы пропускания. Новые спецификаторы полосы пропускания могут быть зарегистрированы в IANA.В отправка ДОЛЖНА содержать ссылку на RFC для отслеживания стандартов, определяющий точная семантика спецификатора полосы пропускания и указание когда его следует использовать и почему существующая зарегистрированная пропускная способность спецификаторов не хватает. "nettype" (Тип сети) Новые типы сетей могут быть зарегистрированы в IANA, если требуется SDP. используется в контексте неинтернет-среды. Пока эти обычно не являются прерогативой IANA, могут быть обстоятельства когда интернет-приложению необходимо взаимодействовать с не- Интернет-приложение, например, при подключении к Интернету телефонный звонок в PSTN.Количество типов сети должно быть маленькими и редко расширять. Новый тип сети нельзя зарегистрироваться без регистрации хотя бы одного адреса тип, который будет использоваться с этим типом сети. Новый тип сети регистрация ДОЛЖНА содержать ссылку на RFC, в котором подробно описаны тип сети и тип адреса и указывает, как и когда они будет использоваться. Такой RFC МОЖЕТ быть информационным. "addrtype" (Тип адреса) Новые типы адресов могут быть зарегистрированы в IANA.Тип адреса имеет смысл только в контексте типа сети, и любой регистрация типа адреса ДОЛЖНА указывать зарегистрированную сеть type, или быть отправленным вместе с регистрацией сетевого типа. А регистрация нового типа адреса ДОЛЖНА ссылаться на RFC, дающий подробности синтаксиса типа адреса. Такой RFC МОЖЕТ быть Информационный. Типы адресов не должны регистрироваться часто. Процедура регистрации Чтобы зарегистрировать имя, необходимо следовать приведенным выше инструкциям относительно необходимый уровень документации, которая требуется.В саму регистрацию следует отправить в IANA. Регистрация атрибутов должен включать информацию, указанную выше. Другие регистрации должен включать следующую дополнительную информацию: o контактное имя, адрес электронной почты и номер телефона o регистрируемое имя (как оно появится в SDP) o полное имя на английском языке o тип имени («media», «proto», «fmt», «bwtype», «nettype» или "addrtype") o объяснение цели зарегистрированного имени в одном абзаце.o ссылку на спецификацию (например, номер RFC) зарегистрированного имя. IANA может передать любую регистрацию в IESG или в любой соответствующий Рабочая группа IETF для проверки и может потребовать внесения изменений до того, как будет произведена регистрация. Приложение C: Адреса авторов Марк Хэндли Институт информационных наук c / o MIT Лаборатория компьютерных наук 545 Площадь Технологий Кембридж, Массачусетс 02139 Соединенные Штаты электронная почта: [email protected] Ван Якобсон МС 46а-1121 Лаборатория Лоуренса Беркли Беркли, Калифорния 94720 Соединенные Штаты электронная почта: van @ ee.lbl.gov Благодарности Многие люди в рабочей группе IETF MMUSIC оставили комментарии и предложения по этому документу. В частности, мы бы хотел бы поблагодарить Еву Шулер, Стива Каснера, Билла Феннера, Эллисон Манкин, Росс Финлейсон, Питер Парнс, Йорг Отт, Карстен Борман, Роб Ланфье и Стив Ханна. Рекомендации [1] Миллс Д., "Спецификация сетевого протокола времени (версия 3) и реализация », RFC 1305, март 1992 г. [2] Шульцринн, Х., Каснер, С., Фредерик, Р.и В. Якобсон, "RTP: Транспортный протокол для приложений реального времени », RFC 1889, январь 1996 г. [3] Шульцринн, Х., "Профиль RTP для аудио- и видеоконференций. с минимальным контролем », RFC 1890, январь 1996 г. [4] Хэндли, М., «SAP - протокол объявления сеанса», Работа в Прогресс. [5] В. Якобсон, С. Макканн, «НДС - аудиоконференцсвязь на базе X11. инструмент », страница руководства по чанам, Лаборатория Лоуренса Беркли, 1994. [6] Консорциум Unicode, «Стандарт Unicode - версия 2.0 ", Аддисон-Уэсли, 1996. [7] ИСО / МЭК 10646-1: 1993. Международный стандарт - Информация технология - Универсальный набор символов с несколькими октетами (UCS) - Часть 1: Архитектура и базовая многоязычная плоскость. Пять поправок и техническое исправление опубликовано к настоящему времени. UTF-8 описан в Приложении R, опубликованном как Поправка 2. [8] Голдсмит Д. и М. Дэвис, «Использование Unicode с MIME», RFC 1641, Июль 1994 г. [9] Йерго, Ф., «UTF-8, формат преобразования Unicode и ISO. 10646 ", RFC 2044, октябрь 1996 г.[10] Рекомендация ITU-T H.332 (1998): «Мультимедийный терминал для Прием Интернет-конференций H.323 », ITU, Женева. [11] Хэндли, М., Школьник, Э. и Х. Шульцринн, "Сессия Протокол инициации (SIP) », Работа в процессе. [12] Шульцринн, Х., Рао, А., и Р. Ланфьер, "Потоковая передача в реальном времени Протокол (RTSP) », RFC 2326, апрель 1998 г. Полное заявление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Этот документ и его переводы могут быть скопированы и предоставлены другие и производные работы, которые комментируют или иным образом объясняют это или помочь в его реализации могут быть подготовлены, скопированы, опубликованы и распространяется, полностью или частично, без ограничения каких-либо вида, при условии, что указанное выше уведомление об авторских правах и этот абзац включены во все такие копии и производные работы.Однако это сам документ не может быть изменен каким-либо образом, например, путем удаления уведомление об авторских правах или ссылки на Internet Society или другие Интернет-организации, за исключением случаев, когда это необходимо для разработки Интернет-стандартов, в этом случае процедуры для авторские права, определенные в процессе разработки стандартов Интернета, должны быть следовали, или по мере необходимости перевести его на другие языки, кроме Английский.