Darrin Smart | 6 May 21:44 2011

Re-writing RFC 3605 SDP attributes

Hi All,

In this example I have a Aastra 9480i phone at I have a
siproxd instance running on a machine that straddles the 10.1.0
internal network and 64.60.XX.YY public IP address.

I have an asterisk server that also happens to be running on the same
public IP address (for now). I am using sipproxd so that handsets can
bypass Asterisk for their RTP streams negotiate directly with the
other endpoint.

Take a look at the extracted SDP packet below. This was captured on
the outbound side of siproxd, between siproxd and the Asterisk server.
You can see that it's rewritten most of the packet perfectly. The only
problem is that the handset has included RFC 3605 RTCP attributes, and
these have not been rewritten by siproxd.

I can't find a way to stop my handsets setting this attribute, so it
would be great if siproxd could rewrite it.



    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): MxSIP 0 1 IN IP4 64.60.XX.YY
                Owner Username: MxSIP
                Session ID: 0
(Continue reading)

Darrin Smart | 24 May 08:35 2011

Re: Re-writing RFC 3605 SDP attributes

I had a poke at the source code and made a quick change that addressed
my problem. I simply clear the rtcp media attribute on packets that
flow through siproxd. The patch below is against the
siproxd-08May2011.tar.gz tarball.

As the comment says, a more correct solution is to properly implement
RFC3605, but this hack seems to work well for me (where I can't set my
handsets to omit this field themselves).

diff -ur siproxd-0.8.1dev/src/proxy.c siproxd-0.8.1dev-patched/src/proxy.c
--- siproxd-0.8.1dev/src/proxy.c	2010-03-29 10:30:58.000000000 -0700
+++ siproxd-0.8.1dev-patched/src/proxy.c	2011-05-08 10:43:19.000000000 -0700
 <at>  <at>  -965,6 +965,14  <at>  <at> 
                    "MUTE c= record (media level)");
+      /*
+       * Clear any RFC 3605 rtcp attributes. It would probably be better
+       * to actually make use of them on the inbound and outbound sides,
+       * but clearing them is better than possibly sending NAT'd IP addresses
+       * out to the internet.
+       */
+      sdp_message_a_attribute_del(sdp, media_stream_no, "rtcp");

       /* start an RTP proxying stream */
       if (sdp_message_m_port_get(sdp, media_stream_no)) {

vRanger cuts backup time in half-while increasing security.
(Continue reading)