Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: letrung on October 09, 2017, 03:24:42 AM

Title: Call Fails when MCP has multi NICs
Post by: letrung on October 09, 2017, 03:24:42 AM
Hello all,

I have a interesting stutiation:
- When MCP server has a NIC eth0 : call's  result  to IVR service is OK  with RTP.
- But when i add a new NIC for storage network ( eth1 without default GW, eth0 has higher priority and has a default GW to route to client ).  I tried to call to IVR service : signalling between componets is OK, but have no voice ( RTP ). I checked and figure out that :

Cleint ...invite......> SIP  ..........> RM ..............> MCP (eth0 received message)
Cleint <......... SIP  <.......... RM <......200 OK ....... MCP (eth0 sent 200 ok)
client  ..... RTP ......> MCP

But, in the 200 OK  message body  from MCP has " Owner/ Creactor" attribute has value is eth1 . So that, client sent RTP mesage to eth1 of MCP ( message not able to destination because eth1 has no gateway).

anyone met this stituation ? with a solution to MCP indicate that client must sent RTP to eth0 instead of eth1. (please suggest solution without adding static route from client to MCP )


Thanks guys,
Le
Title: Re: Call Fails when MCP has multi NICs
Post by: cavagnaro on October 09, 2017, 03:59:41 AM
You need to configure the transport settings for that NIC. By default is any NIC, but you can define an static ip address.
You have to configure Sip server, RM and MCP
Follow documentation

Enviado de meu E6633 usando Tapatalk

Title: Re: Call Fails when MCP has multi NICs
Post by: letrung on October 09, 2017, 04:07:19 AM
Hi,

Could you provide more detailed info to define an static ip address for MCP ?
Title: Re: Call Fails when MCP has multi NICs
Post by: cavagnaro on October 09, 2017, 12:31:20 PM
Check transport settings for the application. That is it.

Enviado de meu E6633 usando Tapatalk

Title: Re: Call Fails when MCP has multi NICs
Post by: letrung on October 10, 2017, 06:07:49 AM
Thank cavagnaro,

This issue is resolved by setting rtp.localaddr to expected ip address.