My SIP trunk provider provides a number of SIP proxies (let us call them proxy_a and proxy_b) for outbound calling. The provider's DNS is configured with a single record which contains the IP addresses for proxy_a and proxy_b. There is no hot / warm standby configured between proxy_a and proxy_b - so each proxy is unaware of any SIP dialogs which are active on the other proxy. 

I have noticed that when using the DNS record for the outbound SIP proxy configuration (which contains both proxy_a and proxy_b address) and digest authentication that the initial INVITE is sent to one proxy (which then returns a '407 Proxy Authentication Required' along with the required values (realm, nonce etc) to generate the authentication response. However in some cases the second INVITE (containing the response) is then sent to the other proxy - which (being unaware of the active dialog) simply responds again with a 407 - at which point the outbound call attempt is aborted. The behaviour is not consistent and approximately 50% of call attempts succeed.

Is this the intended behaviour of the system ? If it is the intended behaviour, would it not be better if the response to a 407 challenge was always returned to the proxy to which the initial INVITE was sent ?

Regards,

Sean

#SIP/VolP

------------------------------
Sean Fitzpatrick
Prime Contact BV
------------------------------

This response '407 Proxy Authentication Required', I guess, then is sent from SIP Proxy your provider. Maybe the provider needs to apply the configuration of "session persistent" or change for the authentication will be used in the first INVITE only.

Att,

Hi Breno,

thanks for your answer. The situation is not quite as you describe it. The '407 Proxy Authentication Required' response is coming from our SIP trunk provider as an answer to the 1st INVITE sent by Genesys Cloud for an outbound call. The 407 response contains a random string intended for authentication of one single call. This is expected behaviour when using digest authentication. Genesys Cloud should then respond with another INVITE containing a hash of a number of parameters like username, password etc. and the random string sent in the 407 response. The 2nd  INVITE sent for the same call should (and does) contain the hashed value which proves to our SIP trunk provider that we are indeed a known customer. However what I am seeing is that sometimes Genesys Cloud is sending the 2nd INVITE to another SIP proxy from our service  provider. This appears to be happening because we configured the SIP trunk in Genesys Cloud to use a single DNS record in the 'SIP Server or Proxies' configuration for the trunk and that DNS record contains multiple IP addresses of several proxies. As mentioned earlier - the actual SIP proxies provider by our service provider do not replicatie call information between themselves. So when Genesys Cloud sends the 2nd INVITE to another proxy listed in the DNS record, that 2nd proxy sees this as a new call and simply responds another '407 Proxy Authentication Required'. When that happens Genesys Cloud simply aborts the call attempt. About 50% of the time the 2nd INVITE is sent to the same SIP proxy and the outbound call is established correctly.

So it seems that my SIP trunk provider is actually not at fault here. The issue is arising because Genesys Cloud sometimes selects another SIP proxy from those listed in the DNS record of my service provider.

As a workaround I can configure the individual SIP proxies of my service provider in the 'SIP Server or Proxies' configuration for my trunk in Genesys Cloud. In this way one of the proxies is always tried first and only if this proxy does not reply to the initial INVITE, will the second proxy be used. The screenshot below shows this configuration. 

However I still think that this might be an issue with Genesys Cloud.

/Sean