Genesys Cloud - Main

Hello!

What is the "Outbound SIP Termination FQDN" set to on the trunk you are sending the call out?

Remember, this call is still going to flow through the dial plan, and still get assigned to a trunk, and then that trunk's settings are going to come into play.

-Jim

Hello Lee, 

To expand on Jim's response. 

What you're seeing is expected behavior with BYOC Cloud.

When Genesys Cloud sends an outbound SIP call through a BYOC Cloud trunk, it performs DNS resolution on the domain in the Request-URI and uses the resulting IP address for routing. Based on the available documentation, there isn't a configuration option to preserve the original FQDN in the Request-URI host.

From your description, it sounds like your downstream SIP platform is using the Request-URI host for domain-based routing or multi-tenant routing. Since the host is being replaced with an IP address, the downstream platform can't identify the intended destination, which explains the 404 Not Found response.

I am not sure if there is a supported way to disable this, but I do have some work arounds:

Use an SBC or SIP proxy. This is the most common approach. The SBC can rewrite the Request-URI back to the required FQDN before forwarding the call to your downstream platform.

Route using other SIP information. If your downstream platform supports it, consider routing based on custom SIP headers, URI parameters, or the user portion of the Request-URI instead of the host.

Leverage the user portion of the SIP URI. If you're building the URI dynamically in Architect, the user portion is preserved and may provide enough information for downstream routing.

One thing to note is that while custom SIP headers can be configured on a BYOC Cloud trunk, they're static values. Architect variables can't be inserted dynamically into those headers.

Based on the documentation, I don't see a native way to preserve the FQDN in the Request-URI host today. If this behavior is a hard requirement for your integration, I'd recommend opening a support case to confirm whether there are any newer capabilities or whether this functionality is being considered for a future enhancement.

Hope this helps!

So, I just set this up to go to my SBC here in my lab from on of our Genesys Cloud instances and this is my R-URI observed on the incoming side of my SBC:

INVITE sip:+17773010001@sbc3.tteclabs.com:5061;transport=tls SIP/2.0

FQDN intact! So, I have to ask, what is different about our setups? Feel free to send me a direct message.

Hello Lee, 

To expand on Jim's response. 

What you're seeing is expected behavior with BYOC Cloud.

When Genesys Cloud sends an outbound SIP call through a BYOC Cloud trunk, it performs DNS resolution on the domain in the Request-URI and uses the resulting IP address for routing. Based on the available documentation, there isn't a configuration option to preserve the original FQDN in the Request-URI host.

From your description, it sounds like your downstream SIP platform is using the Request-URI host for domain-based routing or multi-tenant routing. Since the host is being replaced with an IP address, the downstream platform can't identify the intended destination, which explains the 404 Not Found response.

I am not sure if there is a supported way to disable this, but I do have some work arounds:

Use an SBC or SIP proxy. This is the most common approach. The SBC can rewrite the Request-URI back to the required FQDN before forwarding the call to your downstream platform.

Route using other SIP information. If your downstream platform supports it, consider routing based on custom SIP headers, URI parameters, or the user portion of the Request-URI instead of the host.

Leverage the user portion of the SIP URI. If you're building the URI dynamically in Architect, the user portion is preserved and may provide enough information for downstream routing.

One thing to note is that while custom SIP headers can be configured on a BYOC Cloud trunk, they're static values. Architect variables can't be inserted dynamically into those headers.

Based on the documentation, I don't see a native way to preserve the FQDN in the Request-URI host today. If this behavior is a hard requirement for your integration, I'd recommend opening a support case to confirm whether there are any newer capabilities or whether this functionality is being considered for a future enhancement.

Hope this helps!

Jim

Check if this is the configuration you are looking for:

So, I just set this up to go to my SBC here in my lab from on of our Genesys Cloud instances and this is my R-URI observed on the incoming side of my SBC:

INVITE sip:+17773010001@sbc3.tteclabs.com:5061;transport=tls SIP/2.0

FQDN intact! So, I have to ask, what is different about our setups? Feel free to send me a direct message.

Hello Lee, 

To expand on Jim's response. 

What you're seeing is expected behavior with BYOC Cloud.

When Genesys Cloud sends an outbound SIP call through a BYOC Cloud trunk, it performs DNS resolution on the domain in the Request-URI and uses the resulting IP address for routing. Based on the available documentation, there isn't a configuration option to preserve the original FQDN in the Request-URI host.

From your description, it sounds like your downstream SIP platform is using the Request-URI host for domain-based routing or multi-tenant routing. Since the host is being replaced with an IP address, the downstream platform can't identify the intended destination, which explains the 404 Not Found response.

I am not sure if there is a supported way to disable this, but I do have some work arounds:

Use an SBC or SIP proxy. This is the most common approach. The SBC can rewrite the Request-URI back to the required FQDN before forwarding the call to your downstream platform.

Route using other SIP information. If your downstream platform supports it, consider routing based on custom SIP headers, URI parameters, or the user portion of the Request-URI instead of the host.

Leverage the user portion of the SIP URI. If you're building the URI dynamically in Architect, the user portion is preserved and may provide enough information for downstream routing.

One thing to note is that while custom SIP headers can be configured on a BYOC Cloud trunk, they're static values. Architect variables can't be inserted dynamically into those headers.

Based on the documentation, I don't see a native way to preserve the FQDN in the Request-URI host today. If this behavior is a hard requirement for your integration, I'd recommend opening a support case to confirm whether there are any newer capabilities or whether this functionality is being considered for a future enhancement.

Hope this helps!

Jim 

-

I ran a test adjusting the "Outbound SIP Termination FQDN," and the Request-URI updated according to my configuration.

-

Jim

Check if this is the configuration you are looking for:

So, I just set this up to go to my SBC here in my lab from on of our Genesys Cloud instances and this is my R-URI observed on the incoming side of my SBC:

INVITE sip:+17773010001@sbc3.tteclabs.com:5061;transport=tls SIP/2.0

FQDN intact! So, I have to ask, what is different about our setups? Feel free to send me a direct message.

Hello Lee, 

To expand on Jim's response. 

What you're seeing is expected behavior with BYOC Cloud.

When Genesys Cloud sends an outbound SIP call through a BYOC Cloud trunk, it performs DNS resolution on the domain in the Request-URI and uses the resulting IP address for routing. Based on the available documentation, there isn't a configuration option to preserve the original FQDN in the Request-URI host.

From your description, it sounds like your downstream SIP platform is using the Request-URI host for domain-based routing or multi-tenant routing. Since the host is being replaced with an IP address, the downstream platform can't identify the intended destination, which explains the 404 Not Found response.

I am not sure if there is a supported way to disable this, but I do have some work arounds:

Use an SBC or SIP proxy. This is the most common approach. The SBC can rewrite the Request-URI back to the required FQDN before forwarding the call to your downstream platform.

Route using other SIP information. If your downstream platform supports it, consider routing based on custom SIP headers, URI parameters, or the user portion of the Request-URI instead of the host.

Leverage the user portion of the SIP URI. If you're building the URI dynamically in Architect, the user portion is preserved and may provide enough information for downstream routing.

One thing to note is that while custom SIP headers can be configured on a BYOC Cloud trunk, they're static values. Architect variables can't be inserted dynamically into those headers.

Based on the documentation, I don't see a native way to preserve the FQDN in the Request-URI host today. If this behavior is a hard requirement for your integration, I'd recommend opening a support case to confirm whether there are any newer capabilities or whether this functionality is being considered for a future enhancement.

Hope this helps!

I'm not looking for any configuration. He was. 😀

You are seeing what I am. I have no issue getting the RURI to have the FQDN.

Jim 

-

I ran a test adjusting the "Outbound SIP Termination FQDN," and the Request-URI updated according to my configuration.

-

Jim

Check if this is the configuration you are looking for:

So, I just set this up to go to my SBC here in my lab from on of our Genesys Cloud instances and this is my R-URI observed on the incoming side of my SBC:

INVITE sip:+17773010001@sbc3.tteclabs.com:5061;transport=tls SIP/2.0

FQDN intact! So, I have to ask, what is different about our setups? Feel free to send me a direct message.

Hello Lee, 

To expand on Jim's response. 

What you're seeing is expected behavior with BYOC Cloud.

When Genesys Cloud sends an outbound SIP call through a BYOC Cloud trunk, it performs DNS resolution on the domain in the Request-URI and uses the resulting IP address for routing. Based on the available documentation, there isn't a configuration option to preserve the original FQDN in the Request-URI host.

From your description, it sounds like your downstream SIP platform is using the Request-URI host for domain-based routing or multi-tenant routing. Since the host is being replaced with an IP address, the downstream platform can't identify the intended destination, which explains the 404 Not Found response.

I am not sure if there is a supported way to disable this, but I do have some work arounds:

Use an SBC or SIP proxy. This is the most common approach. The SBC can rewrite the Request-URI back to the required FQDN before forwarding the call to your downstream platform.

Route using other SIP information. If your downstream platform supports it, consider routing based on custom SIP headers, URI parameters, or the user portion of the Request-URI instead of the host.

Leverage the user portion of the SIP URI. If you're building the URI dynamically in Architect, the user portion is preserved and may provide enough information for downstream routing.

One thing to note is that while custom SIP headers can be configured on a BYOC Cloud trunk, they're static values. Architect variables can't be inserted dynamically into those headers.

Based on the documentation, I don't see a native way to preserve the FQDN in the Request-URI host today. If this behavior is a hard requirement for your integration, I'd recommend opening a support case to confirm whether there are any newer capabilities or whether this functionality is being considered for a future enhancement.

Hope this helps!