[Users] Re: missing record-route when using uac_auth()

[Günther Starnberger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.kamailio.org/pipermail/users/attachments/20060323/33f5f996/attachment.pgp