siproxd-users — Users Mailing List

[Siproxd-users] Release 0.5.12

[Thomas R. <tr...@gm...>]

Release Notes for siproxd-0.5.12
================================

Major changes since 0.5.11:
   A "Short-Dial" feature is now available.
   A number of bugfixes have been made. These include some issues
   with Grandstream phones and the "unregister at startup" option,
   as well as other issues with the expiration timeout.

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/
 - runs on various operating systems (see below)
 - 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.
 - Symmetric RTP support
 - Symmetric SIP signalling support
 - Supports running in a chroot jail and changing user-ID after startup
 - All configuration done via one simple ascii configuration file
 - Logging to syslog in daemon mode
 - RPM package
 - The host part of UA registration entries can be masqueraded
   (mask_host, masked_host config items). Some Siemens SIP phones seem to
   need this 'feature'.
 - Provider specific outbound proxies can be configured
 - Can run "in front of" a NAT router.(in the local LAN segment)
 - supports "Short-Dials"

Requirements:
 - pthreads (Linux)
 - glibc2 / libc5 / uClibc
 - libosip2

Currently tested on:
- Fedora Core1 (Kernel 2.4.x, Glibc)
  This is my main development and testing environment. Other platforms
  are not extensively tested by myself.

Builds on:
- Linux:	Fedora Core1
		Fedora Core3 (x86_64 - 64 bit)
		WRT54g (133mhz mipsel router)
- FreeBSD:	FreeBSD 4.10-BETA
- OpenBSD:	OpenBSD 3.4 GENERIC#18
- SunOS:	SunOS 5.9
- Mac OS X:	Darwin 6.8
- Windows:	Cygwin environment

Reported interoperability with softphones:
 - Grandstream BudgeTone-100 series
 - Linphone (local and remote UA) (http://www.linphone.org)
 - Kphone (local and remote UA) (http://www.wirlab.net/kphone/)
 - MSN messenger 4.6 (remote and local UA)
 - X-Lite (Win XP Professional)
 - SJPhone softphone

Reported interoperability with SIP service providers:
 - Sipphone	(http://www.sipphone.com)
 - FWD		(http://www.fwd.pulver.com)
 - Sipgate *)	(http://www.sipgate.de)
 - Stanaphone	(SIP Gateway to PSTN)

 *) There have been reports of people having problems using
    siproxd with these providers.


 If you have siproxd successfully running with another SIP phone
 and/or service provider, please drop me a short note so I can update
 the list.

Known bugs:
   - SRV DNS records are not yet looked up, only A records
   There will be more...

If you port siproxd to a new platform or do other kinds of changes
or bugfixes that might be of general interest, please drop me a
line. Also if you intend to include siproxd into a software
distribution I'd be happy to get a short notice.


-----
md5sum for siproxd-0.5.12.tar.gz: 	2fa02bd6f83070593bfc2d383ce614fa

GnuPG signature for siproxd-0.5.12.tar.gz archive:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBEP57MCfzBioe83JQRAntEAJ93Q4ba+OYsKKsY863TodsRS56QqQCcDUmp
qN8NJl/4atCZiyOs7CNn0hI=
=REmU
-----END PGP SIGNATURE-----


GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

[Siproxd-users] IPPBX to PSTN Gateway, no registration issue

[<lin...@eb...>]

I'm attempting to get a Cisco CallManager 5 (CM5) server to talk to a Global Crossing (GX) PSTN gateway over the public Internet.

CM5 is on the private IP network at 10.99.1.10.
GX is at 208.49.124.43.
The firewall is at eth1=10.100.254.73 and eth0=12.31.231.1.

I'm using siproxd-0.5.12 downloaded from CSV yesterday and libosip2-2.2.2.

CM5 is configured to attempt to talk to GX directly and I'm using iptables to implement transparent SIP proxy.

The CM5 sends it's requests, the redirect sends the packets to the siproxd and siproxd sends a 408 Request timeout because it can't find a route.  It can't find a route because there is no UA to register for siproxd to extract the route from.  (saw the notes about 404 and 403 but I don't think it matters here)

All traffic will be between these two systems so the route will need to be hard coded.

Tried various config combinations and even tried digging in the source for it but my sip skills are limited.

Tried looking for a siproxd_registrations file via google so that I could forge a registration entry but no joy.

How do I hard code the route between two hosts or get a route entered for server to gateway communications?

Thanks
Linuxboy

attempt log:
/sbin/siproxd --config /etc/siproxd.conf -d -1
14:28:19 INFO:siproxd.c:180 siproxd-0.5.12-3500 i686-pc-linux-gnu starting up
14:28:19 readconf.c:69 trying to read config file
14:28:19 readconf.c:90 ... trying /etc/siproxd.conf
14:28:19 readconf.c:209 pc:"if_inbound= eth0"
14:28:19 readconf.c:216 got keyword:"if_inbound"
14:28:19 readconf.c:226 got argument:"eth0"
14:28:19 readconf.c:259 STRING=eth0
14:28:19 readconf.c:209 pc:"if_outbound = eth1"
14:28:19 readconf.c:216 got keyword:"if_outbound"
14:28:19 readconf.c:226 got argument:"eth1"
14:28:19 readconf.c:259 STRING=eth1
14:28:19 readconf.c:209 pc:"hosts_allow_reg = 10.0.0.0/8"
14:28:19 readconf.c:216 got keyword:"hosts_allow_reg"
14:28:19 readconf.c:226 got argument:"10.0.0.0/8"
14:28:19 readconf.c:259 STRING=10.0.0.0/8
14:28:19 readconf.c:209 pc:"sip_listen_port = 5060"
14:28:19 readconf.c:216 got keyword:"sip_listen_port"
14:28:19 readconf.c:226 got argument:"5060"
14:28:19 readconf.c:241 INT4=5060
14:28:19 readconf.c:209 pc:"daemonize = 0"
14:28:19 readconf.c:216 got keyword:"daemonize"
14:28:19 readconf.c:226 got argument:"0"
14:28:19 readconf.c:241 INT4=0
14:28:19 readconf.c:209 pc:"silence_log = 1"
14:28:19 readconf.c:216 got keyword:"silence_log"
14:28:19 readconf.c:226 got argument:"1"
14:28:19 readconf.c:241 INT4=1
14:28:19 readconf.c:209 pc:"log_calls = 1"
14:28:19 readconf.c:216 got keyword:"log_calls"
14:28:19 readconf.c:226 got argument:"1"
14:28:19 readconf.c:241 INT4=1
14:28:19 readconf.c:209 pc:"user = root"
14:28:19 readconf.c:216 got keyword:"user"
14:28:19 readconf.c:226 got argument:"root"
14:28:19 readconf.c:259 STRING=root
14:28:19 readconf.c:209 pc:"registration_file = /var/lib/siproxd_registrations"
14:28:19 readconf.c:216 got keyword:"registration_file"
14:28:19 readconf.c:226 got argument:"/var/lib/siproxd_registrations"
14:28:19 readconf.c:259 STRING=/var/lib/siproxd_registrations
14:28:19 readconf.c:209 pc:"pid_file = /var/run/siproxd/siproxd.pid"
14:28:19 readconf.c:216 got keyword:"pid_file"
14:28:19 readconf.c:226 got argument:"/var/run/siproxd/siproxd.pid"
14:28:19 readconf.c:259 STRING=/var/run/siproxd/siproxd.pid
14:28:19 readconf.c:209 pc:"rtp_proxy_enable = 1"
14:28:19 readconf.c:216 got keyword:"rtp_proxy_enable"
14:28:19 readconf.c:226 got argument:"1"
14:28:19 readconf.c:241 INT4=1
14:28:19 readconf.c:209 pc:"rtp_port_low = 7070"
14:28:19 readconf.c:216 got keyword:"rtp_port_low"
14:28:19 readconf.c:226 got argument:"7070"
14:28:19 readconf.c:241 INT4=7070
14:28:19 readconf.c:209 pc:"rtp_port_high = 7079"
14:28:19 readconf.c:216 got keyword:"rtp_port_high"
14:28:19 readconf.c:226 got argument:"7079"
14:28:19 readconf.c:241 INT4=7079
14:28:19 readconf.c:209 pc:"rtp_timeout = 300"
14:28:19 readconf.c:216 got keyword:"rtp_timeout"
14:28:19 readconf.c:226 got argument:"300"
14:28:19 readconf.c:241 INT4=300
14:28:19 readconf.c:209 pc:"default_expires = 600"
14:28:19 readconf.c:216 got keyword:"default_expires"
14:28:19 readconf.c:226 got argument:"600"
14:28:19 readconf.c:241 INT4=600
14:28:19 readconf.c:209 pc:"debug_level = 0"
14:28:19 readconf.c:216 got keyword:"debug_level"
14:28:19 readconf.c:226 got argument:"0"
14:28:19 readconf.c:241 INT4=0
14:28:19 readconf.c:209 pc:"debug_port = 0"
14:28:19 readconf.c:216 got keyword:"debug_port"
14:28:19 readconf.c:226 got argument:"0"
14:28:19 readconf.c:241 INT4=0
14:28:19 readconf.c:209 pc:"mask_host = 10.99.1.10"
14:28:19 readconf.c:216 got keyword:"mask_host"
14:28:19 readconf.c:226 got argument:"10.99.1.10"
14:28:19 readconf.c:279 STRINGA[0]=10.99.1.10
14:28:19 readconf.c:209 pc:"masked_host = 12.31.231.1"
14:28:19 readconf.c:216 got keyword:"masked_host"
14:28:19 readconf.c:226 got argument:"12.31.231.1"
14:28:19 readconf.c:279 STRINGA[0]=12.31.231.1
14:28:19 readconf.c:119 rounded rtp_port_high down to 7078
14:28:19 utils.c:234 running w/uid=0, euid=0, gid=0, egid=0
14:28:19 utils.c:270 changing uid/gid to root
14:28:19 utils.c:273 changed gid to 0 - Ok
14:28:19 utils.c:277 changed egid to 0 - Ok
14:28:19 utils.c:288 changed euid to 0 - Ok
14:28:19 siproxd.c:223 creating PID file [/var/run/siproxd/siproxd.pid]
14:28:19 rtpproxy_relay.c:108 create thread
14:28:19 rtpproxy_relay.c:110 created, sts=0
14:28:19 rtpproxy_relay.c:121 uid=0, euid=0
14:28:19 rtpproxy_relay.c:134 pmin=1, pmax=99, using p=33
14:28:19 INFO:sock.c:65 bound to port 5060
14:28:19 sock.c:66 bound socket 5
14:28:19 INFO:siproxd.c:263 siproxd-0.5.12-3500 i686-pc-linux-gnu started
14:28:19 siproxd.c:270 going into sipsock_wait

14:28:20 siproxd.c:296 back from sipsock_wait
14:28:20 sock.c:125 received UDP packet from 10.99.1.10, count=949
---BUFFER DUMP follows---
  49 4e 56 49 54 45 20 73 69 70 3a 36 33 30 37 37 INVITE sip:63077
  38 32 38 30 30 40 32 30 38 2e 34 39 2e 31 32 34 82800@208.49.124 
  2e 34 33 3a 35 30 36 30 20 53 49 50 2f 32 2e 30 .43:5060 SIP/2.0
  0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 ..Via: SIP/2.0/U
  44 50 20 31 30 2e 39 39 2e 31 2e 31 30 3a 35 30 DP 10.99.1.10:50
  36 30 3b 62 72 61 6e 63 68 3d 7a 39 68 47 34 62 60;branch=z9hG4b
  4b 39 37 66 65 30 37 37 0d 0a 52 65 6d 6f 74 65 K97fe077..Remote
  2d 50 61 72 74 79 2d 49 44 3a 20 22 42 72 69 61 -Party-ID: "Bria
  6e 20 46 72 65 65 6d 61 6e 22 20 3c 73 69 70 3a n Freeman" <sip:
  30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 30 3e 0286@10.99.1.10>
  3b 70 61 72 74 79 3d 63 61 6c 6c 69 6e 67 3b 73 ;party=calling;s
  63 72 65 65 6e 3d 79 65 73 3b 70 72 69 76 61 63 creen=yes;privac
  79 3d 6f 66 66 0d 0a 46 72 6f 6d 3a 20 22 42 72 y=off..From: "Br
  69 61 6e 20 46 72 65 65 6d 61 6e 22 20 3c 73 69 ian Freeman" <si
  70 3a 30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 p:0286@10.99.1.1 
  30 3e 3b 74 61 67 3d 66 39 38 65 38 61 63 31 2d 0>;tag=f98e8ac1-
  64 65 37 66 2d 34 61 32 66 2d 38 35 66 35 2d 63 de7f-4a2f-85f5-c
  38 62 36 31 39 35 38 66 38 32 38 2d 32 30 33 36 8b61958f828-2036
  32 39 30 32 0d 0a 54 6f 3a 20 3c 73 69 70 3a 36 2902..To: <sip:6
  33 30 37 37 38 32 38 30 30 40 32 30 38 2e 34 39 307782800@208.49 
  2e 31 32 34 2e 34 33 3e 0d 0a 44 61 74 65 3a 20 .124.43>..Date:
  46 72 69 2c 20 32 34 20 4d 61 72 20 32 30 30 36 Fri, 24 Mar 2006
  20 32 31 3a 32 38 3a 30 32 20 47 4d 54 0d 0a 43  21:28:02 GMT..C
  61 6c 6c 2d 49 44 3a 20 31 31 37 63 65 32 38 30 all-ID: 117ce280
  2d 34 32 34 31 36 34 36 32 2d 33 34 36 31 2d 61 -42416462-3461-a
  30 31 36 33 30 61 40 31 30 2e 39 39 2e 31 2e 31 01630a@10.99.1.1 
  30 0d 0a 53 75 70 70 6f 72 74 65 64 3a 20 74 69 0..Supported: ti
  6d 65 72 2c 72 65 70 6c 61 63 65 73 0d 0a 4d 69 mer,replaces..Mi
  6e 2d 53 45 3a 20 20 31 38 30 30 0d 0a 55 73 65 n-SE:  1800..Use
  72 2d 41 67 65 6e 74 3a 20 43 69 73 63 6f 2d 43 r-Agent: Cisco-C
  43 4d 35 2e 30 0d 0a 41 6c 6c 6f 77 3a 20 49 4e CM5.0..Allow: IN
  56 49 54 45 2c 20 4f 50 54 49 4f 4e 53 2c 20 49 VITE, OPTIONS, I
  4e 46 4f 2c 20 42 59 45 2c 20 43 41 4e 43 45 4c NFO, BYE, CANCEL
  2c 20 41 43 4b 2c 20 50 52 41 43 4b 2c 20 55 50 , ACK, PRACK, UP
  44 41 54 45 2c 20 52 45 46 45 52 2c 20 53 55 42 DATE, REFER, SUB
  53 43 52 49 42 45 2c 20 4e 4f 54 49 46 59 0d 0a SCRIBE, NOTIFY..
  43 53 65 71 3a 20 31 30 31 20 49 4e 56 49 54 45 CSeq: 101 INVITE
  0d 0a 43 6f 6e 74 61 63 74 3a 20 3c 73 69 70 3a ..Contact: <sip:
  30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 30 3a 0286@10.99.1.10: 
  35 30 36 30 3e 0d 0a 45 78 70 69 72 65 73 3a 20 5060>..Expires:
  31 38 30 0d 0a 41 6c 6c 6f 77 2d 45 76 65 6e 74 180..Allow-Event
  73 3a 20 70 72 65 73 65 6e 63 65 0d 0a 4d 61 78 s: presence..Max
  2d 46 6f 72 77 61 72 64 73 3a 20 37 30 0d 0a 43 -Forwards: 70..C
  6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 ontent-Type: app
  6c 69 63 61 74 69 6f 6e 2f 73 64 70 0d 0a 43 6f lication/sdp..Co
  6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 32 30 ntent-Length: 20
  38 0d 0a 0d 0a 76 3d 30 0d 0a 6f 3d 43 69 73 63 8....v=0..o=Cisc
  6f 53 79 73 74 65 6d 73 43 43 4d 2d 53 49 50 20 oSystemsCCM-SIP
  32 30 30 30 20 31 20 49 4e 20 49 50 34 20 31 30 2000 1 IN IP4 10
  2e 39 39 2e 31 2e 31 30 0d 0a 73 3d 53 49 50 20 .99.1.10..s=SIP
  43 61 6c 6c 0d 0a 63 3d 49 4e 20 49 50 34 20 31 Call..c=IN IP4 1
  30 2e 39 39 2e 31 2e 31 30 0d 0a 74 3d 30 20 30 0.99.1.10..t=0 0
  0d 0a 6d 3d 61 75 64 69 6f 20 32 34 38 38 32 20 ..m=audio 24882
  52 54 50 2f 41 56 50 20 30 20 31 30 31 0d 0a 61 RTP/AVP 0 101..a
  3d 72 74 70 6d 61 70 3a 30 20 50 43 4d 55 2f 38 =rtpmap:0 PCMU/8
  30 30 30 0d 0a 61 3d 70 74 69 6d 65 3a 32 30 0d 000..a=ptime:20.
  0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 65 .a=rtpmap:101 te
  6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 30 lephone-event/80
  30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 30 00..a=fmtp:101 0
  2d 31 35 0d 0a                                  -15..

---end of BUFFER DUMP---
14:28:20 accessctl.c:53 deny  list (SIP):*NULL*
14:28:20 accessctl.c:55 allow list (SIP):*NULL*
14:28:20 accessctl.c:57 allow list (REG):10.0.0.0/8
14:28:20 accessctl.c:154 [0] extracted address=10.0.0.0
14:28:20 accessctl.c:155 [0] extracted mask   =8
14:28:20 utils.c:91 initializing DNS cache (32 entries)
14:28:20 utils.c:194 DNS lookup - resolved: 10.0.0.0 -> 10.0.0.0
14:28:20 utils.c:214 DNS lookup - store into cache, entry 0)
14:28:20 accessctl.c:172 [0] (0xa000000) <-> (0xa000000)
14:28:20 accessctl.c:95 granted REG/SIP access
14:28:20 accessctl.c:102 access check =3
14:28:20 security.c:48 security_check_raw: size=949
14:28:20 siproxd.c:374 checking Max-Forwards (=70)
14:28:20 siproxd.c:419 received SIP type REQ:INVITE
14:28:20 utils.c:322 fetching interface IP by INTERFACE [0]
14:28:20 utils.c:367 initializing ifaddr cache (32 entries)
14:28:20 utils.c:432 get_ip_by_ifname: if eth1 has IP:10.100.254.73 (flags=1043) UP
14:28:20 utils.c:452 ifname lookup - store into cache, entry 0)
14:28:20 proxy.c:87 proxy_request
14:28:20 route_processing.c:63 route_preprocess: no Route header present
14:28:20 sip_utils.c:1137 sip_find_direction: unable to determine direction of SIP packet
14:28:20 INFO:proxy.c:159 Outgoing Call: 0286@10.99.1.10 -> 6307782800@208.49.124.43 
14:28:20 proxy.c:272 request [INVITE] from/to unregistered UA (RQ: 0286@10.99.1.10 -> 6307782800@208.49.124.43)
14:28:20 sock.c:164 send UDP packet to 10.99.1.10: 5060
---BUFFER DUMP follows---
  53 49 50 2f 32 2e 30 20 34 30 38 20 52 65 71 75 SIP/2.0 408 Requ
  65 73 74 20 54 69 6d 65 6f 75 74 0d 0a 56 69 61 est Timeout..Via
  3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 31 30 : SIP/2.0/UDP 10
  2e 39 39 2e 31 2e 31 30 3a 35 30 36 30 3b 62 72 .99.1.10:5060;br
  61 6e 63 68 3d 7a 39 68 47 34 62 4b 39 37 66 65 anch=z9hG4bK97fe
  30 37 37 0d 0a 46 72 6f 6d 3a 20 22 42 72 69 61 077..From: "Bria
  6e 20 46 72 65 65 6d 61 6e 22 20 3c 73 69 70 3a n Freeman" <sip:
  30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 30 3e 0286@10.99.1.10>
  3b 74 61 67 3d 66 39 38 65 38 61 63 31 2d 64 65 ;tag=f98e8ac1-de
  37 66 2d 34 61 32 66 2d 38 35 66 35 2d 63 38 62 7f-4a2f-85f5-c8b
  36 31 39 35 38 66 38 32 38 2d 32 30 33 36 32 39 61958f828-203629
  30 32 0d 0a 54 6f 3a 20 3c 73 69 70 3a 36 33 30 02..To: <sip:630
  37 37 38 32 38 30 30 40 32 30 38 2e 34 39 2e 31 7782800@208.49.1 
  32 34 2e 34 33 3e 0d 0a 43 61 6c 6c 2d 49 44 3a 24.43>..Call-ID:
  20 31 31 37 63 65 32 38 30 2d 34 32 34 31 36 34  117ce280-424164
  36 32 2d 33 34 36 31 2d 61 30 31 36 33 30 61 40 62-3461-a01630a@
  31 30 2e 39 39 2e 31 2e 31 30 0d 0a 43 53 65 71 10.99.1.10..CSeq
  3a 20 31 30 31 20 49 4e 56 49 54 45 0d 0a 43 6f : 101 INVITE..Co
  6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 30 0d ntent-Length: 0.
  0a 0d 0a                                        ...

---end of BUFFER DUMP---
14:28:20 siproxd.c:270 going into sipsock_wait

14:28:20 siproxd.c:296 back from sipsock_wait
14:28:20 sock.c:125 received UDP packet from 10.99.1.10, count=401
---BUFFER DUMP follows---
  41 43 4b 20 73 69 70 3a 36 33 30 37 37 38 32 38 ACK sip:63077828
  30 30 40 32 30 38 2e 34 39 2e 31 32 34 2e 34 33 00@208.49.124.43 
  3a 35 30 36 30 20 53 49 50 2f 32 2e 30 0d 0a 56 :5060 SIP/2.0..V
  69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 ia: SIP/2.0/UDP
  31 30 2e 39 39 2e 31 2e 31 30 3a 35 30 36 30 3b 10.99.1.10:5060;
  62 72 61 6e 63 68 3d 7a 39 68 47 34 62 4b 39 37 branch=z9hG4bK97
  66 65 30 37 37 0d 0a 46 72 6f 6d 3a 20 22 42 72 fe077..From: "Br
  69 61 6e 20 46 72 65 65 6d 61 6e 22 20 3c 73 69 ian Freeman" <si
  70 3a 30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 p:0286@10.99.1.1 
  30 3e 3b 74 61 67 3d 66 39 38 65 38 61 63 31 2d 0>;tag=f98e8ac1-
  64 65 37 66 2d 34 61 32 66 2d 38 35 66 35 2d 63 de7f-4a2f-85f5-c
  38 62 36 31 39 35 38 66 38 32 38 2d 32 30 33 36 8b61958f828-2036
  32 39 30 32 0d 0a 54 6f 3a 20 3c 73 69 70 3a 36 2902..To: <sip:6
  33 30 37 37 38 32 38 30 30 40 32 30 38 2e 34 39 307782800@208.49 
  2e 31 32 34 2e 34 33 3e 0d 0a 44 61 74 65 3a 20 .124.43>..Date:
  46 72 69 2c 20 32 34 20 4d 61 72 20 32 30 30 36 Fri, 24 Mar 2006
  20 32 31 3a 32 38 3a 30 32 20 47 4d 54 0d 0a 43  21:28:02 GMT..C
  61 6c 6c 2d 49 44 3a 20 31 31 37 63 65 32 38 30 all-ID: 117ce280
  2d 34 32 34 31 36 34 36 32 2d 33 34 36 31 2d 61 -42416462-3461-a
  30 31 36 33 30 61 40 31 30 2e 39 39 2e 31 2e 31 01630a@10.99.1.1 
  30 0d 0a 4d 61 78 2d 46 6f 72 77 61 72 64 73 3a 0..Max-Forwards:
  20 37 30 0d 0a 43 53 65 71 3a 20 31 30 31 20 41  70..CSeq: 101 A
  43 4b 0d 0a 41 6c 6c 6f 77 2d 45 76 65 6e 74 73 CK..Allow-Events
  3a 20 70 72 65 73 65 6e 63 65 0d 0a 43 6f 6e 74 : presence..Cont
  65 6e 74 2d 4c 65 6e 67 74 68 3a 20 30 0d 0a 0d ent-Length: 0...
  0a                                              .

---end of BUFFER DUMP---
14:28:20 accessctl.c:53 deny  list (SIP):*NULL*
14:28:20 accessctl.c:55 allow list (SIP):*NULL*
14:28:20 accessctl.c:57 allow list (REG):10.0.0.0/8
14:28:20 accessctl.c:154 [0] extracted address=10.0.0.0
14:28:20 accessctl.c:155 [0] extracted mask   =8
14:28:20 utils.c:114 DNS lookup - from cache: 10.0.0.0 -> 10.0.0.0
14:28:20 accessctl.c:172 [0] (0xa000000) <-> (0xa000000)
14:28:20 accessctl.c:95 granted REG/SIP access
14:28:20 accessctl.c:102 access check =3
14:28:20 security.c:48 security_check_raw: size=401
14:28:20 siproxd.c:374 checking Max-Forwards (=70)
14:28:20 siproxd.c:419 received SIP type REQ:ACK
14:28:20 utils.c:322 fetching interface IP by INTERFACE [0]
14:28:20 utils.c:394 ifaddr lookup - from cache: eth1 -> 10.100.254.73 UP
14:28:20 proxy.c:87 proxy_request
14:28:20 route_processing.c:63 route_preprocess: no Route header present
14:28:20 sip_utils.c:1137 sip_find_direction: unable to determine direction of SIP packet
14:28:20 INFO:proxy.c:159 ACK Call: 0286@10.99.1.10 -> 6307782800@208.49.124.43 
14:28:20 proxy.c:272 request [ACK] from/to unregistered UA (RQ: 0286@10.99.1.10 -> 6307782800@208.49.124.43)
14:28:20 sock.c:164 send UDP packet to 10.99.1.10: 5060
---BUFFER DUMP follows---
  53 49 50 2f 32 2e 30 20 34 30 38 20 52 65 71 75 SIP/2.0 408 Requ
  65 73 74 20 54 69 6d 65 6f 75 74 0d 0a 56 69 61 est Timeout..Via
  3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 31 30 : SIP/2.0/UDP 10
  2e 39 39 2e 31 2e 31 30 3a 35 30 36 30 3b 62 72 .99.1.10:5060;br
  61 6e 63 68 3d 7a 39 68 47 34 62 4b 39 37 66 65 anch=z9hG4bK97fe
  30 37 37 0d 0a 46 72 6f 6d 3a 20 22 42 72 69 61 077..From: "Bria
  6e 20 46 72 65 65 6d 61 6e 22 20 3c 73 69 70 3a n Freeman" <sip:
  30 32 38 36 40 31 30 2e 39 39 2e 31 2e 31 30 3e 0286@10.99.1.10>
  3b 74 61 67 3d 66 39 38 65 38 61 63 31 2d 64 65 ;tag=f98e8ac1-de
  37 66 2d 34 61 32 66 2d 38 35 66 35 2d 63 38 62 7f-4a2f-85f5-c8b
  36 31 39 35 38 66 38 32 38 2d 32 30 33 36 32 39 61958f828-203629
  30 32 0d 0a 54 6f 3a 20 3c 73 69 70 3a 36 33 30 02..To: <sip:630
  37 37 38 32 38 30 30 40 32 30 38 2e 34 39 2e 31 7782800@208.49.1 
  32 34 2e 34 33 3e 0d 0a 43 61 6c 6c 2d 49 44 3a 24.43>..Call-ID:
  20 31 31 37 63 65 32 38 30 2d 34 32 34 31 36 34  117ce280-424164
  36 32 2d 33 34 36 31 2d 61 30 31 36 33 30 61 40 62-3461-a01630a@
  31 30 2e 39 39 2e 31 2e 31 30 0d 0a 43 53 65 71 10.99.1.10..CSeq
  3a 20 31 30 31 20 41 43 4b 0d 0a 43 6f 6e 74 65 : 101 ACK..Conte
  6e 74 2d 4c 65 6e 67 74 68 3a 20 30 0d 0a 0d 0a nt-Length: 0....

---end of BUFFER DUMP---
14:28:20 siproxd.c:270 going into sipsock_wait

14:28:22 register.c:492 sip_agemap, t=1143235702
14:28:24 register.c:492 sip_agemap, t=1143235704
14:28:26 sock.c:96 select() returned error [4:Interrupted system call]
14:28:26 register.c:492 sip_agemap, t=1143235706
14:28:26 INFO:siproxd.c:548 properly terminating siproxd
14:28:26 siproxd.c:552 deleting PID file [/var/run/siproxd/siproxd.pid]
14:28:26 rtpproxy_relay.c:848 killed RTP proxy thread

Re: [Siproxd-users] simultaneous calls?

[Thomas R. <tr...@gm...>]

yes.

On 24 Mar, Mario Doering wrote:
> Hello,
> 
> is it possible to have multiple incoming and outgoing calls at the same
> time?
> 
> regards,
> Mario.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

[Siproxd-users] simultaneous calls?

[Mario D. <ma...@de...>]

Hello,

is it possible to have multiple incoming and outgoing calls at the same
time?

regards,
Mario.

Re: [Siproxd-users] Problem with siproxd not rewriting request URI

[Thomas R. <tr...@gm...>]

Hello Michael,

Thanks for the feedback. All this sounds logical to me. I just wonder
why I didn't implement it then... Maybe I have to read through the RFC
again. I can't remember a specific reason why I did not do it.
Anyhow, I'll integrate you changes, Thanks a lot.


Regards,
/Thomas

On  2 Feb, Michael Procter wrote:
> 
> Thomas Ries wrote:
>> 
>> I'd really like to have more details to see what is going on exactly.
>> Especially the whole SIP communication in front and after siproxd.
>> 
>> Don't you have the chance to ask the admin of the machine to 
>> assist you
>> to record a debug log? Do you have the chance to reproduce this effect
>> on a machine that you have under control? You should also try with the
>> latest snapshot of siproxd.
>> 
> 
> I am the admin of the machine in question.  I updated to the 02Feb2006
> snapshot this morning, and the problem remained.  I've looked a little
> further and come up with a fix.  The problem seemed to be in the
> function
> proxy_rewrite_request_uri, in that it only rewrote 2 of the 4 components
> of the uri.  Rewriting the 'username' component made it work, but I
> added
> rewriting of the scheme too, just for completeness.
> 
> Regards,
> 
> Michael Procter
> 
> 
> 
> *** siproxd-0.5.12-snapshot-02Feb20006-orig/src/proxy.c  2006-01-01
> 20:31:54.000000000 +0000
> --- siproxd-0.5.12-snapshot-02Feb2006/src/proxy.c       2006-02-02
> 10:34:02.000000000 +0000
> ***************
> *** 1122,1127 ****
> --- 1122,1129 ----
>    *    STS_SUCCESS on success
>    */
>   int proxy_rewrite_request_uri(osip_message_t *mymsg, int idx){
> +    char *scheme;
> +    char *username;
>      char *host;
>      char *port;
>      osip_uri_t *url;
> ***************
> *** 1134,1139 ****
> --- 1136,1163 ----
>      DEBUGC(DBCLASS_PROXY,"rewriting incoming Request URI");
>      url=osip_message_get_uri(mymsg);
> 
> +    /* set the true scheme */
> +    if (url->scheme) osip_free(url->scheme);url->scheme=NULL;
> +    if (urlmap[idx].true_url->scheme) {
> +       DEBUGC(DBCLASS_BABBLE,"proxy_rewrite_request_uri: scheme=%s",
> +              urlmap[idx].true_url->scheme);
> +       scheme = (char *)malloc(strlen(urlmap[idx].true_url->scheme)+1);
> +       memcpy(scheme, urlmap[idx].true_url->scheme,
> strlen(urlmap[idx].true_url->scheme));
> +       scheme[strlen(urlmap[idx].true_url->scheme)]='\0';
> +       osip_uri_set_scheme(url, scheme);
> +    }
> +
> +    /* set the true username */
> +    if (url->username) osip_free(url->username);url->username=NULL;
> +    if (urlmap[idx].true_url->username) {
> +       DEBUGC(DBCLASS_BABBLE,"proxy_rewrite_request_uri: username=%s",
> +              urlmap[idx].true_url->username);
> +       username = (char
> *)malloc(strlen(urlmap[idx].true_url->scheme)+1);
> +       memcpy(username, urlmap[idx].true_url->username,
> strlen(urlmap[idx].true_url->username));
> +       username[strlen(urlmap[idx].true_url->username)]='\0';
> +       osip_uri_set_username(url, username);
> +    }
> +
>      /* set the true host */
>      if (url->host) osip_free(url->host);url->host=NULL;
>      if (urlmap[idx].true_url->host) {
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

RE: [Siproxd-users] Problem with siproxd not rewriting request URI

[Michael P. <mic...@ci...>]

Thomas Ries wrote:
>=20
> I'd really like to have more details to see what is going on exactly.
> Especially the whole SIP communication in front and after siproxd.
>=20
> Don't you have the chance to ask the admin of the machine to=20
> assist you
> to record a debug log? Do you have the chance to reproduce this effect
> on a machine that you have under control? You should also try with the
> latest snapshot of siproxd.
>=20

I am the admin of the machine in question.  I updated to the 02Feb2006
snapshot this morning, and the problem remained.  I've looked a little
further and come up with a fix.  The problem seemed to be in the
function
proxy_rewrite_request_uri, in that it only rewrote 2 of the 4 components
of the uri.  Rewriting the 'username' component made it work, but I
added
rewriting of the scheme too, just for completeness.

Regards,

Michael Procter



*** siproxd-0.5.12-snapshot-02Feb20006-orig/src/proxy.c  2006-01-01
20:31:54.000000000 +0000
--- siproxd-0.5.12-snapshot-02Feb2006/src/proxy.c       2006-02-02
10:34:02.000000000 +0000
***************
*** 1122,1127 ****
--- 1122,1129 ----
   *    STS_SUCCESS on success
   */
  int proxy_rewrite_request_uri(osip_message_t *mymsg, int idx){
+    char *scheme;
+    char *username;
     char *host;
     char *port;
     osip_uri_t *url;
***************
*** 1134,1139 ****
--- 1136,1163 ----
     DEBUGC(DBCLASS_PROXY,"rewriting incoming Request URI");
     url=3Dosip_message_get_uri(mymsg);

+    /* set the true scheme */
+    if (url->scheme) osip_free(url->scheme);url->scheme=3DNULL;
+    if (urlmap[idx].true_url->scheme) {
+       DEBUGC(DBCLASS_BABBLE,"proxy_rewrite_request_uri: scheme=3D%s",
+              urlmap[idx].true_url->scheme);
+       scheme =3D (char =
*)malloc(strlen(urlmap[idx].true_url->scheme)+1);
+       memcpy(scheme, urlmap[idx].true_url->scheme,
strlen(urlmap[idx].true_url->scheme));
+       scheme[strlen(urlmap[idx].true_url->scheme)]=3D'\0';
+       osip_uri_set_scheme(url, scheme);
+    }
+
+    /* set the true username */
+    if (url->username) osip_free(url->username);url->username=3DNULL;
+    if (urlmap[idx].true_url->username) {
+       DEBUGC(DBCLASS_BABBLE,"proxy_rewrite_request_uri: =
username=3D%s",
+              urlmap[idx].true_url->username);
+       username =3D (char
*)malloc(strlen(urlmap[idx].true_url->scheme)+1);
+       memcpy(username, urlmap[idx].true_url->username,
strlen(urlmap[idx].true_url->username));
+       username[strlen(urlmap[idx].true_url->username)]=3D'\0';
+       osip_uri_set_username(url, username);
+    }
+
     /* set the true host */
     if (url->host) osip_free(url->host);url->host=3DNULL;
     if (urlmap[idx].true_url->host) {

Re: [Siproxd-users] Problem with siproxd not rewriting request URI

[Thomas R. <tr...@gm...>]

I'd really like to have more details to see what is going on exactly.
Especially the whole SIP communication in front and after siproxd.

Don't you have the chance to ask the admin of the machine to assist you
to record a debug log? Do you have the chance to reproduce this effect
on a machine that you have under control? You should also try with the
latest snapshot of siproxd.

Regards,

/Thomas



On  1 Feb, Steve Langstaff wrote:
> I have a problem with an installation of siproxd not rewriting a request URI correctly.
> 
> I'm not sure of the version number of siproxd - I don't administer the server - but it's from the back end of 2005.
> 
> The problem that I am seeing is that I can register a contact address correctly, but the incoming INVITE URI is not rewritten to be the contact address, as the following packet fragments show:
> 
> Here is my request to the registrar, before hitting siproxd:
> 
> <--- REGISTER sip:service.provider.com SIP/2.0
> 
>         To: sip:12...@se...
>         From: sip:12...@se...
>         Contact: sip:line1@192.168.1.1:5065;expires=3600
> 
> And here is the response:
> 
> ---> SIP/2.0 200 OK
> 
>         From: <sip:12...@se...>
>         To: <sip:12...@se...>;tag=something
>         Contact: <sip:line1@192.168.1.1:5065>;q=0.00;expires=3600
> 
> So now siproxd knows that to reach sip:12...@se... it should rewrite message URIs to sip:line1@192.168.1.1:5065.
> 
> Now, here is a call coming in to sip:12...@se......
> 
> ---> INVITE sip:123456@192.168.1.1:5065 SIP/2.0
> 
> To which my UA responds:
> 
> <--- SIP/2.0 404 Not Found
> 
> Shouldn't the invite have come in with the following instead?
> 
> ---> INVITE sip:line1@192.168.1.1:5065 SIP/2.0
> 
> It looks like siproxd rewrote the host:port part of the URI but not the user part.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

[Siproxd-users] Problem with siproxd not rewriting request URI

[Steve L. <ste...@ci...>]

I have a problem with an installation of siproxd not rewriting a request =
URI correctly.

I'm not sure of the version number of siproxd - I don't administer the =
server - but it's from the back end of 2005.

The problem that I am seeing is that I can register a contact address =
correctly, but the incoming INVITE URI is not rewritten to be the =
contact address, as the following packet fragments show:

Here is my request to the registrar, before hitting siproxd:

<--- REGISTER sip:service.provider.com SIP/2.0

        To: sip:12...@se...
        From: sip:12...@se...
        Contact: sip:line1@192.168.1.1:5065;expires=3D3600

And here is the response:

---> SIP/2.0 200 OK

        From: <sip:12...@se...>
        To: <sip:12...@se...>;tag=3Dsomething
        Contact: <sip:line1@192.168.1.1:5065>;q=3D0.00;expires=3D3600

So now siproxd knows that to reach sip:12...@se... it =
should rewrite message URIs to sip:line1@192.168.1.1:5065.

Now, here is a call coming in to sip:12...@se......

---> INVITE sip:123456@192.168.1.1:5065 SIP/2.0

To which my UA responds:

<--- SIP/2.0 404 Not Found

Shouldn't the invite have come in with the following instead?

---> INVITE sip:line1@192.168.1.1:5065 SIP/2.0

It looks like siproxd rewrote the host:port part of the URI but not the =
user part.

Re: [Siproxd-users] Is there a way to get detailed sip message logs?

[Li S. <w1...@gm...>]

Didn't know this ngrep before. This tool is cool.

Thanks,
Stephen


On 1/16/06, Henning Verbeek <ha...@pr...> wrote:
>
> Hmm, you could just run
> ngrep port 5060
> in the background...
>
> Cheers, Hank
>
> Li Stephen <w1...@gm...> wrote:
>
> > Hello,
> >
> > With Siemens SIP proxy, I can easily get very detailed SIP message log,
> > which is very useful for debugging and testing. I just setup Siproxd,
> seems
> > it print brief messages. Is there a way to get detailed content of SIP
> > message logs?
> >
> > Thanks,
> > Stephen
> >
>
> --
> http://www.pray4snow.de
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>

Re: [Siproxd-users] Is there a way to get detailed sip message logs?

[Li S. <w1...@gm...>]

Yeah - I misread the comments in the config sample. Thanks for the help.

Stephen


On 1/16/06, Thomas Ries <tr...@gm...> wrote:
>
> Hi,
>
> debuglevel =3D -1
>
> will give you full output. IF you are only looking in/outgoing
> network data:
>
> debuglevel =3D 128
>
> /Thomas
>
>
> On 15 Jan, Li Stephen wrote:
> > Hello,
> >
> > With Siemens SIP proxy, I can easily get very detailed SIP message log,
> > which is very useful for debugging and testing. I just setup Siproxd,
> seems
> > it print brief messages. Is there a way to get detailed content of SIP
> > message logs?
> >
> > Thanks,
> > Stephen
>
> --
> GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
> -      Fingerprint =3D 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
> -      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
> VoIP:  sip:174...@pr... | sip:43...@fw...
>
>

Re: [Siproxd-users] Is there a way to get detailed sip message logs?

[Thomas R. <tr...@gm...>]

Hi,

debuglevel = -1

will give you full output. IF you are only looking in/outgoing
network data:

debuglevel = 128

/Thomas


On 15 Jan, Li Stephen wrote:
> Hello,
> 
> With Siemens SIP proxy, I can easily get very detailed SIP message log,
> which is very useful for debugging and testing. I just setup Siproxd, seems
> it print brief messages. Is there a way to get detailed content of SIP
> message logs?
> 
> Thanks,
> Stephen

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

Re: [Siproxd-users] Is there a way to get detailed sip message logs?

[Henning V. <ha...@pr...>]

Hmm, you could just run
  ngrep port 5060
in the background...

Cheers, Hank

Li Stephen <w1...@gm...> wrote:

> Hello,
> 
> With Siemens SIP proxy, I can easily get very detailed SIP message log,
> which is very useful for debugging and testing. I just setup Siproxd, seems
> it print brief messages. Is there a way to get detailed content of SIP
> message logs?
> 
> Thanks,
> Stephen
> 

--
http://www.pray4snow.de
 

[Siproxd-users] Is there a way to get detailed sip message logs?

[Li S. <w1...@gm...>]

Hello,

With Siemens SIP proxy, I can easily get very detailed SIP message log,
which is very useful for debugging and testing. I just setup Siproxd, seems
it print brief messages. Is there a way to get detailed content of SIP
message logs?

Thanks,
Stephen

[Siproxd-users] DNS resolution in chroot jail

[Michael P. <mic...@ci...>]

I'm running siproxd snapshot from 4th October, and was testing the
'multiple contact handling' in sip_rewrite_contact.  During my testing,
I found another problem, this time associated with DNS resolution.  I
think I may have updated something on my system to break it, as I don't
think you have changed it between these releases.

The problem is that once chrooted, siproxd cannot resolve DNS names.  I
can see in utils.c:secure_environment() that you perform a lookup of
'localhost' before chrooting, to fix this problem.  But for me, it
doesn't.  I added an additional line, just after the lookup of
'localhost', and before the chroot, of the form:

	get_ip_by_host("www.google.com", &dummy);

which made it work as I expect.

I think the problem is that 'localhost' can be looked up without
resorting to a remote DNS lookup, so all the relevant libraries are not
installed before the call to chroot.

I did an 'strace' of siproxd starting up, and here is an extract of the
work done between looking up 'localhost' and looking up
'www.google.com'.

time([1129723469])                      =3D 1129723469
write(2, "13:04:29 utils.c:194 ", 2113:04:29 utils.c:194 )   =3D 21
write(2, "DNS lookup - resolved: localhost"..., 45DNS lookup - resolved:
localhost -> 127.0.0.1) =3D 45
write(2, "\n", 1
)                       =3D 1
time([1129723469])                      =3D 1129723469
write(2, "13:04:29 utils.c:214 ", 2113:04:29 utils.c:214 )   =3D 21
write(2, "DNS lookup - store into cache, e"..., 39DNS lookup - store
into cache, entry 0)) =3D 39
write(2, "\n", 1
)                       =3D 1
time([1129723469])                      =3D 1129723469
time([1129723469])                      =3D 1129723469
open("/etc/hosts", O_RDONLY)            =3D 4
fcntl64(4, F_GETFD)                     =3D 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D217, ...}) =3D 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) =3D 0x40017000
read(4, "127.0.0.1 localhost.localdomain "..., 4096) =3D 217
read(4, "", 4096)                       =3D 0
close(4)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/ld.so.cache", O_RDONLY)      =3D 4
fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D57385, ...}) =3D 0
old_mmap(NULL, 57385, PROT_READ, MAP_PRIVATE, 4, 0) =3D 0x40017000
close(4)                                =3D 0
access("/etc/ld.so.nohwcap", F_OK)      =3D -1 ENOENT (No such file or
directory)
open("/lib/libnss_dns.so.2", O_RDONLY)  =3D 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\r\0"...,
512) =3D 512
fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D17840, ...}) =3D 0
old_mmap(NULL, 20616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) =3D 0x40217000
old_mmap(0x4021b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x3000) =3D 0x4021b000
close(4)                                =3D 0
munmap(0x40017000, 57385)               =3D 0
gettimeofday({1129723469, 797825}, NULL) =3D 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) =3D 4
connect(4, {sa_family=3DAF_INET, sin_port=3Dhtons(53),
sin_addr=3Dinet_addr("10.7.1.2")}, 28) =3D 0
fcntl64(4, F_GETFL)                     =3D 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  =3D 0
gettimeofday({1129723469, 798933}, NULL) =3D 0
poll([{fd=3D4, events=3DPOLLOUT, revents=3DPOLLOUT}], 1, 0) =3D 1
send(4, "\340\333\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\1\0"..., 32,
0) =3D 32
poll([{fd=3D4, events=3DPOLLIN, revents=3DPOLLIN}], 1, 5000) =3D 1
ioctl(4, FIONREAD, [100])               =3D 0
recvfrom(4, "\340\333\201\200\0\1\0\4\0\0\0\0\3www\6google\3com\0\0"...,
1024, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(53),
sin_addr=3Dinet_addr("10.7.1.2")}, [16]) =3D 100
close(4)                                =3D 0
time([1129723470])                      =3D 1129723470
write(2, "13:04:30 utils.c:194 ", 2113:04:30 utils.c:194 )   =3D 21
write(2, "DNS lookup - resolved: www.googl"..., 52DNS lookup - resolved:
www.google.com -> 66.102.9.99) =3D 52
write(2, "\n", 1
)                       =3D 1
time([1129723470])                      =3D 1129723470
write(2, "13:04:30 utils.c:214 ", 2113:04:30 utils.c:214 )   =3D 21
write(2, "DNS lookup - store into cache, e"..., 39DNS lookup - store
into cache, entry 1)) =3D 39
write(2, "\n", 1
)                       =3D 1
time([1129723470])                      =3D 1129723470
time([1129723470])                      =3D 1129723470
write(2, "13:04:30 utils.c:259 ", 2113:04:30 utils.c:259 )   =3D 21
write(2, "chrooting to /var/lib/siproxd/", 30chrooting to
/var/lib/siproxd/) =3D 30


This suggests to me that an additional library is pulled in for remote
lookups, and also that hosts only listed in /etc/hosts will not be
visible after the chroot, unless you create a new /etc/hosts within the
chroot jail, or hardlink to the existing one.

I suppose you could also hardlink the libraries that it needs into the
right place within the chroot jail to get this to work too, rather than
forcing a lookup of an address that won't be resolved locally.  And this
might be the better solution - setting up the chroot jail so that all
the relevant libraries are available.

Regards,

Michael Procter

Re: [Siproxd-users] Bug in sip_rewrite_contact()

[Thomas R. <tr...@gm...>]

Hi Michael,

This should be fixed in the latest snapshot.

Regards,
/Thomas

On 18 Aug, Michael Procter wrote:
> Hi,
> 
> I have been trying to use siproxd in association with Free World Dialup,
> just as an outbound proxy, and it normally works.  But I have found one
> failure case concerning registration.
> 
> FWD supports several endpoints registering for the same number at the
> same time.  When I register a new endpoint, the 200 response contains
> a list of all currently registered contacts, and this is where the
> problem lies.
> 
> sip_rewrite_contact attempts to translate the contact back to the
> 'true url', but it only does this for the first contact listed in the
> message.  As it happens, I needed it to translate the 2nd contact in a
> list of 3 contacts.
> 
> Because this translation doesn't take place, my User Agent thinks that
> the registration has failed, since it can't find itself on the list of
> registered contacts.
> 
> Regards,
> 
> Michael Procter
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

Re: [Siproxd-users] Need for help, siproxd does not work well....@@...

[Thomas R. <tr...@gm...>]

Hi Samlee


The "rtp_proxy_enable" *must* be set to 1. This configuration option is
a relict from earlier versions of siproxd. Set to 0, siproxd will NOT
perform any RTP traffic forwarding.
Please set to 1 and try again. The rest of your setup looks ok to me.


Regards,
/Thomas

On 26 Aug, Samlee wrote:
> Dear all:
> 
>            Sorry, I am a newbie of siproxd, and have some problem when using
> siproxd...
> 
> The architecture is following:
> 
> private IP address range             :          Internet public IP address
> range
> 
>    192.168.2.1                          :          10.90.8.40
> 
>                                         :
> 
>    192.168.2.91                         :  foo.bar.org          10.90.8.185
> 
>    +-------------+             +--------------+              +-------------+
> 
>    !             !          .1 ! masquerading ! publicIP     !             !
> 
>    ! IntHost     !-------------! Firewall     !------------>>! externalHost!
> 
>    !             !         eth2!              !eth1          !             !
> 
>    +-------------+             +--------------+              +-------------+
> 
>    user: 1111                                                user: 2222
> 
> Both of user 1111 and user 2222 are registered to siproxd, and 
> 
> I want to make a call from "1111" to "2222" and make a call from "2222" to
> "1111".
> 
>  
> 
>        I installed siproxd into a machine with two network interfaces: eth1
> (public IP address, but we use 10.90.8.40 for simulation), eth2 (private IP
> address, 192.168.2.1). 
> 
> To enable NAT, I executed following commands:
> 
> 1. iptables -A INPUT -i eth2 -j ACCEPT
> 
> 2. echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> 3. iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth1 -j MASQUERADE
> 
> Then execute 
> 
> 1. iptables -A INPUT -i eth1 -p udp -m udp --dport 5060 -j ACCEPT
> 
> 2. iptables -A INPUT -i eth1 -p udp -m udp --dport 2:65000 -j ACCEPT
> 
> to receive SIP and RTP message from eth1.
> 
> Finally execute "siproxd".
> 
> My configuration is following:
> 
> # The interface names of INBOUND and OUTBOUND interface.####
> 
> if_inbound  = eth2
> 
> if_outbound = eth1
> 
> host_outbound = 10.90.8.40
> 
>  
> 
> # Access control.#
> 
> hosts_allow_reg = 192.168.2.0/24,10.90.8.0/24
> 
> hosts_allow_sip = 192.168.2.0/24,10.90.8.0/24
> 
>  
> 
> # Port to listen for incoming SIP messages.#
> 
> sip_listen_port = 5060
> 
>  
> 
> # Shall we daemonize?#
> 
> daemonize = 0
> 
>  
> 
> # What shall I log to syslog?#
> 
> silence_log = 0
> 
>  
> 
> # Shall I log call establishment to syslog?#
> 
> log_calls = 1
> 
>  
> 
> # Secure Enviroment settings:#
> 
> user = root
> 
>  
> 
> # Registration file:#
> 
> registration_file = /usr/local/sipproxd/etc/siproxd_registrations
> 
>  
> 
> # Automatically save current registrations every 'n' seconds#
> 
> autosave_registrations = 300
> 
>  
> 
> # PID file:#
> 
> pid_file = /usr/local/sipproxd/etc/siproxd.pid
> 
>  
> 
> # global switch to control the RTP proxy behaviour#
> 
> rtp_proxy_enable = 0
> 
>  
> 
> # Port range to allocate listen ports from for incoming RTP traffic
> 
> rtp_port_low  = 2
> 
> rtp_port_high = 65000
> 
>  
> 
> # Timeout for RTP streams#
> 
> rtp_timeout = 300
> 
>  
> 
> # Default Expiration timeout for Registrations#
> 
> default_expires = 600
> 
>  
> 
> # Proxy authentication#
> 
> proxy_auth_pwfile = usr/local/sipproxd/etc/siproxd_passwd.cfg
> 
>  
> 
> # Debug level... (setting to -1 will enable everything)#
> 
> debug_level =      0x00000000
> 
>  
> 
> But when 1111 makes a call to 2222 , the call is failed. 2222 is ringing,
> but when taking the call, 1111 will send CANCEL message..@@
> 
> When 2222 makes a call to 1111, the signaling is OK , but there is only one
> way RTP from 1111 to 2222.@@
> 
>  
> 
> Is it something wrong of the configuration file? Or the NAT setting ? .. @@
> , please help, Thank you 
> 
>  
> 
> Best Regards,
> 
> sam
> 
>  
> 

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

Re: [Siproxd-users] Need for help, siproxd does not work well....@@...

[Thomas R. <tr...@gm...>]

Just saw something else:

Please don't use a rtp_port range from 5 to 65000. Siproxd will try to
use also the "low port range" that usually is used for "well known
services" and the port range above ~30000 which (depending of you Linux)
is used for masquerading). It *might* work, but I'd not be surprised if
funny things start to happen.
Stay with the port range as provided in the sample configuration file
(7070-7089).

/Thomas




On 26 Aug, Samlee wrote:
> Dear all:
> 
>            Sorry, I am a newbie of siproxd, and have some problem when using
> siproxd...
> 
> The architecture is following:
> 
> private IP address range             :          Internet public IP address
> range
> 
>    192.168.2.1                          :          10.90.8.40
> 
>                                         :
> 
>    192.168.2.91                         :  foo.bar.org          10.90.8.185
> 
>    +-------------+             +--------------+              +-------------+
> 
>    !             !          .1 ! masquerading ! publicIP     !             !
> 
>    ! IntHost     !-------------! Firewall     !------------>>! externalHost!
> 
>    !             !         eth2!              !eth1          !             !
> 
>    +-------------+             +--------------+              +-------------+
> 
>    user: 1111                                                user: 2222
> 
> Both of user 1111 and user 2222 are registered to siproxd, and 
> 
> I want to make a call from "1111" to "2222" and make a call from "2222" to
> "1111".
> 
>  
> 
>        I installed siproxd into a machine with two network interfaces: eth1
> (public IP address, but we use 10.90.8.40 for simulation), eth2 (private IP
> address, 192.168.2.1). 
> 
> To enable NAT, I executed following commands:
> 
> 1. iptables -A INPUT -i eth2 -j ACCEPT
> 
> 2. echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> 3. iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth1 -j MASQUERADE
> 
> Then execute 
> 
> 1. iptables -A INPUT -i eth1 -p udp -m udp --dport 5060 -j ACCEPT
> 
> 2. iptables -A INPUT -i eth1 -p udp -m udp --dport 2:65000 -j ACCEPT
> 
> to receive SIP and RTP message from eth1.
> 
> Finally execute "siproxd".
> 
> My configuration is following:
> 
> # The interface names of INBOUND and OUTBOUND interface.####
> 
> if_inbound  = eth2
> 
> if_outbound = eth1
> 
> host_outbound = 10.90.8.40
> 
>  
> 
> # Access control.#
> 
> hosts_allow_reg = 192.168.2.0/24,10.90.8.0/24
> 
> hosts_allow_sip = 192.168.2.0/24,10.90.8.0/24
> 
>  
> 
> # Port to listen for incoming SIP messages.#
> 
> sip_listen_port = 5060
> 
>  
> 
> # Shall we daemonize?#
> 
> daemonize = 0
> 
>  
> 
> # What shall I log to syslog?#
> 
> silence_log = 0
> 
>  
> 
> # Shall I log call establishment to syslog?#
> 
> log_calls = 1
> 
>  
> 
> # Secure Enviroment settings:#
> 
> user = root
> 
>  
> 
> # Registration file:#
> 
> registration_file = /usr/local/sipproxd/etc/siproxd_registrations
> 
>  
> 
> # Automatically save current registrations every 'n' seconds#
> 
> autosave_registrations = 300
> 
>  
> 
> # PID file:#
> 
> pid_file = /usr/local/sipproxd/etc/siproxd.pid
> 
>  
> 
> # global switch to control the RTP proxy behaviour#
> 
> rtp_proxy_enable = 0
> 
>  
> 
> # Port range to allocate listen ports from for incoming RTP traffic
> 
> rtp_port_low  = 2
> 
> rtp_port_high = 65000
> 
>  
> 
> # Timeout for RTP streams#
> 
> rtp_timeout = 300
> 
>  
> 
> # Default Expiration timeout for Registrations#
> 
> default_expires = 600
> 
>  
> 
> # Proxy authentication#
> 
> proxy_auth_pwfile = usr/local/sipproxd/etc/siproxd_passwd.cfg
> 
>  
> 
> # Debug level... (setting to -1 will enable everything)#
> 
> debug_level =      0x00000000
> 
>  
> 
> But when 1111 makes a call to 2222 , the call is failed. 2222 is ringing,
> but when taking the call, 1111 will send CANCEL message..@@
> 
> When 2222 makes a call to 1111, the signaling is OK , but there is only one
> way RTP from 1111 to 2222.@@
> 
>  
> 
> Is it something wrong of the configuration file? Or the NAT setting ? .. @@
> , please help, Thank you 
> 
>  
> 
> Best Regards,
> 
> sam
> 
>  
> 

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

Re: [Siproxd-users] Bug in sip_rewrite_contact()

[Thomas R. <tr...@gm...>]

Hi Michael,

This issue is currently beeing worked on. I hope to have a solution
within the next few days.

Regards,
/Thomas

On 18 Aug, Michael Procter wrote:
> Hi,
> 
> I have been trying to use siproxd in association with Free World Dialup,
> just as an outbound proxy, and it normally works.  But I have found one
> failure case concerning registration.
> 
> FWD supports several endpoints registering for the same number at the
> same time.  When I register a new endpoint, the 200 response contains
> a list of all currently registered contacts, and this is where the
> problem lies.
> 
> sip_rewrite_contact attempts to translate the contact back to the
> 'true url', but it only does this for the first contact listed in the
> message.  As it happens, I needed it to translate the 2nd contact in a
> list of 3 contacts.
> 
> Because this translation doesn't take place, my User Agent thinks that
> the registration has failed, since it can't find itself on the list of
> registered contacts.
> 
> Regards,
> 
> Michael Procter
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

-- 
GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
-      Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
-      Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP:  sip:174...@pr... | sip:43...@fw...

[Siproxd-users] Transparent proxy config

[Alexandre A. <aar...@gm...>]

Hi all, I'm new to siproxd, I wanted to test the transparent proxy
config (as found in the online doc). But between a public machine and a
remote LAN, as explained below:


+-------------+                   +--------------+
!             !publicIP  publicIP ! masquerading ! publicIP                =
 Remote LAN
! SIP GW      !-------------------! Firewall     !------>>  (IP tunnel) ---=
 10.x.x.x
!             !                   ! siproxd      !
+-------------+                   +--------------+
                                  eth2   :  eth3


The SIP GW sends INVITEs to a SIP server via my masquerading firewall
through the public Internet. When the call gets established I'd like
siproxd to relay the RTP between the private (remote) LAN and the public
GW.

With the example config, I get "Outgoing Call from:
*NULL*@212.62.110.65" errors when my public GW (212.62.110.65) tries to
send INVITEs to the server behind the firewall.=20

Is my config possible? How can I do it with siproxd?
Thanks a lot for your help!

--=20
Alexandre Aractingi <aar...@gm...>

[Siproxd-users] Need for help, siproxd does not work well....@@...

[Samlee <sa...@pt...>]

Dear all:

           Sorry, I am a newbie of siproxd, and have some problem when using
siproxd...

The architecture is following:

private IP address range             :          Internet public IP address
range

   192.168.2.1                          :          10.90.8.40

                                        :

   192.168.2.91                         :  foo.bar.org          10.90.8.185

   +-------------+             +--------------+              +-------------+

   !             !          .1 ! masquerading ! publicIP     !             !

   ! IntHost     !-------------! Firewall     !------------>>! externalHost!

   !             !         eth2!              !eth1          !             !

   +-------------+             +--------------+              +-------------+

   user: 1111                                                user: 2222

Both of user 1111 and user 2222 are registered to siproxd, and 

I want to make a call from "1111" to "2222" and make a call from "2222" to
"1111".

 

       I installed siproxd into a machine with two network interfaces: eth1
(public IP address, but we use 10.90.8.40 for simulation), eth2 (private IP
address, 192.168.2.1). 

To enable NAT, I executed following commands:

1. iptables -A INPUT -i eth2 -j ACCEPT

2. echo "1" > /proc/sys/net/ipv4/ip_forward

3. iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth1 -j MASQUERADE

Then execute 

1. iptables -A INPUT -i eth1 -p udp -m udp --dport 5060 -j ACCEPT

2. iptables -A INPUT -i eth1 -p udp -m udp --dport 2:65000 -j ACCEPT

to receive SIP and RTP message from eth1.

Finally execute "siproxd".

My configuration is following:

# The interface names of INBOUND and OUTBOUND interface.####

if_inbound  = eth2

if_outbound = eth1

host_outbound = 10.90.8.40

 

# Access control.#

hosts_allow_reg = 192.168.2.0/24,10.90.8.0/24

hosts_allow_sip = 192.168.2.0/24,10.90.8.0/24

 

# Port to listen for incoming SIP messages.#

sip_listen_port = 5060

 

# Shall we daemonize?#

daemonize = 0

 

# What shall I log to syslog?#

silence_log = 0

 

# Shall I log call establishment to syslog?#

log_calls = 1

 

# Secure Enviroment settings:#

user = root

 

# Registration file:#

registration_file = /usr/local/sipproxd/etc/siproxd_registrations

 

# Automatically save current registrations every 'n' seconds#

autosave_registrations = 300

 

# PID file:#

pid_file = /usr/local/sipproxd/etc/siproxd.pid

 

# global switch to control the RTP proxy behaviour#

rtp_proxy_enable = 0

 

# Port range to allocate listen ports from for incoming RTP traffic

rtp_port_low  = 2

rtp_port_high = 65000

 

# Timeout for RTP streams#

rtp_timeout = 300

 

# Default Expiration timeout for Registrations#

default_expires = 600

 

# Proxy authentication#

proxy_auth_pwfile = usr/local/sipproxd/etc/siproxd_passwd.cfg

 

# Debug level... (setting to -1 will enable everything)#

debug_level =      0x00000000

 

But when 1111 makes a call to 2222 , the call is failed. 2222 is ringing,
but when taking the call, 1111 will send CANCEL message..@@

When 2222 makes a call to 1111, the signaling is OK , but there is only one
way RTP from 1111 to 2222.@@

 

Is it something wrong of the configuration file? Or the NAT setting ? .. @@
, please help, Thank you 

 

Best Regards,

sam

 

[Siproxd-users] Need for help, siproxd does not work well....@@...

[Samlee <sa...@pt...>]

Dear all:

           Sorry, I am a newbie of siproxd, and have some problem when using
siproxd...

The architecture is following:

private IP address range             :          Internet public IP address
range
   192.168.2.1                          :          10.90.8.40
                                        :
   192.168.2.91                         :  foo.bar.org          10.90.8.185
   +-------------+             +--------------+              +-------------+
   !             !          .1 ! masquerading ! publicIP     !             !
   ! IntHost     !-------------! Firewall     !------------>>! externalHost!
   !             !         eth2!              !eth1          !             !
   +-------------+             +--------------+              +-------------+
   user: 1111                                                user: 2222

Both of user 1111 and user 2222 are registered to siproxd, and 

I want to make a call from "1111" to "2222" and make a call from "2222" to
"1111".

 

       I installed siproxd into a machine with two network interfaces: eth1
(public IP address, but we use 10.90.8.40 for simulation), eth2 (private IP
address, 192.168.2.1). 

To enable NAT, I executed following commands:

1. iptables -A INPUT -i eth2 -j ACCEPT

2. echo "1" > /proc/sys/net/ipv4/ip_forward

3. iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth1 -j MASQUERADE

Then execute 

1. iptables -A INPUT -i eth1 -p udp -m udp --dport 5060 -j ACCEPT

2. iptables -A INPUT -i eth1 -p udp -m udp --dport 2:65000 -j ACCEPT

to receive SIP and RTP message from eth1.

Finally execute "siproxd".

My configuration is following:

# The interface names of INBOUND and OUTBOUND interface.####

if_inbound  = eth2

if_outbound = eth1

host_outbound = 10.90.8.40

 

# Access control.###########################################

hosts_allow_reg = 192.168.2.0/24,10.90.8.0/24

hosts_allow_sip = 192.168.2.0/24,10.90.8.0/24

 

# Port to listen for incoming SIP messages.#################

sip_listen_port = 5060

 

# Shall we daemonize?#######################################

daemonize = 0

 

# What shall I log to syslog?###############################

silence_log = 0

 

# Shall I log call establishment to syslog?#################

log_calls = 1

 

# Secure Enviroment settings:###############################

user = root

 

# Registration file:########################################

registration_file = /usr/local/sipproxd/etc/siproxd_registrations

 

# Automatically save current registrations every 'n' seconds###

autosave_registrations = 300

 

# PID file:#################################################

pid_file = /usr/local/sipproxd/etc/siproxd.pid

 

# global switch to control the RTP proxy behaviour##########

rtp_proxy_enable = 0

 

# Port range to allocate listen ports from for incoming RTP traffic

rtp_port_low  = 2

rtp_port_high = 65000

 

# Timeout for RTP streams###################################

rtp_timeout = 300

 

# Default Expiration timeout for Registrations##############

default_expires = 600

 

# Proxy authentication######################################

proxy_auth_pwfile = usr/local/sipproxd/etc/siproxd_passwd.cfg

 

# Debug level... (setting to -1 will enable everything)#####

debug_level =      0x00000000

 

But when 1111 dial to 2222: the call is failed. And the captured:

No.     Time        Source                Destination           Protocol
Info

     38 10.924474   192.168.2.91          10.90.8.40            SIP
Request: REGISTER sip:10.90.8.40:5060

     39 10.925528   192.168.2.1           192.168.2.91          SIP
Status: 200 OK    (0 bindings)

     74 16.369609   192.168.2.91          10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     75 16.371000   10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     76 16.372224   10.90.8.40            10.90.8.185           SIP/SDP
Request: INVITE sip:2222@10.90.8.185:5060, with session description

     77 16.864497   192.168.2.91          10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     78 16.865351   10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     79 16.866323   10.90.8.40            10.90.8.185           SIP/SDP
Request: INVITE sip:2222@10.90.8.185:5060, with session description

     83 17.864655   192.168.2.91          10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     84 17.889328   10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     85 17.890470   10.90.8.40            10.90.8.185           SIP/SDP
Request: INVITE sip:2222@10.90.8.185:5060, with session description

     91 19.864932   192.168.2.91          10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     92 19.882906   10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

     95 20.008373   10.90.8.40            10.90.8.185           SIP/SDP
Request: INVITE sip:2222@10.90.8.185:5060, with session description

    111 23.865545   192.168.2.91          10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

    112 23.883294   10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:2222@10.90.8.40:5060, with session description

    113 23.884462   10.90.8.40            10.90.8.185           SIP/SDP
Request: INVITE sip:2222@10.90.8.185:5060, with session description

    127 26.240143   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    128 26.240862   10.90.8.40            10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    129 26.241682   10.90.8.40            10.90.8.185           SIP
Request: CANCEL sip:2222@10.90.8.185:5060

    130 26.745748   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    131 26.746478   10.90.8.40            10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    132 26.747301   10.90.8.40            10.90.8.185           SIP
Request: CANCEL sip:2222@10.90.8.185:5060

    133 26.881212   10.90.8.185           10.90.8.40            SIP
Request: REGISTER sip:10.90.8.40:5060

    134 26.881827   10.90.8.40            10.90.8.185           SIP
Status: 200 OK    (0 bindings)

    138 27.746942   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    139 27.747963   10.90.8.40            10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    140 27.748952   10.90.8.40            10.90.8.185           SIP
Request: CANCEL sip:2222@10.90.8.185:5060

    145 29.747297   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    146 29.760631   10.90.8.40            10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    147 29.761526   10.90.8.40            10.90.8.185           SIP
Request: CANCEL sip:2222@10.90.8.185:5060

    171 33.789311   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    172 33.804332   10.90.8.40            10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

    173 33.822108   10.90.8.40            10.90.8.185           SIP
Request: CANCEL sip:2222@10.90.8.185:5060

    188 37.790961   192.168.2.91          10.90.8.40            SIP
Request: CANCEL sip:2222@10.90.8.40:5060

 

And 2222 make a call to 1111 can only hear the voice from 1111 to 2222..@@

 

    12 2.470288    10.90.8.185           10.90.8.40            SIP
Request: REGISTER sip:10.90.8.40:5060

     13 2.470998    10.90.8.40            10.90.8.185           SIP
Status: 200 OK    (0 bindings)

     19 4.323916    10.90.8.185           10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     20 4.325011    10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     21 4.326098    192.168.2.1           192.168.2.91          SIP/SDP
Request: INVITE sip:1111@192.168.2.91:5060, with session description

     22 4.821524    10.90.8.185           10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     23 4.826198    10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     24 4.827119    192.168.2.1           192.168.2.91          SIP/SDP
Request: INVITE sip:1111@192.168.2.91:5060, with session description

     29 5.821816    10.90.8.185           10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     30 5.822835    10.90.8.40            10.90.8.40            SIP/SDP
Request: INVITE sip:1111@10.90.8.40:5060, with session description

     31 5.823904    192.168.2.1           192.168.2.91          SIP/SDP
Request: INVITE sip:1111@192.168.2.91:5060, with session description

     32 6.044740    192.168.2.91          192.168.2.1           SIP
Status: 100 Trying

     33 6.045655    10.90.8.40            10.90.8.40            SIP
Status: 100 Trying

     34 6.046303    10.90.8.40            10.90.8.185           SIP
Status: 100 Trying

     35 6.053839    192.168.2.91          192.168.2.1           SIP
Status: 180 Ringing

     36 6.065038    10.90.8.40            10.90.8.40            SIP
Status: 180 Ringing

     37 6.065702    10.90.8.40            10.90.8.185           SIP
Status: 180 Ringing

     41 6.111349    192.168.2.91          192.168.2.1           SIP
Status: 180 Ringing

     43 6.112376    10.90.8.40            10.90.8.40            SIP
Status: 180 Ringing

     45 6.113068    10.90.8.40            10.90.8.185           SIP
Status: 180 Ringing

     51 6.153730    192.168.2.91          192.168.2.1           SIP
Status: 180 Ringing

     52 6.154906    10.90.8.40            10.90.8.40            SIP
Status: 180 Ringing

     53 6.155568    10.90.8.40            10.90.8.185           SIP
Status: 180 Ringing

     58 7.330918    192.168.2.91          192.168.2.1           SIP/SDP
Status: 200 OK, with session description

     59 7.332508    10.90.8.40            10.90.8.40            SIP/SDP
Status: 200 OK, with session description

     60 7.333367    10.90.8.40            10.90.8.185           SIP/SDP
Status: 200 OK, with session description

     63 7.492410    10.90.8.185           10.90.8.40            SIP
Request: ACK sip:1111@10.90.8.40:5060

     64 7.493288    10.90.8.40            10.90.8.40            SIP
Request: ACK sip:1111@10.90.8.40:5060

     65 7.494027    192.168.2.1           192.168.2.91          SIP
Request: ACK sip:1111@192.168.2.91:5060

     66 7.609294    192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=0, Time=21876

    272 9.609103    10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=100, Time=37876

    273 9.629051    192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=101, Time=38036

    458 11.408043   10.90.8.185           10.90.8.40            SIP
Request: BYE sip:1111@10.90.8.40:5060

    459 11.408878   192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=190, Time=52276

    460 11.408912   10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=190, Time=52276

    461 11.426690   10.90.8.40            10.90.8.40            SIP
Request: BYE sip:1111@10.90.8.40:5060

    462 11.427514   192.168.2.1           192.168.2.91          SIP
Request: BYE sip:1111@192.168.2.91:5060

    463 11.429936   192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=191, Time=52436

    464 11.429980   10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=191, Time=52436

    465 11.449212   192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=192, Time=52596

    466 11.449258   10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=192, Time=52596

    467 11.468703   192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=193, Time=52756

    468 11.468750   10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=193, Time=52756

    469 11.482394   192.168.2.91          192.168.2.1           SIP
Status: 200 OK

    470 11.493440   192.168.2.91          10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=194, Time=52916

    471 11.493487   10.90.8.40            10.90.8.185           RTP
Payload type=ITU-T G.711 PCMU, SSRC=672222100, Seq=194, Time=52916

    472 11.494736   10.90.8.40            10.90.8.40            SIP
Status: 200 OK

    473 11.495582   10.90.8.40            10.90.8.185           SIP
Status: 200 OK

 

Is it something wrong of the configuration file? Or the NAT setting ? .. @@
, please help, Thank you 

 

Best Regards,

samlee

[Siproxd-users] Bug in sip_rewrite_contact()

[Michael P. <mic...@ci...>]

Hi,

I have been trying to use siproxd in association with Free World Dialup,
just as an outbound proxy, and it normally works.  But I have found one
failure case concerning registration.

FWD supports several endpoints registering for the same number at the
same time.  When I register a new endpoint, the 200 response contains
a list of all currently registered contacts, and this is where the
problem lies.

sip_rewrite_contact attempts to translate the contact back to the
'true url', but it only does this for the first contact listed in the
message.  As it happens, I needed it to translate the 2nd contact in a
list of 3 contacts.

Because this translation doesn't take place, my User Agent thinks that
the registration has failed, since it can't find itself on the list of
registered contacts.

Regards,

Michael Procter

[Siproxd-users] More network interfaces

[Krzysztof D. <krz...@gm...>]

Hello!
I have a little bit more complicated situation.
eth0, eth1 - are WAN interfaces
eth2, eth3, eth4 - are LAN interfaces

Is it possible to run 3 instances of siproxd when I have 2 WAN interfaces?
As far as I understand I can run few instances of siproxd, they just have t=
o=20
use different pid files. Am I right?

Tia.
Krzysztof "Xyo" Dendra

--=20
A: Because it is the opposite of how a conversation is scripted.
Q: Why is top posting so annoying?
A: Top posting.
Q: What is the most annoying thing on usenet?

[Siproxd-users] More network interfaces

[Krzysztof D. <krz...@gm...>]

Hello!
I have a little bit more complicated situation.=20
eth0, eth1 - are WAN interfaces
eth2, eth3, eth4 - are LAN interfaces

Is it possible to run 3 instances of siproxd when I have 2 WAN interfaces?=
=20
As far as I understand I can run few instances of siproxd, they just have t=
o=20
use different pid files. Am I right?

Tia.
Krzysztof "Xyo" Dendra

--=20
A: Because it is the opposite of how a conversation is scripted.
Q: Why is top posting so annoying?
A: Top posting.
Q: What is the most annoying thing on usenet?

[Siproxd-users] siproxd "in front" of a nat router

[jeff k. <kwo...@gm...>]

Hi Everyone!

I tried the siproxd configuration of running it "in front" of the
router as described in the online docu. Unfortunatey I cannot make
calls for phones that are inside the same private network of the nat
router. Looking at the traces it seems that the phones were sending
the rtp stream to public ip of the nat router.

IPphone --->siproxd(private ip)-->nat router(public ip)

But the nat router does not know where to route the rtp stream.

This happens because after siproxd the sdp connection information and
the sip contact header becomes the public ip of the nat router. Has
anyone encountered this same problem?What do you think is the work
around to this?

Advance thanks to everyone!
_Jeff