Voz : T.38

Diretrizes da terceira do fax da Interoperabilidade do CUBO

18 Junho 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (10 Maio 2016) | Feedback

Introdução

Este documento descreve como o FAX over IP (FoIP) se opera em fluxos de chamadas do Cisco Unified Border Element (CUBO) com provedores de serviços IP.

Contribuído por John Casale e por David Whiteford, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Empresa do CUBO
  • Protocolo de controle de gateway de mídia (MGCP)
  • Session Initiation Protocol (SIP)
  • Conjunto de protocolos de H323
  • Sinalização T30

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware: O ® do Cisco IOS libera 12.4T, 15.0M, 15.0T, 15.1M, 15.1T, 15.2M, 15.2T, 15.3T nas séries 2800 do Roteadores dos Serviços integrados de Cisco (ISR), 3800, 2900, 3900, 3900e ou o Universal Gateway de Cisco AS5400XM

Nota: Este exemplo de configuração não é limitado às versões de software e às plataformas de hardware alistadas aqui.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

FoIP com CUBO opera-se em uma multidão de ambientes e é executado a fim leverage redes voip atuais para serviços seguros do fax. Há os protocolos múltiplos do fax que o CUBO apoia junto com uma multidão de mecanismos do switchover. Contudo, no contexto de provedores de serviços IP, você deve aderir para enviar os protocolos e os métodos do switchover que são apoiados por vendedores fora de Cisco.

Em fluxos de chamadas de FoIP, o CUBO está entre o gateway de terminação (TGW) e o gateway de origem (OGW). De uma perspectiva da sinalização, a configuração do CUBO permite, ou nega, o switchover de uma chamada de voz a uma chamada de fax. Devido ao fato de que os protocolos de FoIP são fim-a-fim negociado em um ambiente VoIP, é essencial que tudo do OGW ao TGW está configurado a fim usar o mesmo protocolo de FoIP.

É importante saber que fluxos de FoIP são apoiados e que configuração é necessária no CUBO, assim como os TGW e os OGW, a fim assegurar uma comunicação segura do fax.

Fluxos da chamada de fax do CUBO

Devido ao fato de que os provedores de serviços IP têm tipicamente um ambiente misto de Cisco e do equipamento que não é da Cisco, é essencial que você usa um método do padrão para indústria a fim comutar de uma chamada de voz a uma chamada de fax. Isto significa que a Sinalização Nomeado Evento (NSE) não pode ser usada, desde que os NSE são proprietários Cisco. Há umas exceções a esta regra, mas são extremamente raros.

Nota: A incapacidade usar um switchover com base nos protocolos significa que o Skinny Call Control Protocol (SCCP) está usado somente em fluxos da chamada de fax aos provedores de serviços IP com G711ulaw e é um “melhor esforço.”

Métodos do transporte de FoIP

Este documento discute dois métodos do transporte de FoIP, fax Passagem-através de e fax relay de T.38.

Fax Passagem-através de

O fax Passagem-através de é um método do transporte do fax onde os sinais T30 e os dados da página sejam transportados através da rede IP como a modulação de código de pulso (PCM) - os dados codificados, envolvidos em quadros do Real-Time Transport Protocol (RTP).

O fax Passagem-através do switchover é provocado pela detecção do preâmbulo V.21 no TGW. A resultante CONVIDA (para o SORVO) ou o modo do pedido (para H323) é enviado com o CUBO e o resto do trajeto da sinalização de chamada ao OGW.

O fax Passagem-através do switchover comuta sobre de todo o codec da Voz ao codec definido sob o fax Passagem-através da configuração (este processo é esboçado mais tarde neste documento).

Nota: Um gateway MGCP não pode ser configurado a fim iniciar a maior velocidade a G.711 para o fax Passagem-através de. Consequentemente, todo o fax que se usar passagem-através no CUBO que termina a um gateway MGCP deve ser distribuído com codec de G.711.

Nota: O fax Passagem-através do não deve ser configurado com H.323 se o codec inicial é G.711. Isto faz com que um modo do pedido H.245 esteja enviado para comutar a G.711 quando G.711 é negociado já. CUCM responde com uma rejeção do modo do pedido H.245.

Fax Relay T.38

O fax relay é um método do transporte do fax onde os TGW e os OGW detectem os sinais T30 e os dados da página. Os gateways tomam aqueles sinais e convertem-nos nas mensagens de relé, que são representações digitais dos sinais analógicos. Aquelas mensagens de relé são enviadas então através da rede IP.

O switchover do fax relay de T.38 é provocado igualmente pela detecção do preâmbulo V.21 no TGW.

  • Quando o TGW se opera com SORVO, a detecção do preâmbulo V.21 provoca T.38 ReINVITE (similar ao que foi descrito previamente).
  • Quando o TGW se opera com H323, a detecção do preâmbulo V.21 provoca um modo do pedido de T.38.
  • Quando o TGW se opera com MGCP, a detecção do preâmbulo V.21 provoca uma notificação (NTFY), que seja enviada ao agente do atendimento. O agente do atendimento responde então com uma APROVAÇÃO 200, e envia um modo do pedido ou um ReINVITE PARA CUBAR, que dependa do protocolo de VoIP usado.

Debugar exemplos estão na seção da pesquisa de defeitos deste documento.

CUBE a configuração

O CUBO pode ser configurado para FoIP em dois lugares: globalmente sob o voip do serviço de voz assim como sob o dial-peer. A configuração no dial-peer combinado para um atendimento dado toma sempre a precedência sobre a configuração global. A configuração para T.38 e o fax Passagem-através do podem ser configurados ao mesmo tempo se sob o dial peers diferente, de modo que ambos os protocolos sejam apoiados simultaneamente.

CUBO Passagem-através da configuração

A fim configurar o fax Passagem-através do voip inferior do serviço de voz, use este comando (em corajoso):

voice service voip
no ip address trusted authenticate
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol pass-through g711ulaw

A fim configurar o fax Passagem-através no dial-peer, use este comando (em corajoso):

dial-peer voice 1 voip
description T38 Test
destination-pattern ^1000$
session protocol sipv2
session target ipv4:192.168.0.1
dtmf-relay rtp-nte
fax protocol pass-through g711ulaw
no vad

Nota: O fax Passagem-através de não é o mesmo que a transmissão do fax. Envie os motores do Cisco Network Services das forças de alavanca da transmissão (NSE) a fim comutar sobre de uma chamada de voz a uma chamada de fax.

CUBE a configuração de T.38

Nota: A versão 3 de T.38 (o fax G3 super se apressa) é apoiada nas versões do Cisco IOS 15.1(1)T e mais tarde.

A fim configurar a versão 0 de T.38 (velocidade do fax G3) sob o voip do serviço de voz, use este comando (em corajoso):

voice service voip
no ip address trusted authenticate
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

A fim configurar T.38 no dial-peer, use este comando (em corajoso):

dial-peer voice 1 voip
description T38 Test
destination-pattern ^1000$
session protocol sipv2
session target ipv4:192.168.0.1
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad

A fim configurar a versão 3 de T.38, sob o serviço de voz VoIP ou no dial-peer, usa este comando:

fax protocol t38 version 3 ls-redundancy 0 hs-redundancy 0 fallback none

Se um protocolo transfer dos media (MTP) é usado ao colaborar através de um CUBO, deve apoiar a transmissão do codec. O gerente das comunicações unificadas de Cisco (CUCM) MTP apoia a transmissão do codec para a versão 8.6.1 e mais recente. O Cisco IOS MTP deve ter o codec passagem-através na configuração da exploração agrícola do processador do sinal digital (DSP):

dspfarm profile 2 mtp  
 codec pass-through
 codec g729r8
 maximum sessions software 50
 associate application SCCP

Configuração de gateway do Time-Division Multiplexing (TDM) para colaborar com CUBO

Para um gateway controlado SCCP TDM, esta configuração é usada para o fax Passagem-através de.

voice service voip
no modem passthrough
fax protocol none
no fax-relay sg3-to-g3

Nota: O codec nas regiões que ajustam-se para esta que colabora deve ser G.711. Como notável previamente, um gateway SCCP não pode ser ajustado para usar T.38 ao colaborar com CUBO.

A fim configurar o fax Passagem-através para do SORVO e os gateways de H.323 TDM que colaboram com CUBO, entre:

voice service voip
no modem passthrough
no fax-relay sg3-to-g3
fax protocol pass-through g711ulaw

A fim configurar T.38 para o SORVO e os gateways de H.323 TDM que colaboram com CUBO, entre:

voice service voip
no modem passthrough
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

Nota: A versão 3 de T.38 pode ser usada se é configurada no CUBO e apoiada pelo provedor de serviços do SORVO.

A fim configurar um gateway MGCP TDM para o fax Passagem-através de inteworking com CUBO, entre:

no mgcp fax-relay sg3-to-g3
no mgcp package fxr-package
mgcp fax t38 inhibit
no mgcp modem passthrough voip mode nse

Nota: Desde que um gateway MGCP não apoia upspeeding para o fax Passagem-através de, as regiões em CUCM entre o gateway MGCP e o CUBO devem ter um codec de G.711.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshooting

A fim pesquisar defeitos esta edição no CUBO, estes debugam devem ser permitidos.

SORVO

Permita estes debuga para o SORVO:

debug voip ccapi inout
debug ccsip mess

Depois que a chamada de voz se estabelece, o TGW envia um SORVO ReINVITE ao OGW através do CUBO. Se o switchover é bem sucedido, o OGW responde com uma APROVAÇÃO do SORVO 200 com os parâmetros corretos do protocolo session description (SDP).

Switchover de T.38

INVITE sip:2101@10.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK171D71
Remote-Party-ID: <sip:1101@10.0.0.2>;party=calling;screen=no;privacy=off
From: <sip:8141101@10.0.0.2>;tag=8D815D8-646
To: <sip:2101@10.0.0.1>;tag=DD4D344-21B2
Date: Fri, 25 Feb 2011 19:25:15 GMT
Call-ID: 32395B08-403E11E0-818C9D5B-499FBE40@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 786980147-1077809632-2173148507-1235205696
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1298661915
Contact: <sip:8141101@10.0.0.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 384

v=0
o=CiscoSystemsSIP-GW-UserAgent 3745 9509 IN IP4 10.0.0.2
s=SIP Call
c=IN IP4 10.0.0.2
t=0 0
m=image 17682 udptl t38
c=IN IP4 10.0.0.2
a=T38FaxVersion:0
a=T38MaxBitRate:7200
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:180
a=T38FaxUdpEC:t38UDPRedundancy


!!NOTE!! Not all of the above bolded fields are required.
The above is an example of how Cisco implements T38.


SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK171D71
From: <sip:8141101@10.0.0.2>;tag=8D815D8-646
To: <sip:2101@10.0.0.1>;tag=DD4D344-21B2
Date: Fri, 25 Feb 2011 17:48:05 GMT
Call-ID: 32395B08-403E11E0-818C9D5B-499FBE40@10.0.0.1
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

176443: Feb 25 17:48:05.360:
//134/2EE85D338187/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK171D71
From: <sip:8141101@10.0.0.2>;tag=8D815D8-646
To: <sip:2101@10.0.0.1>;tag=DD4D344-21B2
Date: Fri, 25 Feb 2011 17:48:05 GMT
Call-ID: 32395B08-403E11E0-818C9D5B-499FBE40@10.0.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:2101@10.0.0.1>
;party=called;screen=no;privacy=off
Contact: <sip:2101@10.0.0.1:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Length: 384

v=0
o=CiscoSystemsSIP-GW-UserAgent 5552 9399 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=image 16710 udptl t38
c=IN IP4 10.0.0.1
a=T38FaxVersion:0
a=T38MaxBitRate:7200
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy


ACK sip:2101@10.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK181B79
From: <sip:8141101@10.0.0.2>;tag=8D815D8-646
To: <sip:2101@10.0.0.1>;tag=DD4D344-21B2
Date: Fri, 25 Feb 2011 19:25:15 GMT
Call-ID: 32395B08-403E11E0-818C9D5B-499FBE40@10.0.0.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

Fax Passagem-através do Switchover

INVITE sip:2101@10.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK154F2
Remote-Party-ID: <sip:1101@10.0.0.2>;party=calling;screen=no;privacy=off
From: <sip:8131101@10.0.0.2>;tag=8D66B94-7BF
To: <sip:2101@10.0.0.1>;tag=DD32900-5D4
Date: Fri, 25 Feb 2011 19:23:25 GMT
Call-ID: F12F0BBB-403D11E0-81869D5B-499FBE40@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3990792353-1077744096-2172755291-1235205696
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1298661805
Contact: <sip:8131101@10.0.0.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 174

v=0
o=CiscoSystemsSIP-GW-UserAgent 107 1892 IN IP4 10.0.0.2
s=SIP Call
c=IN IP4 10.0.0.2
t=0 0
m=audio 16464 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -


SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK154F2
From: <sip:8131101@10.0.0.2>;tag=8D66B94-7BF
To: <sip:2101@10.0.0.1>;tag=DD32900-5D4
Date: Fri, 25 Feb 2011 17:46:16 GMT
Call-ID: F12F0BBB-403D11E0-81869D5B-499FBE40@10.0.0.1
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK154F2
From: <sip:8131101@10.0.0.2>;tag=8D66B94-7BF
To: <sip:2101@10.0.0.1>;tag=DD32900-5D4
Date: Fri, 25 Feb 2011 17:46:16 GMT
Call-ID: F12F0BBB-403D11E0-81869D5B-499FBE40@10.0.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:2101@10.0.0.1>;party=called;screen=no;privacy=off
Contact: <sip:2101@10.0.0.1:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Length: 194

v=0
o=CiscoSystemsSIP-GW-UserAgent 4896 2709 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=audio 19054 RTP/AVP 0
c=IN IP4 10.0.0.1
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -


ACK sip:2101@10.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK16A56
From: <sip:8131101@10.0.0.2>;tag=8D66B94-7BF
To: <sip:2101@10.0.0.1>;tag=DD32900-5D4
Date: Fri, 25 Feb 2011 19:23:25 GMT
Call-ID: F12F0BBB-403D11E0-81869D5B-499FBE40@10.0.0.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

H323

Permita estes debuga para H323:

debug voip ccapi inout
debug cch323 all
debug h225 asn1
debug h245 asn1

Depois que a chamada de voz se estabelece, o TGW envia um H245 RequestMode ao OGW através do CUBO. Se o switchover é bem sucedido, o OGW responde com um RequestModeAck.

Switchover de T.38

value MultimediaSystemControlMessage ::= request : requestMode :
{
sequenceNumber 1
requestedModes
{

{

{
type dataMode :
{
application t38fax :
{
t38FaxProtocol udp : NULL
t38FaxProfile
{
fillBitRemoval FALSE
transcodingJBIG FALSE
transcodingMMR FALSE
version 0
t38FaxRateManagement transferredTCF : NULL
t38FaxUdpOptions
{
t38FaxMaxBuffer 200
t38FaxMaxDatagram 72
t38FaxUdpEC t38UDPRedundancy : NULL
}
}
}
bitRate 144
}
}
}
}
}

001378: May 31 20:56:19.745: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= response :
requestModeAck :
{
sequenceNumber 1
response willTransmitMostPreferredMode : NULL
}

Fax Passagem-através do Switchover

value MultimediaSystemControlMessage ::= request : requestMode :
{
sequenceNumber 1
requestedModes
{

{

{
type audioMode : g711Ulaw64k : NULL
}
}
}
}

value MultimediaSystemControlMessage ::= response :
requestModeAck :
{
sequenceNumber 1
response willTransmitMostPreferredMode : NULL
}

Sintoma 1: O CUBO rejeita ReINVITE com 488

Se você encontra este problema, termine estas etapas:

  1. Permita debuga e recolhem para uma chamada de teste.
  2. Verifique que T.38 ou o fax Passagem-através de estão configurados globalmente.
  3. Se T.38 ou o fax Passagem-através de não são configurados globalmente, assegure-se de que T.38 ou o fax Passagem-através de estejam configurados sob o entrante e os dial peer de saída baseados na interface de programação de aplicativo do Controle de chamadas (CCAPI) debuguem.
  4. Se o problema não é resolvido ainda, permita debugam o ccsip todo (em um logging buffer com registo de 5000000 protegidos debugar) a fim determinar porque o SORVO rejeita este ReINVITE.

Sintoma 2: O CUBO rejeita RequestMode com RequestModeReject

Se você encontra este problema, termine estas etapas:

  1. Permita debuga e recolhem para uma chamada de teste.
  2. Verifique que T.38 ou o fax Passagem-através de estão configurados globalmente.
  3. Se T.38 ou o fax Passagem-através de não são configurados globalmente, assegure-se de que T.38 ou o fax Passagem-através de estejam configurados sob o entrante e os dial peer de saída baseados no CCAPI debuguem.
  4. Se o problema não é resolvido ainda, permita debugam os eventos h225, debugam h225 q931, e debugam os eventos h245 a fim determinar porque H323 rejeita este RequestMode.

Informação do específico do vendedor

Verizon

  • O centro de assistência técnica da Cisco (TAC) observou que, embora o apoio das reivindicações de Verizon para T.38 sobre o SORVO, eles nunca iniciasse um switchover de uma chamada de voz a T.38 quando se operam no TGW.
  • Esta é uma limitação conhecida em seu ambiente, e não parece que estão indo o fixar.
  • Quando o OGW é um server de FoIP, você pode geralmente ajustar o server para iniciar um switchover mesmo quando é o OGW.
  • Quando Cisco GW é o OGW, não há atualmente nenhuma maneira de forçar o switchover quando Cisco GW atua como o OGW.
  • A identificação de bug Cisco CSCud72998 é a requisição de aprimoramento apoiar o switchover de T.38 quando Cisco GW é o OGW.

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 116280