Hi Nils,
Once again I'm writing to ask about more things and to give you an update on what is happening with the FCP tests...
We have set up a simple scenario with 2 proxies separated by a firewall/NAT, and 2 UA, one within (UA1) and another outside the firewall (UA2). One UA registers with the natted proxy (UA1), the other with the "public" proxy (UA2).
At the moment, SIP messages go forwards and backwards without problems, but media is not flowing across the firewall. It think the problem is in the replacement of the SDP information. The first occurrence of the IP address in "v= " and the port in "m= " in the SDP get replaced, but the second IP in "c=" is not. I have been trying all sorts of things, but no joy :( . Here are the INVITE messages in more detail. I also include the latest fcp module for you to play with it.
---------- UA1 to proxy message ------------------
U 172.21.68.78:1129 -> 192.168.6.153:5060 INVITE sip:jaime@asereje.orange.co.uk SIP/2.0 Call-ID: 5812832001907970791@172.21.68.78 Content-Length: 121 Content-Type: application/sdp To: sip:jaime@asereje.orange.co.uk From: sip:pepe@asereje.orange.co.uk;tag=-779729009 Contact: sip:pepe@172.21.68.78:5061 CSeq: 1 INVITE Via: SIP/2.0/UDP 172.21.68.78:5061;branch=AC15444E13C5000000F38F819DE5-2*0
v=0..o=- 1046084768435 1046084768465 IN IP4 172.21.68.78 s=- c=IN IP4 172.21.68.78 t=0 0 m=audio 5006 RTP/AVP 8 3 0
---------- End of UA1 to proxy message -----------------
-------- Proxy to UA2 message ---------------------
U 192.168.6.153:5060 -> 172.21.68.78:15592 INVITE sip:172.21.68.78:15592 SIP/2.0 Call-ID: 5812832001907970791@172.21.68.78 Content-Length: 121 Content-Type: application/sdp To: sip:jaime@asereje.orange.co.uk From: sip:pepe@asereje.orange.co.uk;tag=-779729009 Contact:sip:192.168.0.1:33240 CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.6.153;branch=z9hG4bK1019.21c52996.0 Via: SIP/2.0/UDP 172.21.68.78:5061;branch=AC15444E13C5000000F38F819DE5-2*0
v=0..o=- 1046084768435 1046084768465 IN IP4 192.168.0.1 s=- c=IN IP4 172.21.68.78 <--- Need to change this as well!!! t=0 0 m=audio 33240 RTP/AVP 8 3 0
------------ End of Proxy to UA2 message -------------------
(See attached file: fcp-module210203.tar.gz)
I have been trying to understand how the proxy builds the forwarded message from the old one, and realised that for the Via replacement (or adding of more params), I need to be using a string called add_to_branch_s and add_to_branch_len (so ignore the replace_via implementation in the current tar.gz). But for the SDP, whenever I work with get_body, it does not modify it appropriately. So currently, I'm using msg->orig to get to the initial message, search for certain IP4 and audio strings and replace them with the information provided by the fcp server. That means, in the case of the SDP, 2 IP address replacements (in v=.. and c=..) and 1 port replacement (in m=..). As I mentioned before, I only manged to change the v=.. and m=... Whenever I try to replace more than one appearance, strange things happen, like strings in non expected places, like Via, and cannot work out why. So my question is an open one:): what is the best way to change the SDP part?
The other of my questions is whether all this mess with NAT's will get solved when the proxy supports TCP, and whether this is the best approach to solve the SIP through NAT/FW problem. For example, how about a nathelper module for netfilter/iptables that gets this working, in the same manner as IRC or ftp currently? Does anybody know about any work progressing this for linux/FreeBSD?
Greetings,
Jaime
Nils Ohlmeier nils@ohlmeier.de on 18/02/2003 02:58:47
To: Jaime GILL/EN/HTLUK@HTLUK cc: Jan Janak J.Janak@sh.cvut.cz Jiri Kuthan jiri@iptel.org
Subject: Re: [Serusers] FCP support in SER: Modifying SDP
Hi Jaime,
debugging without the code is really hard :-) But maybe your problme with SDP is correlated to a bug in the Via header which i marked below.
Greetings Nils
On Monday 17 February 2003 11:58, jaime.gill@orange.co.uk wrote:
U 192.168.6.153:5060 -> 172.21.68.78:5061 INVITE sip:pepe@172.21.68.78:5061 SIP/2.0..Via: SIP/2.0/UDP 192.168.6.153;b ranch=z9hG4bKb848.8a014f84.0..Via: SIP/2.0/UDP 192.168.0.1192.168.0.1:9439. .From: "jaime"
^^^^^^^^^^^^^^^^^^^^^^ Here you inserted the external IP twice. Maybe your SDP replacer did this?
sip:jaime@asereje.orange.co.uk;tag=8c20540f-4259-11d7-9cc5 -00065b4c11cb..To: sip:pepe@asereje.orange.co.uk..Call-ID: 8c205410-4259- 11d7-9cc5-00065b4c11cb@172.21.68.78..CSeq: 1 INVITE..Contact:sip:192.168.0 .1:33186.User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Conte nt-Length: 211....v=0..o=gill_j 0 0 IN IP4 172.21.68.78..s=session..c=IN IP 4 172.21.68.78..b=CT:1000..t=0 0..m=audio 33186 RTP/AVP 97 0 8 4..a=rtpmap: 97 red/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/80 00..
-- gpg-key: http://www.ohlmeier.org/public_key.asc
******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately.
Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************
At 12:50 PM 2/24/2003, jaime.gill@orange.co.uk wrote: [...]
It think the problem is in the replacement of the SDP information. The first occurrence of the IP address in "v= " and the port in "m= " in the SDP get replaced, but the second IP in "c=" is not.
nit: it's not the "v=" line, but "o=" ('owner') line which you are replacing. However, you are not probably worried so much about this one -- it maintains primarily a (not widely utilizied) identification purpose. All "c=" occurences do matter. (In addition to port numbers in "m=" lines.)
[...]
I have been trying to understand how the proxy builds the forwarded message from the old one, and realised that for the Via replacement (or adding of more params), I need to be using a string called add_to_branch_s and add_to_branch_len (so ignore the replace_via implementation in the current tar.gz).
I suggest you used the mhomed option (available only on CVS). The issue is you need to print the correct IP address in Via on multihomed host. With mhomed enabled, IP routing is utilized to determine the right IP address. Let me know if you need something more for getting Via right.
But for the SDP, whenever I work with get_body, it does not modify it appropriately. So currently, I'm using msg->orig to get to the initial message, search for certain IP4 and audio strings and replace them with the information provided by the fcp server. That means, in the case of the SDP, 2 IP address replacements (in v=.. and c=..) and 1 port replacement (in m=..). As I mentioned before, I only manged to change the v=.. and m=... Whenever I try to replace more than one appearance, strange things happen, like strings in non expected places, like Via, and cannot work out why. So my question is an open one:): what is the best way to change the SDP part?
I suggest here too -- use the CVS version. It has departed from the use of the buffers (orig and buf) -- we have now just one buffer (buf) without any zero termination. Previously, the two buffers and 0-termination caused lot of issues, some of them possibly annoying you right now. Look at the textops/replace_all action (only on CVS too) to see how to replace multiple occurences of a string in SIP messages. (Caution: you will eventually need to calculate new SDP body size and change content-length too.)
The other of my questions is whether all this mess with NAT's will get solved when the proxy supports TCP,
The major problem is media, which will keep using UDP.
and whether this is the best approach to solve the SIP through NAT/FW problem.
As all NAT traversal methods -- none of them is perfect, each has cons and pros. The benefit of FCP is that once fcpd works, maintenance of the SIP code is easier in user space. Also, you can better couple your pinhole policy with SER's SIP-layer policy.
For example, how about a nathelper module for netfilter/iptables that gets this working, in the same manner as IRC or ftp currently? Does anybody know about any work progressing this for linux/FreeBSD?
I'm not aware of such. There is Billy Biggs masquerading module, but it is pretty old and no longer maintained.
-Jiri
-
jaime.gill＠orange.co.uk -
Jiri Kuthan