Hello,
preparations for 1.5.0 release starts. Any developer that has to commit any code, please do it quickly. Branch will be created very soon.
Many thanks for those helping with development and testing.
Cheers, Daniel
Hi, we have a problem with OpenSER not relaying ACKs.
The problem arises because we have a connection to a PBX that sends SIP uri's like this;
Contact: sip:192.168.1.1
So for instance when we get a SIP/2.0 200 OK (...) Contact: sip:192.168.1.1
OpenSER relays this to the client (SIP phone) which tries to respond
ACK sip:192.168.1.1 SIP/2.0 (...)
This causes my $ru to be sip:domain.net whereas normally it would be sip:user@domain.net.
And for somereason t_relay simply fails... I've done tcpdump on the server, and what it does is try to look for NAPTR/SRV to DNS name (domain.net) which resolves to itself.
Not sure why it would do that, as the PBX sends a different IP address than that of the OpenSER server.
Any ideas?
Anyone experienced anything similar?
(Running on Ubuntu with OpenSER 1.3.0-tls)
Thanks in advance, //gojensen
Hello,
do you do record route in config file? Do you have Route headers in ACK?
Why the PBX is setting the contact to be the IP address of the sip server? Should be the IP address of PBX. Check the config of pbx, maybe is someting wrong there.
Cheers, Daniel
On 03/02/2009 02:46 PM, Geir O. Jensen wrote:
Hi, we have a problem with OpenSER not relaying ACKs.
The problem arises because we have a connection to a PBX that sends SIP uri's like this;
Contact: sip:192.168.1.1
So for instance when we get a SIP/2.0 200 OK (...) Contact: sip:192.168.1.1
OpenSER relays this to the client (SIP phone) which tries to respond
ACK sip:192.168.1.1 SIP/2.0 (...)
This causes my $ru to be sip:domain.net whereas normally it would be sip:user@domain.net.
And for somereason t_relay simply fails... I've done tcpdump on the server, and what it does is try to look for NAPTR/SRV to DNS name (domain.net) which resolves to itself.
Not sure why it would do that, as the PBX sends a different IP address than that of the OpenSER server.
Any ideas?
Anyone experienced anything similar?
(Running on Ubuntu with OpenSER 1.3.0-tls)
Thanks in advance, //gojensen
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Yes, we do record routes and it's properly going into the loose route section of the config.
The PBX is NOT setting the ip address of the SIP server. It's using it's own, but when OpenSER tries to process the ACK it seems that when it doesn't find a "proper" Contact field it looks at the original To: field maybe... Anyways it tries to look up it's domain name and then just stops prosessing.
I may need to get deeper debug settings here - but it's a production system so I can't really experiment much. (We've solve the problem by routing via an ISDN gateway at the moment, which is rather unfortunate :D)
- Geir
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: 2. mars 2009 14:46 To: Geir O. Jensen Cc: 'kamailio' Subject: Re: [Kamailio-Users] Problem with sip uri in contact field
Hello,
do you do record route in config file? Do you have Route headers in ACK?
Why the PBX is setting the contact to be the IP address of the sip server? Should be the IP address of PBX. Check the config of pbx, maybe is someting wrong there.
Cheers, Daniel
On 03/02/2009 02:46 PM, Geir O. Jensen wrote:
Hi, we have a problem with OpenSER not relaying ACKs.
The problem arises because we have a connection to a PBX that sends SIP uri's like this;
Contact: sip:192.168.1.1
So for instance when we get a SIP/2.0 200 OK (...) Contact: sip:192.168.1.1
OpenSER relays this to the client (SIP phone) which tries to respond
ACK sip:192.168.1.1 SIP/2.0 (...)
This causes my $ru to be sip:domain.net whereas normally it
would be
sip:user@domain.net.
And for somereason t_relay simply fails... I've done tcpdump on the server, and what it does is try to look for NAPTR/SRV to DNS name (domain.net) which resolves to itself.
Not sure why it would do that, as the PBX sends a different
IP address
than that of the OpenSER server.
Any ideas?
Anyone experienced anything similar?
(Running on Ubuntu with OpenSER 1.3.0-tls)
Thanks in advance, //gojensen
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
2009/3/2 Geir O. Jensen geir.o.jensen@uninett.no:
I may need to get deeper debug settings here - but it's a production system so I can't really experiment much. (We've solve the problem by routing via an ISDN gateway at the moment, which is rather unfortunate :D)
Can I have a ngrep capture?
Here is a "ngrep-sip br" attached 192.168.10.1 is the OpenSER 1.3.0 server 192.168.10.10 is the SNOM SIP phone 192.168.20.1 is the external PBX (Alcatel 4400 R9.0)
As far as I can see, OpenSER get's the ACK from the phone, fails to follow the contact field and tries to send the ACK to itself.
U 2009/03/03 11:03:58.968311 192.168.10.10:5060 -> 192.168.10.1:5060 ACK sip:192.168.20.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK-jug6wcf05crp;rport Route: sip:192.168.10.1;lr=on;ftag=wy94fiso65 From: "Firstname Lastname" sip:sipuser@sip.domain.net;tag=wy94fiso65 To: sip:96600@sip.domain.net;tag=ae6c517693a92a078da863bf36b1fe53 Call-ID: 3c700f129d86-5m6fq5hc7l7g CSeq: 1 ACK Max-Forwards: 70 Contact: sip:sipuser@192.168.10.10:5060;flow-id=1 Content-Length: 0
U 2009/03/03 11:03:58.972547 192.168.10.1:5060 -> 192.168.10.1:5060 ACK sip:domain.net SIP/2.0 Record-Route: sip:192.168.10.1;lr=on;ftag=wy94fiso65 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bKf305.4e063f76.2 Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK-jug6wcf05crp;rport=5060 From: "Firstname Lastname" sip:sipuser@sip.domain.net;tag=wy94fiso65 To: sip:96600@sip.domain.net;tag=ae6c517693a92a078da863bf36b1fe53 Call-ID: 3c700f129d86-5m6fq5hc7l7g CSeq: 1 ACK Max-Forwards: 69 Contact: sip:sipuser@192.168.10.10:5060;flow-id=1 Content-Length: 0 P-hint: rr-enforced
- Geir
-----Original Message----- From: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] On Behalf Of Iñaki Baz Castillo Sent: 2. mars 2009 16:10 Cc: kamailio Subject: Re: [Kamailio-Users] Problem with sip uri in contact field
2009/3/2 Geir O. Jensen geir.o.jensen@uninett.no:
I may need to get deeper debug settings here - but it's a
production
system so I can't really experiment much. (We've solve the
problem by
routing via an ISDN gateway at the moment, which is rather
unfortunate
:D)
Can I have a ngrep capture?
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
As far as I can see, OpenSER get's the ACK from the phone, fails to follow the contact field and tries to send the ACK to itself.
U 2009/03/03 11:03:58.968311 192.168.10.10:5060 -> 192.168.10.1:5060 ACK sip:192.168.20.1 SIP/2.0
U 2009/03/03 11:03:58.972547 192.168.10.1:5060 -> 192.168.10.1:5060 ACK sip:domain.net SIP/2.0
This is an ACK for a INVITE 200, so it's a new transaction (a in-dialog request) rather than part of the INVITE transaction (as an ACK for a [3456]XX response would be).
The RURI is modified by Kamailio, this means that your script is doing it. What do you do with your in-dialog requests? what do you do with ACK (INVITE-200)? Are you using "$ru=" or "sethostport"/"writehostport" for them?
Hm. We do rather a lot of things with the SIP uri, both reformatting the content and changing hosts depending on the number.
However, I thought this was OK since anything that was changed would be "record routed" and handled via the loose route portion.
I see now that that only works if the contact field is a full SIP uri (as our regular Gateway does) because it's never been a problem.
The ACK that is sent from the SNOM gets caught by the looseroute script. Should it?
I'm a bit confused now, can't really see how I'm going to fix this... Our script is rather large and ugly :/
I was just under the impression that loose route meant the packets "knew" where they were going...
- Geir
-----Original Message----- From: Iñaki Baz Castillo [mailto:ibc@aliax.net] Sent: 3. mars 2009 11:41 To: Geir O. Jensen Cc: kamailio Subject: Re: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
As far as I can see, OpenSER get's the ACK from the phone, fails to follow the contact field and tries to send the ACK to itself.
U 2009/03/03 11:03:58.968311 192.168.10.10:5060 ->
192.168.10.1:5060
ACK sip:192.168.20.1 SIP/2.0
U 2009/03/03 11:03:58.972547 192.168.10.1:5060 -> 192.168.10.1:5060 ACK sip:domain.net SIP/2.0
This is an ACK for a INVITE 200, so it's a new transaction (a in-dialog request) rather than part of the INVITE transaction (as an ACK for a [3456]XX response would be).
The RURI is modified by Kamailio, this means that your script is doing it. What do you do with your in-dialog requests? what do you do with ACK (INVITE-200)? Are you using "$ru=" or "sethostport"/"writehostport" for them?
-- Iñaki Baz Castillo ibc@aliax.net
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
Hm. We do rather a lot of things with the SIP uri, both reformatting the content and changing hosts depending on the number.
You should NEVER modify a request uri in an in-dialog request, NEVER.
However, I thought this was OK since anything that was changed would be "record routed" and handled via the loose route portion.
Again: RURI must not be modified in an in-dialog request, regardless of the usage of record-route.
The ACK that is sent from the SNOM gets caught by the looseroute script. Should it?
The ACK from SNOM must pass through looseroute script since, as I already explained, it is in fact an in-dialog request.
I'm a bit confused now, can't really see how I'm going to fix this... Our script is rather large and ugly :/
Don't modify RURI in loose-route section. Just it.
I was just under the impression that loose route meant the packets "knew" where they were going...
Yes, and that is due to the existance of a Route header. When a proxy receives an in-dialog request with Route header it must inspect that header. Usually it contains a proxy local address so the proxy removes that header and routes the request based on the RURI (but MUST NOT change the RURI !!!).
I think maybe there's some misunderstanding here. We don't modify RURI in the looseroute, it's quite simply
if looseroute t_relay()
We do modify the original INVITE's (basically adding prefixes and changing domain to forward it to the correct gateway).
Thing is, the contact field from the PBX is Contact: sip:192.168.20.1
This causes the phone to reply with ACK sip:192.168.20.1 SIP/2.0
And apparently OpenSER (our script?) doesn't know how to handle this when it comes to looseroute so it looks at the To: header instead (which is the original unmodified header i.e. To: number@sip.domain.no
From our Gateway the contact field is
Contact: sip:number@gateway.net
To which the phone replies ACK sip:number@gateway.net SIP/2.0
And seems to be more to OpenSERs (our scripts?) liking as it then just relays it to the correct address.
Is using rewritehost() the WRONG way to go about forwarding the INVITEs to the right Gateway?
- Geir
-----Original Message----- From: Iñaki Baz Castillo [mailto:ibc@aliax.net] Sent: 3. mars 2009 12:16 To: Geir O. Jensen Cc: users@lists.kamailio.org Subject: Re: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
Hm. We do rather a lot of things with the SIP uri, both
reformatting
the content and changing hosts depending on the number.
You should NEVER modify a request uri in an in-dialog request, NEVER.
However, I thought this was OK since anything that was
changed would
be "record routed" and handled via the loose route portion.
Again: RURI must not be modified in an in-dialog request, regardless of the usage of record-route.
The ACK that is sent from the SNOM gets caught by the
looseroute script.
Should it?
The ACK from SNOM must pass through looseroute script since, as I already explained, it is in fact an in-dialog request.
I'm a bit confused now, can't really see how I'm going to
fix this...
Our script is rather large and ugly :/
Don't modify RURI in loose-route section. Just it.
I was just under the impression that loose route meant the
packets "knew"
where they were going...
Yes, and that is due to the existance of a Route header. When a proxy receives an in-dialog request with Route header it must inspect that header. Usually it contains a proxy local address so the proxy removes that header and routes the request based on the RURI (but MUST NOT change the RURI !!!).
-- Iñaki Baz Castillo ibc@aliax.net
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
I think maybe there's some misunderstanding here. We don't modify RURI in the looseroute, it's quite simply
if looseroute t_relay()
The RURI of the ACK (INVITe-200) is different when it arrives to Kamailio and when it leaves it, so "something" is modifying it. Of course Kamailio doesn't do that for itself.
And apparently OpenSER (our script?) doesn't know how to handle this when it comes to looseroute so it looks at the To: header instead (which is the original unmodified header i.e. To: number@sip.domain.no
No, OpenSer *never* routes based on To header, never. It would be really pathetic ;)
From our Gateway the contact field is Contact: sip:number@gateway.net
To which the phone replies ACK sip:number@gateway.net SIP/2.0
And seems to be more to OpenSERs (our scripts?) liking as it then just relays it to the correct address.
That's not what I see in the capture:
- The ACK sent by the SNOM phone is correct since the RURI matches the Contact URI received in the 200 Ok:
U 2009/03/03 11:03:58.968311 192.168.10.10:5060 -> 192.168.10.1:5060 ACK sip:192.168.20.1 SIP/2.0
- When the ACK leaves OpenSer it has the RURI *obviously* modified, and it resolves to OpenSER's address (so we have a loop):
U 2009/03/03 11:03:58.972547 192.168.10.1:5060 -> 192.168.10.1:5060 ACK sip:domain.net SIP/2.0
Again *obviously* your script is modifying the ACK RURI and it MUST NOT do it.
Is using rewritehost() the WRONG way to go about forwarding the INVITEs to the right Gateway?
It's fully correct, but onlye initial request may have the RURI modified by OpenSer, never an in-dialog request (ACK for INVITE-200).
Please, believe me: your script is wrong since it's replacing the ACK RURI, that's all.
The RURI of the ACK (INVITe-200) is different when it arrives to Kamailio and when it leaves it, so "something" is modifying it. Of course Kamailio doesn't do that for itself.
Please, believe me: your script is wrong since it's replacing the ACK RURI, that's all.
Your insistency made me take a loong hard look at the script.
What did I find tucked away neatly where I wasn't looking?
if (!uri=~"sip:.+@.+") { rewritehost("domain.net"); };
AAARGH! Basically we have one user that insist on using a client that doesn't add the domain in it's sip uri's when doing INVITES and SUBSCRIBES so some long time ago, these lines were added to help him. I knew I shouldn't have done such a silly thing...
Now I feel stupid for wasting your time :(
And sad that I didn't catch this one myself... Though since our primary GW uses full URI's in the contact field it was never a problem. I can't even remember how long that has been sitting in there... Atleast a year :/
Anyways, thanks for the help, and for making me take a loong good look at parts of the script I'd written off as "perfect".
- Geir
2009/3/3 Geir O. Jensen geir.o.jensen@uninett.no:
The RURI of the ACK (INVITe-200) is different when it arrives to Kamailio and when it leaves it, so "something" is modifying it. Of course Kamailio doesn't do that for itself.
Please, believe me: your script is wrong since it's replacing the ACK RURI, that's all.
Your insistency made me take a loong hard look at the script.
What did I find tucked away neatly where I wasn't looking?
if (!uri=~"sip:.+@.+") { rewritehost("domain.net"); };
:)
AAARGH! Basically we have one user that insist on using a client that doesn't add the domain in it's sip uri's when doing INVITES and SUBSCRIBES so some long time ago, these lines were added to help him. I knew I shouldn't have done such a silly thing...
Now I feel stupid for wasting your time :(
Don't worry, at least we've found the bug :)
And sad that I didn't catch this one myself... Though since our primary GW uses full URI's in the contact field it was never a problem. I can't even remember how long that has been sitting in there... Atleast a year :/
Anyways, thanks for the help, and for making me take a loong good look at parts of the script I'd written off as "perfect".
"Perfect"? I don't know that word XD
Best regards.
-
Daniel-Constantin Mierla -
Geir O. Jensen -
Iñaki Baz Castillo