8(499)-709-97-83
Работаем с 8:00 до 19:00

Транспортный адрес в сообщениях SIP и SDP

  • 15 сентября 2014

Протокол SIP основан на следующих протоколах:

  • Session Initiation Protocol (SIP) (RFC3261) и (RFC3581), для контроля вызовов
  • Session Description Protocol (SDP) (RFC4566 и RFC4961) для создания аудиопотока
  • Real Time Protocol (RTP) используется для передачи аудиопотока

SIP клиент будет указывать свой IP адрес и порт в трех различных местах:

  • В заголовке Via, для приемки ответов от других устройств
  • В поле Contact, SIP сообщения REGISTER, для ожидания входящих SIP сообщений INVITE
  • В поле SDP, для установки аудиопотока

Публичный IP адрес

Регистрация телефона

1) Когда SIP клиент отправляет запрос REGISTER серверу регистрации, в этом запросе содержится заголовок Via, в котором SIP клиент указывает свой IP адрес и порт. Заголовок Via служит для прохождения ответа, от сервера регистрации, по тому же маршруту, по которому шел запрос REGISTER к серверу. Поле Contact указывает серверу регистрации/прокси-серверу, как добраться до SIP клиента, т.е. служит для работы входящих вызовов. Пример:

          Via: SIP/2.0/UDP 176.193.129.229:5060
          Contact: User Name sip:username@176.193.129.229:5060

2) Сервер регистрации/прокси-сервер просматривает заголовок Via и сравнивает его с IP адресом источника, от которого пришло это сообщение, и далее добавляет свой собственный заголовок Via поверх уже имеющихся заголовков. Таким образом, сервер регистрации/прокси-сервер запоминает путь исходного сообщения. Из поля From сервер регистрации/прокси-сервер узнает, как связаться с SIP клиентом напрямую. Это необходимо для входящих вызовов (запрос INVITE). Пример:

          Via: SIP/2.0/UDP proxy.voipnotes.ru:5060;received=proxy.voipnotes.ru
          Via: SIP/2.0/UDP 176.193.129.229:5060;received=176.193.129.229
          Contact: User Name sip:username@176.193.129.229:5060

3) Когда сервер регистрации/прокси-сервер начинает отвечать SIP клиенту, он опять просматривает заголовки Via. Сообщение будет отправлено с IP адреса/порта, которые были указаны в самом верхнем заголовке Via. Затем он удаляет свой заголовок Via и отправляет сообщение на IP адрес/порт следующего заголовка Via. Когда SIP клиент, наконец-то, получает ответ от сервера регистрации/прокси-сервера он будет видеть только свой собственный заголовок Via. Пример:

     Via: SIP/2.0/UDP 176.193.129.229:5060;received=176.193.129.229

Действия в момент совершения вызова

1) Когда SIP клиент отправляет запрос INVITE к серверу регистрации, заголовок Via будет использоваться так же как в запросе REGISTER. В теле сообщения будет включен протокол SDP, с описанием IP адреса/порта, необходимых для создания медиа сессии:

          Via: SIP/2.0/UDP 176.193.129.229:5060
          Contact: User Name
          Message Body (SDP)

          Connection Information (c): IN IP4 176.193.129.229
          Media Description, name and address (m): audio 16422 RTP/AVP 18 8 0 2 4 96 97 98 100 101

2) Первоначально сервер отправит в сторону SIP клиента ответ 180 (Trying), и SIP клиент услышит сигал КПВ (Контроль посылки вызова). Далее сервер отправит в сторону SIP клиента ответ 200 (OK), теле сообщения будет включен протокол SDP, с описанием IP адреса/порта, необходимых для создания медиа сессии. SIP клиент получит:

          Via: SIP/2.0/UDP 176.193.129.229:5060;received=176.193.129.229
          Contact: 208.68.167.230:5060>
          Message Body (SDP)

          Connection Information (c): IN IP4 208.68.167.230
          Media Description, name and address (m): audio 17904 RTP/AVP 0 101

3) SIP клиент отправит ACK в сторону сервера и устанавливает RTP аудиопоток от 176.193.129.229:16422 в сторону 208.68.167.230:17904.

Действия в момент принятия вызова

Когда сервер регистрации/прокси-сервер получает входящий вызов из «внешнего мира», он генерирует запрос INVITE в сторону SIP клиента. Куда передать вызов сервер регистрации/прокси-сервер определяет из поля Contact, запроса REGISTER. Далее вызов протекает аналогично исходящему вызову, описанному выше.

Network Address Translation (NAT)

Регистрация телефона

1) Клиент заполняет поле заголовка Via, как обычно этот параметр содержит IP-адрес и номер порта SIP клиента. SIP клиент также добавляет параметр “rport”, изначально этот параметр пустой, т.е. таким образом SIP клиент просит следующее оборудование (next hop) указать порт, с которого пришел изначальный запрос. Пример:

          Via: SIP/2.0/UDP 10.0.1.15:5060;rport
          Contact: User Name sip:username@10.0.1.15:5060

2) Устройство NAT пересылает пакеты с внутреннего порта на внешний публичный IP адрес.

3) Сервер регистрации/прокси-сервер просматривает поля “received” и “rport” в заголовке Via для того, чтобы установить источник сообщения. Далее сервер регистрации/прокси-сервер устанавливает свой собственный заголовок Via, поверх полученных. Пример:

          Via: SIP/2.0/UDP sip.sipnet.com:5060
          Via: SIP/2.0/UDP proxy.voipnotes.ru:5060;rport=5060;received=proxy.voipnotes.ru
          Via: SIP/2.0/UDP 10.0.1.15:5060;rport=1024;received=176.193.129.229
          Contact: User Name sip:username@10.0.1.15:5060

4) Когда сервер регистрации/прокси-сервер отвечает на запрос, он начинает просматривать набор заголовков Via. Сообщение будет отправлено с IP адреса/порта самого верхнего заголовка Via. Затем сервер регистрации/прокси-сервер удаляет этот верхний заголовок Via и посылает сообщение на IP адрес/порт, перечисленные в следующем заголовке Via. Когда клиент, наконец, получает ответ, в заголовке Via, помимо изначальной информации, содержатся поля received/rport, в которых содержатся публичный IP адрес и порт на внешнем интерфейсе NAT устройства. Пример:

          Via: SIP/2.0/UDP 10.0.1.15:5060;rport=1024;received=176.193.129.229

5) SIP клиент теперь знает свой публичный IP адрес и порт и теперь может указать эти данные в поле Contact при повторной регистрации. Теперь сервер регистрации/прокси-сервер знает куда ему маршрутизировать входящие вызовы. Необходимо, чтобы NAT поддерживал соединение, поддерживал «проброшенные» IP адреса и порты.

          Via: SIP/2.0/UDP 176.193.129.229:1024;rport
          Contact: User Name sip:username@176.193.129.229:1024

6) В нашем примере sip.sipnet.com настроен на поддержку соединения с IP адресом и портом 176.193.129.229:1024.

Действия в момент совершения вызова

1) Когда SIP клиент отправляет запрос INVITE к серверу регистрации, заголовок Via будет использоваться так же как в запросе REGISTER. В теле сообщения будет включен протокол SDP, с описанием IP адреса/порта, необходимых для создания медиа сессии:

          Via: SIP/2.0/UDP 176.193.129.229:5060
          Contact: User Name
          Message Body (SDP)

          Connection Information (c): IN IP4 176.193.129.229
          Media Description, name and address (m): audio 16422 RTP/AVP 18 8 0 2 4 96 97 98 100 101

2) Первоначально сервер отправит в сторону SIP клиента ответ 180 (Trying), и SIP клиент услышит сигал КПВ (Контроль посылки вызова). Далее сервер отправит в сторону SIP клиента ответ 200 (OK), теле сообщения будет включен протокол SDP, с описанием IP адреса/порта, необходимых для создания медиа сессии. SIP клиент получит

          Via: SIP/2.0/UDP 176.193.129.229:5060;received=176.193.129.229
          Contact: 208.68.167.230:5060>
          Message Body (SDP)

          Connection Information (c): IN IP4 208.68.167.230
          Media Description, name and address (m): audio 17904 RTP/AVP 0 101

3) SIP клиент отправит ACK в сторону сервера и устанавливает RTP аудиопоток от 176.193.129.229:16422 в сторону 208.68.167.230:17904. Предполагается, что сервер использует симметричный RTP, т.е. обратный звуковой канал будет преодолевать NAT и достигнет SIP клиента.

Как видно, в SDP указан внутренний номер порта, который не достижим извне. Как вариант, использовать на роутере статическую переадресацию диапазона портов в NAT. Более элегантное решение, игнорировать порт RTP в сообщении SDP и ждать, пока не придут медиапакеты с внешнего порта NAT’а, и далее отправлять медиапакета на этот порт. Другим решением является использование Application Level Gateways (ALG), но они редко работают правильно.

Действия в момент принятия вызова

Когда сервер регистрации/прокси-сервер получает входящий вызов из «внешнего мира», он генерирует запрос INVITE в сторону SIP клиента. Куда передать вызов сервер регистрации/прокси-сервер определяет из поля Contact, запроса REGISTER. Далее вызов протекает аналогично исходящему вызову, описанному выше. Заметьте, что аудиопоток, от сервера регистрации/прокси-сервера к SIP клиенту, пройдет только после того как SIP клиент преодолеет NAT и установит соединение с сервером регистрации/прокси-сервером

Исходящий прокси-сервер (Outbound proxy)

Будем использовать MilkFish (OpenSER) в качестве исходящего прокси-сервера. Вместо того, чтобы проходить через NAT, телефоны теперь будут проходить через прокси-службы на маршрутизаторе. В этом случае, опция rport не требуется.

Регистрация телефона

1) Клиент заполняет поле заголовка Via, как обычно этот параметр содержит IP-адрес и номер порта SIP клиента. SIP клиент также добавляет параметр “rport”, изначально этот параметр пустой, т.е. таким образом SIP клиент просит следующее оборудование (next hop) указать порт, с которого пришел изначальный запрос. Пример:

          Via: SIP/2.0/UDP 10.0.1.15:5060;rport
          Contact: User Name sip:username@10.0.1.15:5060

2) Исходящий прокси-сервер добавляет свой собственный заголовок “Via” и редактирует поле “Contact:”. Далее прокси-сервер передает пакеты на публичный IP адрес маршрутизатора.

          Via: SIP/2.0/UDP 176.193.129.229
          Via: SIP/2.0/UDP 10.0.1.15:5060;rport=5060
          Contact: User Name sip:username@176.193.129.229:5060

3) Сервер регистрации/прокси-сервер добавляет свое поле Via, поверх уже имеющихся полей Via.

          Via: SIP/2.0/UDP proxy.voipnotes.ru:5060
          Via: SIP/2.0/UDP 176.193.129.229
          Via: SIP/2.0/UDP 10.0.1.15:5060;rport=5060
          Contact: User Name sip:username@176.193.129.229:5060

4) Когда сервер регистрации/прокси-сервер отвечает на запрос, он начинает просматривать набор заголовков Via. Сообщение будет отправлено с IP адреса/порта самого верхнего заголовка Via. Затем сервер регистрации/прокси-сервер удаляет этот верхний заголовок Via и посылает сообщение на IP адрес/порт, перечисленные в следующем заголовке Via. Наш исходящий прокси-сервер тоже удаляет свой заголовок. В итоге SIP клиент получает только одно поле Via, в котором указан его публичный IP адрес и порт, которые подставил исходящий прокси-сервер. Пример:

          Via: SIP/2.0/UDP 10.0.1.15:5060;rport=5060
          Contact: User Name sip:username@176.193.129.229:5060

Действия в момент совершения вызова

Когда SIP клиент отправляет запрос INVITE к серверу регистрации, заголовок Via будет использоваться так же как в запросе REGISTER. В теле сообщения будет включен протокол SDP, с описанием IP адреса/порта, необходимых для создания медиа сессии:

          Via: SIP/2.0/UDP 176.193.129.229:5060
          Contact: User Name
          Message Body (SDP):Connection Information (c): IN IP4 176.193.129.229
          Media Description, name and address (m): audio 16422 RTP/AVP 18 8 0 2 4 96 97 98 100 101

Далее вызов будет происходить по схемам рассмотренным выше, в данной статье.


Если вы в статье нашли ошибки или несоответствия, мы будем благодарны, если вы напишите нам о них в комментариях.

 
Powered by SEO CMS ver.: 23.1 TOP 2 (opencartadmin.com)