Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Configuração do CUBE

Configuração do CUCM

Mensagens SIP típicas

Troubleshooting

Informações Relacionadas

Introduction

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).

Prerequisites

Requirements

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

- Cisco Unified Border Element (CUBE) Enterprise

- Cisco Unified Communications Manager Express (CUCME)

- Cisco Unified Communications Manager (CUCM)

- Protocolo de Iniciação da Sessão (SIP)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- Cisco IOS versão 15.1(4)M4 em Cisco Integrated Services Routers (ISR): Séries 2800, 3800, 2900, 3900

- Cisco IOS versão 15.1(3)S4 em roteadores de serviços de agregação Cisco ASR 1000 Series

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.

Informações de Apoio

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.

Configuração do CUBE

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.

Configuração do CUCM

Por padrão, o CUCM não suporta resposta confiável. No entanto, você pode alterar o perfil de tronco SIP para configurá-lo:

1. Na interface de administração do CUCM, vá para Device > Device Setting > SIP Profile.

2. Abra o perfil SIP usado por um determinado tronco SIP.

3. Escolha Send PRACK para todas as 1xx Mensagens na lista suspensa SIP Rel1XX Options.

4. Redefina o perfil de tronco SIP para o tronco SIP especificado.

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.

Mensagens SIP típicas

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.

Troubleshooting

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.

Informações Relacionadas

- Suporte Técnico e Documentação - Cisco Systems