i am trying to use uac_auth() on CVS-HEAD but somewhere there is a problem with missing record-route headers.
the SIP sessions looks like this:
client: INVITE openser: SIP/2.0 100 trying openser: SIP/2.0 183 Session progress openser: SIP/2.0 200 Ok (no record-route!) client: ACK (directly - not to openser because of missing rr)
so everything is fine until the remote end sends the Ok to OpenSER (which is further relayed to the client). OpenSER doesn't insert a Record-Route header and my client therefore sends the ACK directly to the remote-end instead of sending it to OpenSER. as the remote-end expects the ACKs from OpenSER it ignores them and after sending some further OKs it quits the sessions.
when i try the same thing using another destination (which doesn't go through the uac_auth() stuff) it works fine (= rr header is inserted), so i'm not sure if this is a bug in my config or OpenSER.
i have put my config online at: http://pastebin.com/614703
the case where it works fine is when dialing a sip-uri. in this case route[3] is called as INVITE handler which calls route[1] to relay the message. the problem occurs when dialing a numeric uri. in this case route[3] calls route[5] which is basically the same as route[1] with the exception of using a uac_auth failure route and a t_relay to a specific destination.
any hints about the cause of this problem?
bye, /gst
On Tue, Mar 21, 2006 at 07:59:31PM +0100, Günther Starnberger wrote:
i am trying to use uac_auth() on CVS-HEAD but somewhere there is a problem with missing record-route headers.
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
Hi Günther,
unfortunately the script is not availabel anymore on the site. you can send it as attachment if not too big.
in the flow below, the problem is that the 407 from the remote party must not be fwded to the client but processed by openser : got via failure route and applied uac_auth().
regards, bogadn
Günther Starnberger wrote:
On Tue, Mar 21, 2006 at 07:59:31PM +0100, Günther Starnberger wrote:
i am trying to use uac_auth() on CVS-HEAD but somewhere there is a problem with missing record-route headers.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Thu, Mar 23, 2006 at 06:46:16PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
unfortunately the script is not availabel anymore on the site. you can send it as attachment if not too big.
I've uploaded the config and the ngrep-dump to: http://gst.sysfrog.org/openser/
ip's in the dump: client: 62.163.103.30 openser: 62.116.32.102 remote server: 194.221.62.206
in the flow below, the problem is that the 407 from the remote party must not be fwded to the client but processed by openser : got via failure route and applied uac_auth().
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.
bye, /gst
Günther Starnberger wrote:
in the flow below, the problem is that the 407 from the remote party must not be fwded to the client but processed by openser : got via failure route and applied uac_auth().
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.
yes, that's problem - for some hidden reasons, that "User-Agent: (Very nice Sip Registrar Server)" does not mirror the RR set in the 200 reply, which is violation of the RFC. The bug is in that UA and you should report it to them.
regards, bogdan
On Thu, Mar 23, 2006 at 08:18:04PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
yes, that's problem - for some hidden reasons, that "User-Agent: (Very nice Sip Registrar Server)" does not mirror the RR set in the 200 reply, which is violation of the RFC. The bug is in that UA and you should report it to them.
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.
bye, /gst
Günther Starnberger wrote:
On Thu, Mar 23, 2006 at 08:18:04PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
yes, that's problem - for some hidden reasons, that "User-Agent: (Very nice Sip Registrar Server)" does not mirror the RR set in the 200 reply, which is violation of the RFC. The bug is in that UA and you should report it to them.
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?
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.
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.
regards, bogdan
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
Hi,
it's very difficult to formulate an opinion without a network trace. Please post it somewhere in order to take a look.
regards, bogadn
Günther Starnberger wrote:
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.
On Fri, Mar 24, 2006 at 12:39:51PM +0200, Bogdan-Andrei Iancu wrote:
Hi,
it's very difficult to formulate an opinion without a network trace. Please post it somewhere in order to take a look.
Both problems which I described occur in the same dump file: http://gst.sysfrog.org/openser/ngrep1.txt
bye, /gst
Günther Starnberger wrote:
Both problems which I described occur in the same dump file: http://gst.sysfrog.org/openser/ngrep1.txt
A simple hint use -W byline with ngrep for packets formatting. bye
:tele
there is something strange on the cfg - please confirm if there is any traffic on loopback interface (messages looping on the proxy).
as the reply shows:
U 62.116.32.102:5060 -> 62.163.103.30:5060 SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP 192.168.0.144:5060;received=62.163.103.30;rport=5060;branch =z9hG4bK1888503047..From: sip:gst@sysfrog.org;tag=1481684668..To: sip:00434635361588@eris.sysfrog.org;tag=329cfeaa6 ded039da25ff8cbb8668bd2.4990..Call-ID: 827989729@192.168.0.144..CSeq: 21 INVITE..Proxy-Authenticate: Digest realm="sysf rog.org", nonce="4422d70719ab3dcb1ff421f74a7a9cbefc3dd47a"..Server: OpenSer (1.1.0-dev16 -tls (i386/linux))..Content-Le ngth: 0..Warning: 392 62.116.32.102:5060 "Noisy feedback tells: pid=16521 req_src_ip=62.116.32.102 req_src_port=5060 i n_uri=sip:00434635361588@eris.sysfrog.org out_uri=sip:00434635361588@eris.sysfrog.org via_cnt==2"....
it was indeed created by openser, but as via_cnt=2 and req_src_ip=62.116.32.102 shows, the request cycled on lo.
my guess in that the original request was parallely forked to the PSTN GW and back to the proxy. GW send 401 and proxy 407.
please check this out.
regards, bogdan
Günther Starnberger wrote:
On Fri, Mar 24, 2006 at 12:39:51PM +0200, Bogdan-Andrei Iancu wrote:
Hi,
it's very difficult to formulate an opinion without a network trace. Please post it somewhere in order to take a look.
Both problems which I described occur in the same dump file: http://gst.sysfrog.org/openser/ngrep1.txt
bye, /gst
On Fri, Mar 24, 2006 at 02:41:38PM +0200, Bogdan-Andrei Iancu wrote:
Hello,
there is something strange on the cfg - please confirm if there is any traffic on loopback interface (messages looping on the proxy).
There's indeed traffic on the loopback interface. I have saved the dump to http://gst.sysfrog.org/openser/lo.txt - the corresponding dump of the eth0 interface (on the same call) is in eth0.txt.
bye, /gst
-
Bogdan-Andrei Iancu -
Günther Starnberger -
tele