[Serusers] FCP support in SER: Modifying SDP

jaime.gill at orange.co.uk jaime.gill at orange.co.uk
Mon Feb 24 12:50:13 CET 2003


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 at asereje.orange.co.uk SIP/2.0
Call-ID: 5812832001907970791 at 172.21.68.78
Content-Length: 121
Content-Type: application/sdp
To: sip:jaime at asereje.orange.co.uk
From: sip:pepe at asereje.orange.co.uk;tag=-779729009
Contact: sip:pepe at 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 at 172.21.68.78
Content-Length: 121
Content-Type: application/sdp
To: sip:jaime at asereje.orange.co.uk
From: sip:pepe at 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 at ohlmeier.de> on 18/02/2003 02:58:47




To:   Jaime GILL/EN/HTLUK at HTLUK
cc:   Jan Janak <J.Janak at sh.cvut.cz>
      Jiri Kuthan <jiri at 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 at orange.co.uk wrote:
> U 192.168.6.153:5060 -> 172.21.68.78:5061
>   INVITE sip:pepe at 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 at asereje.orange.co.uk>;tag=8c20540f-4259-11d7-9cc5
> -00065b4c11cb..To: <sip:pepe at asereje.orange.co.uk>..Call-ID: 8c205410-4259-
> 11d7-9cc5-00065b4c11cb at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: att1.unk
Type: application/octet-stream
Size: 198 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20030224/5174d690/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: att2.eml
Type: application/octet-stream
Size: 3299 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20030224/5174d690/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcp-module210203.tar.gz
Type: application/octet-stream
Size: 13961 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20030224/5174d690/attachment-0002.obj>
-------------- next part --------------

*******************************************************************************
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.
*******************************************************************************
-------------- next part --------------



More information about the sr-users mailing list