- База знаний
- Пример файла конфигурации XML для Cisco 8851 phone
- Пример файла конфигурации XML для Cisco 7970 phone
- Пример файла конфигурации XML для Cisco 9971
- Отладка VoIP звонка с Wireshark
- Книги
- Использование поля Diversion в SIP пакете
- Астериск и Н.323
- ISDN release cause codes
- Пример файла конфигурации голосового шлюза Cisco
- Пример конфигурации интерфейса E1 PRI в голосовом шлюзе Cisco
- Аналоговое зло
- Интернациональные телефонные коды стран
- Практикум по интеграции Астериск в комплексе с OpenBSC/Osmocom
- Факс по IP
SIP метод SUBSCRIBE
Выдержка из RFC 2848:
Когда запрос SUBSCRIBE отправляется серверу PINT, это означает, что у пользователя есть желание получать информацию о статусах в пределах сервисного сеанса. Этот сообщение определяет, интересующую его сессию, включая оригинальный дескриптор в сам запрос, используя SDP поле global-session-id, которое является частью origin-field, для однозначного определения сеанса, состояние которого необходимо отслеживать.
Запрос SUBSCRIBE (как и все остальные SIP запросы, касающиеся, происходящего в данное время, сеанса) отправляются на тот же сервер, на который был отправлен "первичный" запрос INVITE, или на сервер, который указан в поле Contact, полученного в более поздних сообщениях (там может быть, например, указан PINT шлюз для данного сеанса).
В принципе, пользователь может отправить запрос SUBSCRIBE уже после того, как завершилось обслуживание, связанное с использованием телефонной сети. Это, например, позволяет проверить состояние отправленного факса и узнать, был ли он передан полностью и без ошибок. Однако, от PINT шлюза требуется понить состояние о вызове только в течении промежутка времени, до этого определенного в заголовке Expires, которое может располагаться внутри ответа на запрос INVITE, которое инициализировало этот сеанс, внутри ответа на сообщение SUBSCRIBE, внутри ответа на любое сообщение UNSUBSCRIBE или внутри сообщения UNSUBSCRIBE для данного сеанса мониторинга состояния.
RFC для метода SUBSCRIBE конкретно не определяет контролируемые процессы. Все процессы определяются, как "Event packages" и регистрируются в IANA. Текущий набор событий перечислен здесь:
- http://www.iana.org/assignments/sip-events
- Смотри раздел: SIP event packages