Голосовая связь и система унифицированных коммуникаций : Cisco Unified Border Element

Ошибки факса устранения неполадок из-за множественных M-линий на CUBE

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как решить вопрос о Cisco Unified Border Element (CUBE), когда исходящие ошибки факса происходят из-за множественных m-линий от поставщика. CUBE не понимает множественные m-линии, но обходной путь может быть внедрен на CUBE для решения вопроса с использованием профилей Протокола SIP.

Внесенный Kaustubh Inamdar и Mudit Mathur, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Сведения в документе приведены на основе данных версий аппаратного и программного обеспечения:

  • Сервер факсов
  • Cisco Unified Communications Manager (CUCM)
  • CUBE

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Топология сети

Пример, который описан в этом документе, использует эту топологию сети:

Проблема

Когда поставщик передает Пригласить сообщение к CUBE во время переключателя голоса к факсу, и он включает Протокол описания сеанса (SDP), который содержит две m-линии, стандартное поведение CUBE должно было отклонить требование с SIP 488, Не Приемлемым, Здесь обмениваются сообщениями.

После идентификатора ошибки Cisco CSCtw96549 изменилось это поведение. Теперь, если поставщик передает SDP с двумя m-линиями, вызов проходит через как ожидалось.

Вот пример принятого m-формата-линии:

m=audio
m=image

Однако, если поставщик передает SDP с инвертированным m-форматом-линии, CUBE не обрабатывает его правильно и передает неправильно сформированный SDP к факсу - серверу в Пригласить сообщении. Поэтому весь сбой вызовов.

Вот пример непринятого m-формата-линии:

m=image
m=audio

Совет: Для получения дальнейшей информации обратитесь к идентификатору ошибки Cisco CSCue70469.

Решение

Для решения этой проблемы сделайте исходящий тестовый вызов факса и соберите, SIP отлаживает (debug ccsip messages). От выходных данных отладки могут быть сделаны эти наблюдения:

  • Голосовой вызов устанавливает без проблем.

  • Когда пора передать вызов отправить факсом, переключатель инициируется стороной поставщика после обнаружения преамбулы V.21.

    Примечание: Это является не всегда обязательным для стороны, которую вызывают для инициирования переключателя. Несколько факсов - серверов имеют возможность инициировать переключатель, даже при том, что они - терминал, из которого происходит вызов. Это сделано через инкапсуляцию звонящего (CNG) тон в пакетах Индикатора T.30.

  • Повторно приглашение для переключателя имеет две линии сред (m =) так, что, линия m=image размещена выше линии m=audio, когда дефект , который описан в идентификаторе ошибки Cisco CSCue70469, возникает, и CUBE разъединяет вызов.

В настоящее время нет никакого разрешения для этой проблемы на CUBE, но можно изменить внешние факторы для обхождения проблемы:

  • Используйте только одну m-линию для переключателя голоса к факсу.

  • Используйте основанный на протоколе passthrough.

  • Сделайте, чтобы поставщик разместил линию m=audio выше линии m=image.

  • Используйте факс - сервер для инициирования переключателя с использованием CNG в пакете Индикатора T.30.

Версия 10.0 CUBE усиливает новую характеристику для входящих профилей SIP, где профили SIP применены на входящее сообщение SIP, прежде чем она будет представлена стеку SIP и обработана. Идея позади использования входящих профилей SIP в этом сценарии состоит в том, чтобы удалить линию m=audio все вместе так, чтобы CUBE мог работать с только одиночной линией m=image.

Когда поставщик требует передать голосовой вызов к факсу, вот пример повторно пригласить сообщения:

Received:
INVITE sip:025027141@192.0.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnm30rd10dofho0fo9011sb0000g00.1
Call-ID: 6B6CB982-B41D11E3-898F851F-F1ADD198@192.0.2.2
From: <sip:026455288@25027100.xyz>;tag=7qapqh6u-CC-36
To: "Administrator" <sip:025027141@25027100.xyz>;tag=85A6C018-2489
CSeq: 1 INVITE
Contact: <sip:192.0.2.1:5060;transport=udp>
Max-Forwards: 69
Content-Length: 431
Content-Type: application/sdp
v=0
o=HuaweiSoftX3000 22157305 22157306 IN IP4 192.0.2.1
s=Sip Call
c=IN IP4 192.0.2.1
t=0 0
m=image 53200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 53190 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
================================

Эта конфигурация профиля SIP может быть применена для удаления линии m=audio:

voice class sip-profiles 966
request REINVITE sdp-header Audio-Media modify "(.*)" "a=sendrecv"
voice service voip
sip
voice-class sip profiles 966 inbound
or 
dial-peer voice XYZ voip
voice-class sip profiles 966 inbound

Этот профиль SIP изменяет линию m=audio на a=sendrecv, который действует как линия в SDP, который не релевантен. Это позволяет CUBE передавать повторно пригласить сообщение к стороне факса - сервера и ждать 200 ОК ответ.

Необходимо также обратиться к еще одному важному аспекту: То, когда 200 ОК обмениваются сообщениями, передается поставщику в ответ на полученный , повторно приглашают, это должно представить обе из m-линий, чтобы соответствовать RFC и гарантировать, что ответное сообщение имеет то же количество атрибутов сред как сообщение предложения.

Можно выполнить это через стандартный исходящий профиль SIP, который применен на точку вызова, которая указывает поставщику:

voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
"t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"

Это гарантирует , что повторно приглашение со множественными m-линиями правильно обрабатывается и что ответ поставщику является RFC-совместимым, потому что "t38UDPReddundancy" заменен:

"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP

Таким образом, используйте использование обходные пути, которые описаны в этом документе (большинство которых зависимо от поставщика), чтобы к проблеме решения множественных m-линий. Кроме того, было замечено, что Сервер Xmedius может также инициировать переключатель, поскольку это вынуждает сервер передать T.38, повторно приглашают сообщение, и избегает представления множественных m-линий.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 118939