On Tue, Mar 21, 2006 at 07:59:31PM +0100, Günther Starnberger wrote: hmm.. there seems to be a more fundamental problem somewhere (most likely in my configuration). i've made a packet-dump available at: http://pastebin.com/614719 the ip's in the dump are: 62.163.103.30 - client 62.116.32.102 - openser 194.221.62.206 - remote end basically there is the following communication: client -> openser: INVITE openser -> client: 407 proxy auth required client -> openser: ACK client -> openser: INVITE with creds openser -> client: trying openser -> remote: INVITE without creds [1] remote -> openser: unauthorized openser -> remote: ACK openser -> client: 407 proxy auth required client -> openser: ACK client -> openser: INVITE with creds openser -> client: trying openser -> remote: INVITE with creds from client (!!!) remote -> openser: unauthorized openser -> remote: ACK openser -> remote: INVITE with right uac auth creds remote -> openser: session progress [... continuing with problem described in last mail] [1] that's ok as there is a consume_credentials which should remove the credentials send by the client there are some strange things in the dump. e.g. why does openser forward the credentials from the client to the remote endpoint although they should have been removed by consume_credentials? and of course the missing record-route problem which i described in my first mail. bye, /gst ------------------------------------------------------------------------ _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

basically thats what i already do in failure_route[5]. the incoming INVITEs from the client are handled in route[3]. before i do any relaying i have a call to consume_credentials() which should remove the credentials of the client. this works when the INVITE is relayed for the first time. but when uac_auth() comes into play it sends the first INVITE to the remote end with the credentials of the client (instead of the ones which are configured). at the end of the dump you see the "200 Ok" packets from the remote-end. there are no replies in the dump as no record-route is inserted for some reason - the client therefore sends the replies directly to the remote endpoint.

On Thu, Mar 23, 2006 at 08:18:04PM +0200, Bogdan-Andrei Iancu wrote: Hello, I am not sure what you mean. There aren't any Record-Route headers which are set by the Remote-Server. All the RR headers are set by OpenSER. Where exactly do you see the problem?

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.

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.

Both problems which I described occur in the same dump file: http://gst.sysfrog.org/openser/ngrep1.txt

there is something strange on the cfg - please confirm if there is any traffic on loopback interface (messages looping on the proxy).