On Thu, Mar 23, 2006 at 09:56:34PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
the RR set is built on the path of the request - any server on the path may add a RR to the request. The final UAS, when generating a 2xx reply has to mirror on the reply the entire set of RR hdrs. As the dump shows, the INVITE sent by openser to the GW has some RR hdrs, but the 200 OK generate by GW has none.
Thanks for the explanation.
I can try to test this out with another upstream provider. If this problem is related to the 200 reply by the remote-endpoint the first problem which i described (client creds forwarded to remote-end) must have another cause as it directly occurs after the first 407 from the remote-end.
if you post a dump, I will take a look.
It's in the same dump as the RR problem:
Until I get the 401 from the remote-endpoint everything works as expected (i.e. the INVITE is fwd'ed to the remote-end without credentials as I call consume_credentials() before relaying).
But then things start to look strange:
- OpenSER sends a 407 to the client although the INVITE already contained the credentials (as there was a 407 at the very beginning).
- After the client sends the INVITE with the credentials for a second time OpenSER relays them with the credentials from the client to the remote-endpoint. But the credentials should have been removed by consume_credentials() and the uac_auth() credentials should be used instead.
- After the remote-end replies with 401 OpenSER sends the INVITE again but this time with the right credentials which are configured for the UAC module.
So this problem doesn't prevent the call from working, but looks somehow strange nevertheless. E.g. Why does OpenSER relay the credentials of the client although consume_credentials() is called. Or why does OpenSER send a 407 although the previous INVITE was already authenticated.
bye, /gst