O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como funciona o recurso de resposta provisória confiável do Session Initiation Protocol (SIP) e como configurá-lo no Cisco Unified Border Element (CUBE) e no Cisco Unified Communications Manager (CUCM).
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
Note: Este exemplo de configuração não se limita às versões de software e plataformas de hardware listadas acima; essa configuração também funciona com o Cisco IOS versão 12.4(24)T5 no Cisco AS5400XM Universal Gateway.
Foi introduzida uma resposta provisória confiável SIP para melhor integrar com uma rede telefônica pública comutada (PSTN). O cenário mais comum é estabelecer o caminho de voz/áudio antes da conclusão da chamada; portanto, o chamador ouve o anúncio ou a música gerada pela PSTN.
Por exemplo, na topologia abaixo, o telefone IP chama uma ponte de conferência PSTN ou alguns números de ligação gratuita, e a chamada reproduz um prompt antes de atender a chamada. Se o CUCM iniciar a chamada com uma oferta de atraso (o CONVITE não contém o Session Description Protocol (SDP)), o chamador não ouvirá o prompt.
Em outros casos, o lado PSTN gera um tom de chamada de volta. Se a mídia não for cortada antes da chamada se conectar, o chamador talvez não ouça o tom de chamada de volta.
A resposta provisória confiável SIP pode ser usada para resolver o problema acima sem envolver recursos de mídia extras (como o Protocolo de Transferência de Mídia (MTP - Media Transfer Protocol)), já que essas respostas provisórias e mensagens PRACK fornecem oportunidades adicionais para trocas de oferta/resposta.
Por padrão, o CUBE suporta resposta confiável com esta configuração:
voice service voip
sip
rel1xx supported 100rel
Isso significa, como um UAC (User Agent Client, cliente de agente de usuário), se ele receber mensagens 180/183 com cabeçalho Require: 100rel, responderá com o PRACK; no entanto, como um User Agent Server (UAS), ele não enviará 180/183 com o cabeçalho Require: 100rel.
Para forçar o CUBE a enviar 18X com Exigir: 100rel (para que aguarde PRACK do UAC), eis o exemplo de configuração:
Nível global:
voice service voip
sip
rel1xx require 100rel
Nível do peer de discagem:
dial-peer voice 1000 voip
voice-class sip rel1xx require 100rel
Note: A configuração do peer de discagem tem precedência sobre a configuração global.
Por padrão, o CUCM não suporta resposta confiável. No entanto, você pode alterar o perfil de tronco SIP para configurá-lo:
Note: Se o tronco SIP especificado usar o perfil de tronco SIP padrão (perfil SIP padrão), é melhor copiar para um novo perfil e aplicar ao tronco SIP; caso contrário, o perfil de tronco SIP padrão afetará todos os troncos SIP.
Note: Mesmo que você faça a alteração acima, o CUCM pode suportar respostas confiáveis somente enviando PRACK como um UAC; no entanto, por enquanto, não pode enviar 180/183 com o Require: cabeçalho 100rel como UAS.
Se a resposta confiável for configurada no peer de discagem de entrada no CUBE, uma chamada típica será semelhante a esta:
// CUBE receives INVITE with delay offer from CUCM. INVITE sip:2002@10.66.75.246:5060 SIP/2.0
Date: Thu, 04 Apr 2013 05:30:27 GMT
Call-Info: <sip:10.66.75.171:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
Allow-Events: presence, kpml
P-Asserted-Identity: <sip:4832@10.66.75.171>
Supported: 100rel,timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 7200
Cisco-Guid: 3228672256-0000065536-0000000027-2873836042
Remote-Party-ID: <sip:4832@10.66.75.171>;party=calling;screen=yes;privacy=off
Content-Length: 0
User-Agent: Cisco-CUCM8.6
To: <sip:2002@10.66.75.246>
Contact: <sip:4832@10.66.75.171:5060;transport=tcp>
Expires: 180
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
CSeq: 101 INVITE
Session-Expires: 7200
Max-Forwards: 70
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
Content-Length: 0
// CUBE responds 183 with SDP which also contains Require: 100rel.
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 101 INVITE
Require: 100rel
RSeq: 3344
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2002@10.66.75.246:5060;transport=tcp>
Supported: sdp-anat
Supported: X-cisco-srtp-fallback
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 330
v=0
o=CiscoSystemsSIP-GW-UserAgent 4874 2535 IN IP4 10.66.75.246
s=SIP Call
c=IN IP4 10.66.75.246
t=0 0
m=audio 16442 RTP/AVP 8 0 18 101 19
c=IN IP4 10.66.75.246
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
// CUBE receives PRACK from CUCM with SDP
PRACK sip:2002@10.66.75.246:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246da4c33fa3e
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:30:27 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 102 PRACK RAck: 3344 101 INVITE
Allow-Events: presence, kpml
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 213
v=0
o=CiscoSystemsCCM-SIP 169850 1 IN IP4 10.66.75.171
s=SIP Call
c=IN IP4 10.66.75.89
t=0 0
m=audio 26662 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
// CUBE acknowledges the PRACK.
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246da4c33fa3e
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
CSeq: 102 PRACK
Content-Length: 0
// The call is not anwered until now; however, calling and called parties have exchanged SDP,
// and media path is established.
// Other messages omitted.
Para solucionar esse problema no CUBE, essas depurações devem ser habilitadas:
debug voip ccapi inout
debug ccsip message
Sintoma 1: O CUBE envia 180/183 sem a exigência: cabeçalho 100rel.
Verifique se rel1xx require 100rel está configurado no dial-peer ou voice service voip apropriado.
Sintoma 2: O CUBE continua a enviar 180/183 com a solicitação: Cabeçalho 100rel para CUCM.
Esse problema geralmente ocorre quando o CUCM não suporta resposta confiável. Para resolver esse problema, ative Rel1xx no CUCM.