2 Mar
2009
2 Mar
'09
1:36 p.m.
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
--
Daniel-Constantin Mierla
http://www.asipto.com
2 Mar
2 Mar
2:46 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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
3:45 p.m.
New subject: [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(a)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
3:48 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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(a)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
5:09 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
2009/3/2 Geir O. Jensen <geir.o.jensen(a)uninett.no>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(a)aliax.net>
3 Mar
3 Mar
12:14 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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(a)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(a)uninett.no>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(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
12:40 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen <geir.o.jensen(a)uninett.no>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(a)aliax.net>
1:07 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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(a)uninett.no>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(a)aliax.net>
1:15 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen <geir.o.jensen(a)uninett.no>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(a)aliax.net>
1:22 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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(a)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(a)lists.kamailio.org
Subject: Re: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen <geir.o.jensen(a)uninett.no>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(a)aliax.net>
1:45 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen <geir.o.jensen(a)uninett.no>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(a)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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:08 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
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
2:16 p.m.
New subject: [Kamailio-Users] Problem with sip uri in contact field
2009/3/3 Geir O. Jensen <geir.o.jensen(a)uninett.no>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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5750
days inactive
5751
days old
12 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Geir O. Jensen -
Iñaki Baz Castillo