Solucione problemas de transferência de chamada de áudio no momento da transferência do SRVCC em VoLTE
Opções de download
Linguagem imparcial
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.
Sobre esta tradução
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.
Contents
Introduction
Este documento descreve como solucionar o problema que ocorre quando uma chamada de áudio em VoLTE não é transferida sem interrupções no momento da transferência do SRVCC.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Conhecimento de hardware do 5000/5500
- StarOS
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment.
All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Abreviaturas
| VoLTE | Evolução de Voz a Longo Prazo |
| SRVCC | Continuidade de chamada de voz de rádio único |
| CCR | Solicitação de controle de crédito |
| CCA | Resposta de controle de crédito |
| AVP | Par de valor do atributo |
| PCRF | Função de regra de política e cobrança |
| PCEF | Função de aplicação de políticas e tarifas |
| SGW | Servindo Gateway |
| PGW | Gateway de Rede de Dados de Pacotes |
| MME | Entidade de gerenciamento de mobilidade |
Problema
O provedor de serviços relatou que, embora a transferência do SRVCC tenha sido bem-sucedida no MME, a chamada VoLTE não foi transferida sem interrupções para a rede 2G/3G antiga. Após a conclusão da transferência do SRVCC, o MME enviou a mensagem DELETE_BEARER_COMMAND para o SGW com sinalizador do portador de voz como verdadeiro e a versão do portador no PGW foi bem-sucedida.
No entanto, após a comunicação do PGW ao PCRF, observou-se que o PGW não notifica o PCRF como PS_to_CS_Handover, mesmo que o SRVCC tenha sido bem-sucedido na extremidade do MME.
Troubleshoot
Esta seção fornece informações para solucionar o problema de processamento de chamada de áudio quando ela é transferida do VoLTE para a rede 2G/3G herdada por meio de transferência SRVCC.
Coletados "subtraços mon" com a transferência do SRVCC. Esta é a sequência de mensagens trocadas entre MME, SGW, PGW e PCRF.
Mensagem DELETE_BEARER_COMMAND de MME para SGW como flag do portador de voz verdadeiro:
INBOUND>>>>> 12:17:24:406 Eventid:141004(3)
[SGW-S11/S4]GTPv2C Rx PDU, from 10.206.33.X:30464 to 10.206.31.Y:2123 (57)
TEID: 0x81E0418E, Message type: EGTP_DELETE_BEARER_COMMAND (0x42)
Sequence Number: 0xD2101D (13766685)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x0035 (53)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3766718840
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x7D5
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xE02F902
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
Além disso, o SGW envia a mensagem EGTP_DELETE_BEARER_COMMAND ao PGW:
INBOUND>>>>> 12:17:24:407 Eventid:141004(3)
[PGW-S5/S2a/S2b]GTPv2C Rx PDU, from 223.224.X.Y:36368 to 223.224.A.B:2123 (57)
TEID: 0x80F0E1DB, Message type: EGTP_DELETE_BEARER_COMMAND (0x42)
Sequence Number: 0xAD818E (11370894)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x0035 (53)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3766718840
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x7D5
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xE02F902
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
Além disso, DELETE_BEARER é aceito pelo PGW e inicia a exclusão do portador:
<<<
[PGW-S5/S2a/S2b]GTPv2C Tx PDU, from 223.224.A.B:2123 to 223.224.X.Y:36368 (17)
TEID: 0x80F3C18E, Message type: EGTP_DELETE_BEARER_REQUEST (0x63)
Sequence Number: 0xAD818E (11370894)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x000D (13)
INFORMATION ELEMENTS
EPS BEARER ID:
Type: 73 Length: 1 Inst: 1
Value: 7
Além disso, o PGW inicia a mensagem de atualização do CCR para o PCRF. Aqui, no relatório de regra de cobrança AVP, o PGW informa o PCRF sobre nome-regra-tarifação, status-da-PCC e código-falha-regra.
Aqui se descobriu que o PGW envia o código de falha de regra errado para o PCRF. Como o MME indicou a liberação do portador de voz (como o sinalizador era verdadeiro), o PGW deve informar ao PCRF como transferência PS_to_CS. Em vez disso, há um Resource_Allocation_failure que é relatado ao PCRF.
Como resultado, o PCRF estava considerando uma falha na rede 4G e informando o mesmo com o IMS. Portanto, o IMS estava iniciando o encerramento de chamada VoLTE. Embora o SRVCC tenha sido bem-sucedido, a chamada não foi transferida sem interrupções para a rede 2G/3G antiga.
In 3GPP TS 29.212 V13.5.0 (2016-03)
As mentioned in section 3.6, Request of IP-CAN Bearer Termination
If the IP-CAN bearer termination is caused by the PS to CS handover, the PCEF shall report related PCC rules for this IP-CAN bearer by including the Rule-Failure-Code AVP
set to the value PS_TO_CS_HANDOVER.
In 3GPP TS 29.212 V14.3.0 (2017-03)
As mentioned in section 4.5.6 Indication of IP-CAN Bearer Termination Implications
When the PCEF detects that a dedicated IP-CAN bearer could not be activated or has been terminated it shall remove the affected PCC rules and send a CCR command to the PCRF
with CC-Request-Type AVP set to the value "UPDATE_REQUEST", including the Charging-Rule-Report AVP specifying the affected PCC rules with the PCC-Rule-Status set to inactive
and including the Rule-Failure-Code AVP assigned to the value RESOURCE_ALLOCATION_FAILURE.
SRVCC PS-to-CS Handover Indication Support in starOS
This feature helps in notifying the PCRF about the exact reason for PCC rule deactivation on Voice bearer deletion.
This exact cause will help PCRF to then take further action appropriately.
This feature ensures complete compliance for SRVCC, including support for PS-to-CS handover indication when voicebearers are released.
If the IP-CAN bearer termination is caused by the PS to CS handover, the PCEF may report related PCC rules for thisIP-CAN bearer by including the Rule-Failure-Code AVP set to the value PS_TO_CS_HANDOVER.
Mensagem de atualização do CCR do PGW para o PCRF com relação ao relatório de regra de cobrança AVP:
<<<
Diameter message from 10.0.232.X:32933 to 10.5.40.Y:3869
Base Header Information:
Version: 0x01 (1)
Message Length: 0x000260 (608)
Command Flags: 0xc0 (192) REQ PXY
Command Code: 0x000110 (272) Credit-Control-Request
Application ID: 0x01000016 (16777238) 3GPP-Gx
Hop2Hop-ID: 0xb7cf10ce (3083800782)
End2End-ID: 0x3b6b4886 (996886662)
AVP Information:
[M] Session-Id
Code: 0x00000107 (263) Session-Id
Flags: 0x40 (64) [M]
Length: 0x00004f (79)
Data: 0003-diamproxy.asr55k.gx;1385806608;584234203;5cd9037d-1db02
[M] Auth-Application-Id
Code: 0x00000102 (258) Auth-Application-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 16777238
[M] Origin-Host
Code: 0x00000108 (264) Origin-Host
Flags: 0x40 (64) [M]
Length: 0x00002b (43)
Data: 0003-diamproxy.asr55k.gx
[M] Origin-Realm
Code: 0x00000128 (296) Origin-Realm
Flags: 0x40 (64) [M]
Length: 0x00001a (26)
Data: cisco.com
[M] Destination-Realm
Code: 0x0000011b (283) Destination-Realm
Flags: 0x40 (64) [M]
Length: 0x00002a (42)
Data: PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] CC-Request-Type
Code: 0x000001a0 (416) CC-Request-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: UPDATE_REQUEST (2)
[M] CC-Request-Number
Code: 0x0000019f (415) CC-Request-Number
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 2
[M] Destination-Host
Code: 0x00000125 (293) Destination-Host
Flags: 0x40 (64) [M]
Length: 0x000037 (55)
Data: PCRF01.PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] Origin-State-Id
Code: 0x00000116 (278) Origin-State-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 1552081338
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x000028 (40)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_E164 (0)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000014 (20)
Data: 121234567891
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_IMSI (1)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000017 (23)
Data: XYZAB1234567891
[M] Framed-IPv6-Prefix
Code: 0x00000061 (97) Framed-IPv6-Prefix
Flags: 0x40 (64) [M]
Length: 0x000012 (18)
Data: Reserved: 00 Prefixlen: 64 IPv6 prefix: 2401:4900:4097:f050::
[M] User-Equipment-Info
Code: 0x000001ca (458) User-Equipment-Info
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] User-Equipment-Info-Type
Code: 0x000001cb (459) User-Equipment-Info-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: IMEISV (0)
[M] User-Equipment-Info-Value
Code: 0x000001cc (460) User-Equipment-Info-Value
Flags: 0x40 (64) [M]
Length: 0x000018 (24)
Data: 9876543211234
[M] Called-Station-Id
Code: 0x0000001e (30) Called-Station-Id
Flags: 0x40 (64) [M]
Length: 0x00000b (11)
Data: ims
[V] [M] Charging-Rule-Report
Code: 0x000003fa (1018) Charging-Rule-Report
Flags: 0xc0 (192) [V] [M]
Length: 0x00006c (108)
Vendor-Id: 0x000028af (10415) 3GPP
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE00F72513
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE00F72512
[V] [M] PCC-Rule-Status
Code: 0x000003fb (1019) PCC-Rule-Status
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: INACTIVE (1)
[V] [M] Rule-Failure-Code
Code: 0x00000407 (1031) Rule-Failure-Code
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: RESOURCE_ALLOCATION_FAILURE (10) >> failure code is incorrect. It should be PS_CS_Handover
[V] [M] Access-Network-Charging-Address
Code: 0x000001f5 (501) Access-Network-Charging-Address
Flags: 0xc0 (192) [V] [M]
Length: 0x000012 (18)
Vendor-Id: 0x000028af (10415) 3GPP
Data: IPv4 223.224.X.Y
Solução
Na rede do cliente, foi usado o dicionário de diâmetro rel-8. Foi descoberto que PS_CS_Handover não tinha suporte em rel-8.
Então, você precisa atualizar o dicionário para 3gpp-r10. Depois de atualizar o dicionário para 3gpp-r10, a causa é enviada corretamente como PS_CS_Handover.
Depois disso, as chamadas de áudio dos usuários finais podem ser capazes de transferir com facilidade para a rede 2G/3G antiga a partir do VoLTE.
ims-auth-service DRA_Gx_SPG
policy-control
diameter dictionary r8-gx-standard
diameter update-dictionary-avps 3gpp-r10 << diameter dictionary updated to 3gpp-r10
Mensagem DELETE_BEARER_COMMAND de SGW para PGW como flag do portador de voz verdadeiro:
INBOUND>>>>> From sessmgr:205 tpc_interface.c:1338 (Callid 3cda3ef4) 13:28:21:659 Eventid:141004(3)
[PGW-S5/S2a/S2b]GTPv2C Rx PDU, from 223.224.M.N:39632 to 223.224.P.Q:2123 (57)
TEID: 0x845800CD, Message type: EGTP_DELETE_BEARER_COMMAND (0x42)
Sequence Number: 0xE9625A (15295066)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x0035 (53)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3769747091
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x844
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xDCF8C02
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
Além disso, é aceite pela PGW e inicia a libertação do portador.
<<<
[PGW-S5/S2a/S2b]GTPv2C Tx PDU, from 223.224.M.N:2123 to 223.224.P.Q:39632 (17)
TEID: 0x8064A25A, Message type: EGTP_DELETE_BEARER_REQUEST (0x63)
Sequence Number: 0xE9625A (15295066)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x000D (13)
INFORMATION ELEMENTS
EPS BEARER ID:
Type: 73 Length: 1 Inst: 1
Value: 7
CCR de PGW para PCRF com relação ao AVP de relatório de regra de cobrança com código de falha visto como PS_CS_Handover.
<<<
Diameter message from 10.206.17.X:51119 to 10.5.40.Y:3007
Base Header Information:
Version: 0x01 (1)
Message Length: 0x000260 (608)
Command Flags: 0xc0 (192) REQ PXY
Command Code: 0x000110 (272) Credit-Control-Request
Application ID: 0x01000016 (16777238) 3GPP-Gx
Hop2Hop-ID: 0xaebac4d3 (2931475667)
End2End-ID: 0x19b8ec95 (431549589)
AVP Information:
[M] Session-Id
Code: 0x00000107 (263) Session-Id
Flags: 0x40 (64) [M]
Length: 0x00004e (78)
Data: 0007-diamproxy.asr55k.dra.gx;1020935924;202167245;5d0747d1-cd02
[M] Auth-Application-Id
Code: 0x00000102 (258) Auth-Application-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 16777238
[M] Origin-Host
Code: 0x00000108 (264) Origin-Host
Flags: 0x40 (64) [M]
Length: 0x00002b (43)
Data: 0007-diamproxy.asr55k.dra.gx
[M] Origin-Realm
Code: 0x00000128 (296) Origin-Realm
Flags: 0x40 (64) [M]
Length: 0x00001a (26)
Data: cisco.com
[M] Destination-Realm
Code: 0x0000011b (283) Destination-Realm
Flags: 0x40 (64) [M]
Length: 0x00002a (42)
Data: PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] CC-Request-Type
Code: 0x000001a0 (416) CC-Request-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: UPDATE_REQUEST (2)
[M] CC-Request-Number
Code: 0x0000019f (415) CC-Request-Number
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 2
[M] Destination-Host
Code: 0x00000125 (293) Destination-Host
Flags: 0x40 (64) [M]
Length: 0x000037 (55)
Data: PCRF01.NO.DC.PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] Origin-State-Id
Code: 0x00000116 (278) Origin-State-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 1559087623
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x000028 (40)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_E164 (0)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000014 (20)
Data: 121234567891
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_IMSI (1)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000017 (23)
Data: XYZAB1234567891
[M] Framed-IPv6-Prefix
Code: 0x00000061 (97) Framed-IPv6-Prefix
Flags: 0x40 (64) [M]
Length: 0x000012 (18)
Data: Reserved: 00 Prefixlen: 64 IPv6 prefix: 2401:4900:4071:32ec::
[M] User-Equipment-Info
Code: 0x000001ca (458) User-Equipment-Info
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] User-Equipment-Info-Type
Code: 0x000001cb (459) User-Equipment-Info-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: IMEISV (0)
[M] User-Equipment-Info-Value
Code: 0x000001cc (460) User-Equipment-Info-Value
Flags: 0x40 (64) [M]
Length: 0x000018 (24)
Data: 9876543211234
[M] Called-Station-Id
Code: 0x0000001e (30) Called-Station-Id
Flags: 0x40 (64) [M]
Length: 0x00000b (11)
Data: ims
[V] [M] Charging-Rule-Report
Code: 0x000003fa (1018) Charging-Rule-Report
Flags: 0xc0 (192) [V] [M]
Length: 0x00006c (108)
Vendor-Id: 0x000028af (10415) 3GPP
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE03D4E98A
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE03D4E989
[V] [M] PCC-Rule-Status
Code: 0x000003fb (1019) PCC-Rule-Status
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: INACTIVE (1)
[V] [M] Rule-Failure-Code
Code: 0x00000407 (1031) Rule-Failure-Code
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: PS_TO_CS_HANDOVER (13) >> failure code seen as PS_to_CS_Handover
[V] [M] Access-Network-Charging-Address
Code: 0x000001f5 (501) Access-Network-Charging-Address
Flags: 0xc0 (192) [V] [M]
Length: 0x000012 (18)
Vendor-Id: 0x000028af (10415) 3GPP
Data: IPv4 223.224.X.Y
O dicionário de diâmetro apropriado precisa ser usado para transferência direta de uma chamada de áudio de VoLTE em 4G para uma rede 2G/3G legada através de transferência SRVCC. Isso foi suportado depois que o dicionário de diâmetro foi atualizado para 3gpp-rel10 em ims-auth-service.
Colaborado por engenheiros da Cisco
- Satya Narayan PandaCisco TAC Engineer
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)