[Serusers] FCP support in SER: Modifying SDP

[jaime.gill at orange.co.uk]

Thanks Jiri,

I'll have a look at the CVS version. I'm sure there will be more hacking to do
only to make it compile.... :(

However, got the replacement of the "c=.." part working. I'll test this as soon
as I can.

Jaime





Jiri Kuthan <jiri at iptel.org> on 24/02/2003 13:20:00




To:   Jaime GILL/EN/HTLUK at HTLUK
      Nils Ohlmeier <nils at ohlmeier.de>
cc:   Jan Janak <J.Janak at sh.cvut.cz>
      serusers at lists.iptel.org


Subject:  Re: [Serusers] FCP support in SER: Modifying SDP



At 12:50 PM 2/24/2003, jaime.gill at 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

_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: att1.eml
Type: application/octet-stream
Size: 5167 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20030224/abd1fe20/attachment.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 --------------