23 Mar
2006
23 Mar
'06
3:43 p.m.
On Thu, Mar 23, 2006 at 09:56:34PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
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
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.