Genesys Cloud - Main

Hi Senih. 

This being displayed in the ANI field, it's typically related to how the upstream SIP trunk or carrier is populating the From header in the SIP INVITE.

In SIP signaling, ANI is usually derived from one of these headers:

• From

• P-Asserted-Identity (PAI)

• Remote-Party-ID (RPID)

If the carrier sends the ANI as a SIP URI instead of a numeric user part (E.164 format), Genesys Cloud will simply present what it receives, especially if normalization rules are not applied.

In this case, a few things are likely the carrier is sending a SIP URI instead of a standard phone number.

This is not typically a Genesys issue, but rather how the SIP INVITE is being constructed upstream.

In short, Genesys is usually displaying exactly what it receives in the SIP signaling. Cleaning or standardizing the ANI format normally needs to be done at the carrier or SBC level.

Hope this helps.

Hi Kaio, 

Thank you for the explanation. it makes sense with our setup with BYOC.  I will follow up with our carrier.

Best regards,

Hi Senih. 

This being displayed in the ANI field, it's typically related to how the upstream SIP trunk or carrier is populating the From header in the SIP INVITE.

In SIP signaling, ANI is usually derived from one of these headers:

• From

• P-Asserted-Identity (PAI)

• Remote-Party-ID (RPID)

If the carrier sends the ANI as a SIP URI instead of a numeric user part (E.164 format), Genesys Cloud will simply present what it receives, especially if normalization rules are not applied.

In this case, a few things are likely the carrier is sending a SIP URI instead of a standard phone number.

This is not typically a Genesys issue, but rather how the SIP INVITE is being constructed upstream.

In short, Genesys is usually displaying exactly what it receives in the SIP signaling. Cleaning or standardizing the ANI format normally needs to be done at the carrier or SBC level.

Hope this helps.