Christof Meerwald | 8 Feb 14:39 2004
Picon

Siproxd uses random port to send SIP messages

Hi,

I am unable to connect to sipgate.de via siproxd and I have tracked it down
to a problem in siproxd: when siproxd forwards a SIP message it uses a
random local port to send the UDP packet. sipgate.de seems to use this
address to send replies to, but siproxd doesn't listen on this port and so
the reply is lost.

Here is a tcpdump:

14:21:57.348815 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
14:21:57.358810 217.10.79.9.5060 > 62.241.36.165.3769:  udp 689 (DF) [tos 0x10]
14:22:01.275851 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
14:22:01.285601 217.10.79.9.5060 > 62.241.36.165.3769:  udp 689 (DF) [tos 0x10]
14:22:05.320897 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
14:22:05.331116 217.10.79.9.5060 > 62.241.36.165.3769:  udp 690 (DF) [tos 0x10]
14:22:09.306329 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
14:22:09.317900 217.10.79.9.5060 > 62.241.36.165.3769:  udp 690 (DF) [tos 0x10]

As you can see, replies are sent to port 3769 on my machine, but siproxd
doesn't expect replies to be sent to this port (it only listens on port 5060
for replies).

Fixing the problem is simple (use the same socket for sending and receiving
SIP messages):

- remove the line "int sip_socket=0;" in src/siproxd.c
- rename the "listen_socket" in src/sock.c to "sip_socket"

bye, Christof
(Continue reading)

Thomas Ries | 12 Feb 23:21 2004
Picon
Picon

Re: Siproxd uses random port to send SIP messages

Hi Christof,

I included your suggested change. However, it seems that sipgate.de
does not properly implement symmetric SIP signalling...

Symmetric SIP signalling is requested by a 'rport' parameter in the
topmost 'via' header - which siproxd does *NOT* include.

Details:
http://www.jdrosen.net/papers/draft-ietf-sip-symmetric-response-01.html

Anyhow, I hope now siproxd is more tolerant in this respect ;-)

Regards,
/Thomas

On  8 Feb, Christof Meerwald wrote:
> Hi,
> 
> I am unable to connect to sipgate.de via siproxd and I have tracked it down
> to a problem in siproxd: when siproxd forwards a SIP message it uses a
> random local port to send the UDP packet. sipgate.de seems to use this
> address to send replies to, but siproxd doesn't listen on this port and so
> the reply is lost.
> 
> Here is a tcpdump:
> 
> 14:21:57.348815 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
> 14:21:57.358810 217.10.79.9.5060 > 62.241.36.165.3769:  udp 689 (DF) [tos 0x10]
> 14:22:01.275851 62.241.36.165.3769 > 217.10.79.9.5060:  udp 553 (DF)
(Continue reading)

Thomas Ries | 14 Feb 11:43 2004
Picon
Picon

siproxd-0.5.3 released

Release Notes for siproxd-0.5.3
===============================

Major changes since 0.5.2:
 - Support for connections between 2 local (masqueraded) UAs
 - Symmetric SIP signalling
 - handling of Max-Forwards header
 - A lot of smaller bugfixes

General Overview:
 - SIP (RFC3261) Proxy for SIP based softphones hidden behind a
   masquerading firewall
 - works with "dial-up" conenctions (dynamic IP addresses)
 - Multiple local users/hosts can be masqueraded simultaneously
 - Access control (IP based) for incoming traffic
 - Proxy Authentication for registration of local clients (User Agents)
   with individual passwords for each user
 - May be used as pure Outbound proxy (registration of local UAs
   to a 3rd party registrar)
 - Fli4l OPT_SIP (still experimental) available, check
   http://home.arcor.de/jsffm/fli4l/
 - supports Linux, FreeBSD and Solaris
 - Full duplex RTP data stream proxy for *incoming* and *outgoing*
   audio data - no firewall masquerading entries needed
 - Port range to be used for RTP traffic is configurable
   (-> easy to set up apropriate firewall rules for RTP traffic)
 - RTP proxy can handle multiple RTP streams (eg. audio + video)
   within a single SIP session.
 - Supports running in a chroot jail and changing user-ID after startup
 - All configuration done via one simple ascii configuration file
(Continue reading)


Gmane