[OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen= syntax to support per-interface advertised
SourceForge.net
noreply at sourceforge.net
Tue May 26 18:52:30 CEST 2009
Patches item #2706135, was opened at 2009-03-23 15:50
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised
Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]
The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.
Syntax-wise, it works like this:
listen=[proto:]host[:port][ AS host[:port]]
This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure. If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket. If it is not specified, then the old methods work as before.
The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this. Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:
force_send_socket(udp:adv_address:adv_port);
force_send_socket(udp:real_address:real_port);
Note we don't specify protocol on the advertised address. The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.
Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.
Lump substitution is also affected. The following lump substitutions are aware
of this new facility:
SUBST_RCV_IP
SUBST_RCV_PORT
SUBST_RCV_ALL
SUBST_SND_IP
SUBST_SND_PORT
SUBST_SND_ALL
As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route. This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.
Additionally, registrar and usrloc had to be modified:
registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address. This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.
usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address. Same reasoning as the mods to registrar.
----------------------------------------------------------------------
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 19:52
Message:
Hi Guys,
Is the bug fixed in the patch ? I just want to know to start evaluating
the patch for upload.
Thanks and regards,
Bogdan
----------------------------------------------------------------------
Comment By: Nergal (nergalex)
Date: 2009-05-26 12:44
Message:
Hello Phil,
After few tests, I identified the exact context when the problem appear. I
answer to your questions before.
1) b) An extra random character, this morning is '.' that appears in the
first
Record-Route header after host:port BUT always in a specific context, see
#3.
2) I have "listen=X.X.X.X:5060 AS X.X.X.Y:5060" in my configuration and
also:
listen=X.X.X.X:15060 AS X.X.X.Y:5060
3) [NEW] The problem appears when the SIP message match the
"X.X.X.X:15060" instance. The rewrite of RR is done by the line
"listen=X.X.X.X:15060 AS X.X.X.Y:5060". In this case, the extra caracter is
suffixed to the first RR port (public inbound interface).
The problem appears for UDP and TCP protocol.
NB: 2 instances (5060 and 15060) of my SIP proxy is load-balanced. So, the
random effect is made by:
- If "SIP message destination = 5060" So test OK
- If "SIP message destination = 15060" So test Not OK
Best regards
Alexis
----------------------------------------------------------------------
Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-25 23:18
Message:
Alexis :
I have a few questions for you:
1) To make sure I understand the problem, I want to re-word it a bit.
Which of these statements is true about the problem
a) An extra ';' (always a ';') character appears in the first
Record-Route header after host:port, at random times.
b) An extra random character (not always ';') appears in the first
Record-Route header after host:port, at random times
2) Since you are using double-rr can I assume that you also have a
listen=X.X.X.X:5060 line in your configuration for your public inbound
interface, but it was not included in your message because it does not
specify the [AS host:port] portion?
If the answer to 2 is yes, can you try to specify an alias on that listen=
line like this:
listen=X.X.X.X:5060 AS X.X.X.X:5060
The effect should be that no re-write appears to happen as the left and
right side are the same, but the code used to get there would be slightly
different. I'm curious to see if the extra ';' goes away in that case.
Thanks,
Phil
----------------------------------------------------------------------
Comment By: Nergal (nergalex)
Date: 2009-05-25 11:20
Message:
Hello,
Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817
Best regards
Alexis
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';').
Could you help me to fix it?
I can do more test or give you more information if you need.
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long.
conf extract:
- X.X.X.X is a public IP
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060
- force_send_socket(10.143.136.8:15060);
- t_relay("tcp:10.143.81.130:5060")
--- Test OK / proto TCP ---
1. Before SIP proxy processing (Front interface capture)
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060>
Call-ID: 1-1338 at 10.95.10.1
CSeq: 1 SUBSCRIBE
Contact: sip:sipp at 10.95.10.1:10005
Max-Forwards: 70
Subject: Subscribe Test
Content-Length: 0
2. After SIP proxy processing (Back interface capture)
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001>
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001>
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060>
Call-ID: 1-1338 at 10.95.10.1
CSeq: 1 SUBSCRIBE
Contact: sip:sipp at 10.95.10.1:10005
Max-Forwards: 69
Subject: Subscribe Test
Content-Length: 0
--- end Test OK ---
--- Test NOK / proto TCP ---
1. Before SIP proxy processing (Front interface capture)
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060>
Call-ID: 1-1571 at 10.95.10.1
CSeq: 1 SUBSCRIBE
Contact: sip:sipp at 10.95.10.1:10003
Max-Forwards: 70
Subject: Subscribe Test
Content-Length: 0
2. After SIP proxy processing (Back interface capture)
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001>
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001>
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060>
Call-ID: 1-1571 at 10.95.10.1
CSeq: 1 SUBSCRIBE
Contact: sip:sipp at 10.95.10.1:10003
Max-Forwards: 69
Subject: Subscribe Test
Content-Length: 0
--- end Test NOK ---
Best regards
Alexis
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 11:15
Message:
Hi Phil,
I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.
Thanks and regards,
Bogdan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&group_id=232389
More information about the Devel
mailing list