siproxd-users — Users Mailing List

[Siproxd-users] Siproxd Pfsense help...

[Yves G. <yve...@in...>]

Hello Siprox Gurus,

I have a little question for you:
I am trying to use siproxd on a Pfsense box, so that a SIP Server on the
LAN interface (LAN !) can act as a SIP server for phones on the WAN (so,
the other way around, as we normally do)...

The Sip server therefore has a private addresse (192.168.2.100).
I would like siproxd to act as an ALG (Application Layer Gateway), so that
it modifies the SIP packets (content of the application layer) in a way
that it matches the UDP packets (so that my packets are matching at the
layer 4 and 7)...

So far, I was unable to do so, I and I unable to find any log / debug
information... I am even not sure siproxd is simply 'running' on my
pfsense...

Who could give me a hand / redirect me to a decent 'howto' manual ?

Thanks in advance for your answer,

Yves.

-- 

*• InnovIP Networks <http://www.innovip.be> •*

**
<http://www.innovip.be>

* *

* *

* *

Yves Gancberg

☎

+32 2 880 68 22



Managing Partner

*M*

+32 478 27 47 86





✉

yve...@in...

[Siproxd-users] Splitting of comma-separated headers

[Henning H. <he...@lo...>]

Hello,

I'm using siproxd 0.8.1 on Debian Squeeze. I have a problem with comma-separated header values being split into multiple headers. For example, the header

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

becomes

Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: OPTIONS
Allow: BYE
Allow: REFER
Allow: SUBSCRIBE
Allow: NOTIFY
Allow: INFO

after going through siproxd. This behaviour is completely valid, but it results in significantly larger packets. Sometimes, the packet size is beyond the MTU on my internal network and the packets become fragmented. Is it possible to change the behaviour of siproxd so that headers with comma-separated values remain unchanged?

Regards,
Henning Holtschneider
--
LocaNet oHG - http://www.loca.net
Baroper Straße 239 b, D-44227 Dortmund
tel +49 231 91596-25, fax +49 231 91596-55
sip 25...@vo...

Registergericht Amtsgericht Dortmund HRA 14208
Geschäftsführer Sven Haufe, Henning Holtschneider

[Siproxd-users] Using siproxd to open a local sip server

[Maximilian R. <mr...@xt...>]

Hi,

i want to use siproxd to open my Asterisk server to the public. The Asterisk server is behind a NAT and i cannot forward ports to it. But the Asterisk server is in an VPN together with an server that has an public ip address.

So this is how i want my setup to be:



 Asterisk  
  as SIP    --- OpenVPN --- Proxy Server
 registrar                       |
                             Internet
                                 |
                             SIP Clients

Is this posible with siproxd? I try to setup it with this configuration:

[root@jupiter ~]# ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 94.249.134.17  netmask 255.255.255.0  broadcast 94.249.134.255
        inet6 fe80::4042:8dff:feb0:2f42  prefixlen 64  scopeid 0x20<link>
        ether 42:42:8d:b0:2f:42  txqueuelen 1000  (Ethernet)
        RX packets 26757603  bytes 3029780057 (2.8 GiB)
        RX errors 0  dropped 32  overruns 0  frame 0
        TX packets 18925600  bytes 47581287242 (44.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436  metric 1
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 1234740  bytes 186405699 (177.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1234740  bytes 186405699 (177.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 10.8.0.1  netmask 255.255.0.0  broadcast 10.8.255.255
        inet6 fe80::9810:f8ff:fe3c:67c6  prefixlen 64  scopeid 0x20<link>
        ether 9a:10:f8:3c:67:c6  txqueuelen 100  (Ethernet)
        RX packets 800165  bytes 165082677 (157.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 930041  bytes 150851885 (143.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@jupiter ~]# cat /etc/siproxd.conf
if_inbound  = eth0
if_outbound = tap0
host_outbound = 10.8.100.1
sip_listen_port = 5060
daemonize = 0
silence_log = 1
registration_file = /var/lib/siproxd/siproxd_registrations
autosave_registrations = 300
pid_file = /var/run/siproxd/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low  = 7070
rtp_port_high = 7089
rtp_timeout = 300
rtp_dscp = 46
sip_dscp = 0
rtp_input_dejitter  = 0
rtp_output_dejitter = 0
tcp_timeout = 600
tcp_connect_timeout = 500
tcp_keepalive = 20
debug_level =      0x00000000
debug_port = 0
ua_string = Siproxd-UA
plugindir=/usr/lib/siproxd/
load_plugin=plugin_logcall.la
load_plugin=plugin_fix_bogus_via.la

The output is in the attachment try1.log.

I tryed it also with this configuration:

[root@jupiter ~]# cat /etc/siproxd.conf
if_inbound  = eth0
if_outbound = tap0
sip_listen_port = 5060
daemonize = 0
silence_log = 1
registration_file = /var/lib/siproxd/siproxd_registrations
autosave_registrations = 300
pid_file = /var/run/siproxd/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low  = 7070
rtp_port_high = 7089
rtp_timeout = 300
rtp_dscp = 46
sip_dscp = 0
rtp_input_dejitter  = 0
rtp_output_dejitter = 0
tcp_timeout = 600
tcp_connect_timeout = 500
tcp_keepalive = 20
debug_level =      0x00000000
debug_port = 0
ua_string = Siproxd-UA
plugindir=/usr/lib/siproxd/
load_plugin=plugin_logcall.la
load_plugin=plugin_fix_bogus_via.la

The output is in the attachment try2.log.

Thanks

Maximilian Ruta

Re: [Siproxd-users] Config Help

[Reza A. <Rez...@vi...>]

Would it be possible to force all registeration packets regardless of a
FQDN to a SIP server? One our multi-tenant switch we don't utilize FQDN
names for the authentication realm. /etc/hosts is a good work around for
this in the mean time.

Reza Ambler                             
Systems Engineer

(O) 858.357.8770
(F) 858.357.8694
(E) rez...@vi...
(W) www.vintalk.com

 

Vintalk
9707 Waples Street, Suite 201         
San Diego, CA 92121 

-----Original Message-----
From: Thomas Ries [mailto:tr...@gm...] 
Sent: Wednesday, March 21, 2012 12:22 AM
To: Siproxd-users
Subject: Re: [Siproxd-users] Config Help

Hi Reza,

The debug Log says the following during REGISTER:
[...]
00:07:52 utils.c:193 gethostbyname(Vintalk) failed: h_errno=1 [Unknown
host]
00:07:52 utils.c:251 DNS lookup - store into cache, entry 2)
00:07:52 utils.c:260 DNS lookup - errcnt=1
00:07:52 sock.c:194 send UDP packet to 10.10.10.197: 33385
[...]

Your Phone tries to reghister at host "Vintalk" (no qualified domain
name, just "Vintalk"). This name cannot be resolved to an IP address by
siproxd, thus the REGISTER cannot be forwarded to the REGISTRAR.

Fix your DNS setup (or add the Vintalk host to your /etc/hosts) and it
should work better.

I addition, please fix your configuration:
[...]
#    If siproxd is not running on the host doing the masquerading
#    but on a host within the private network segment, "in front" of
#    the masquerading router: define if_inbound and if_outbound to
#    point to the same interface (the inbound interface). In *addition*
#    define 'host_outbound' to hold your external (public) IP address
#    or a hostname that resolves to that address (use a dyndns address
for
#    example).
#
if_inbound  = eth0
if_outbound = eth0
# uncomment the following line ONLY IF YOU KNOW WHAT YOU ARE DOING!
# READ THE FAQ FIRST!
#host_outbound =  64.94.105.151
[...]

As the comment explains, if you set if_inbound and if_outbound to the
same IP interface, you must also set host_putbound to point to the
public IP address.

You also shoulbe be aware that siproxd has been made for NAT traversal
of SIP & RTP, so your REGISTRAR *cannot* be located in the same IP
subnet as your local UAs (phones).

The other thing that confuses me is that the log says, the IP address of
the received REGISTER request is 67.52.x.x (a public IP) which makes me
heavily believe that to try to do something that siproxd was not
designed for.
Please re-read the documentation and the different usage scenarios that
siproxd has been designed for.

Regards,
/Thomas

Reza Ambler wrote:
> Hello everyone,
> 
> I'm trying to use siproxd to test proxying some phones back to our
> switch and have siproxd handle the media relay. I have my example
> configuration file here,
> http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/siproxd.conf but it
> doesn't appear to be relaying the SIP registration to my other
> softswitch. I was wondering if someone could help out here, I think
it's
> something minor I'm missing. This is my first go at using siproxd.
> 
>  
> 
> Debug Log File :
http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/debug.log
> 
> Thanks,
> 
>  
> 
> *Reza Ambler                             *
> Systems Engineer
> 
> (O) 858.357.8770
> (F) 858.357.8694
> (E) rez...@vi... <mailto:rez...@vi...>
> (W) www.vintalk.com <http://www.vintalk.com>
> 
>  
> 
> *Vintalk*
> 9707 Waples Street, Suite 201         
> San Diego, CA 92121 
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------
------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

[Siproxd-users] Transparent proxy of multiple clients

[Shannon W. <wsh...@pt...>]

I'm currently testing Siproxd as a transparent proxy of multiple clients.
All outbound calls are working great.
Inbound calls intermittently have one way voice.
If you hang up and then call right back it will work fine.

Does Siproxd support transparent proxing of multiple clients or are 
there known issues
with multiple clients?

siproxd-0.8.1-53 x86_64-redhat-linux-gnu
The clients are Mobile Broadband Routers running Astrisk.

More detail can be given if needed.

Thanks
Shannon

Re: [Siproxd-users] Config Help

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

Hi Reza,

The debug Log says the following during REGISTER:
[...]
00:07:52 utils.c:193 gethostbyname(Vintalk) failed: h_errno=1 [Unknown host]
00:07:52 utils.c:251 DNS lookup - store into cache, entry 2)
00:07:52 utils.c:260 DNS lookup - errcnt=1
00:07:52 sock.c:194 send UDP packet to 10.10.10.197: 33385
[...]

Your Phone tries to reghister at host "Vintalk" (no qualified domain
name, just "Vintalk"). This name cannot be resolved to an IP address by
siproxd, thus the REGISTER cannot be forwarded to the REGISTRAR.

Fix your DNS setup (or add the Vintalk host to your /etc/hosts) and it
should work better.

I addition, please fix your configuration:
[...]
#    If siproxd is not running on the host doing the masquerading
#    but on a host within the private network segment, "in front" of
#    the masquerading router: define if_inbound and if_outbound to
#    point to the same interface (the inbound interface). In *addition*
#    define 'host_outbound' to hold your external (public) IP address
#    or a hostname that resolves to that address (use a dyndns address for
#    example).
#
if_inbound  = eth0
if_outbound = eth0
# uncomment the following line ONLY IF YOU KNOW WHAT YOU ARE DOING!
# READ THE FAQ FIRST!
#host_outbound =  64.94.105.151
[...]

As the comment explains, if you set if_inbound and if_outbound to the
same IP interface, you must also set host_putbound to point to the
public IP address.

You also shoulbe be aware that siproxd has been made for NAT traversal
of SIP & RTP, so your REGISTRAR *cannot* be located in the same IP
subnet as your local UAs (phones).

The other thing that confuses me is that the log says, the IP address of
the received REGISTER request is 67.52.x.x (a public IP) which makes me
heavily believe that to try to do something that siproxd was not
designed for.
Please re-read the documentation and the different usage scenarios that
siproxd has been designed for.

Regards,
/Thomas

Reza Ambler wrote:
> Hello everyone,
> 
> I’m trying to use siproxd to test proxying some phones back to our
> switch and have siproxd handle the media relay. I have my example
> configuration file here,
> http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/siproxd.conf but it
> doesn’t appear to be relaying the SIP registration to my other
> softswitch. I was wondering if someone could help out here, I think it’s
> something minor I’m missing. This is my first go at using siproxd.
> 
>  
> 
> Debug Log File : http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/debug.log
> 
> Thanks,
> 
>  
> 
> *Reza Ambler                             *
> Systems Engineer
> 
> (O) 858.357.8770
> (F) 858.357.8694
> (E) rez...@vi... <mailto:rez...@vi...>
> (W) www.vintalk.com <http://www.vintalk.com>
> 
>  
> 
> *Vintalk*
> 9707 Waples Street, Suite 201         
> San Diego, CA 92121 
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

[Siproxd-users] Config Help

[Reza A. <Rez...@vi...>]

Hello everyone,

I'm trying to use siproxd to test proxying some phones back to our
switch and have siproxd handle the media relay. I have my example
configuration file here,
http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/siproxd.conf but it
doesn't appear to be relaying the SIP registration to my other
softswitch. I was wondering if someone could help out here, I think it's
something minor I'm missing. This is my first go at using siproxd.

 

Debug Log File :
http://sandbox.vintalk.com/~reza/work/0XDEADBEEF/debug.log 

Thanks,

 

Reza Ambler                             
Systems Engineer

(O) 858.357.8770
(F) 858.357.8694
(E) rez...@vi... <mailto:rez...@vi...> 
(W) www.vintalk.com <http://www.vintalk.com> 

 

Vintalk
9707 Waples Street, Suite 201         
San Diego, CA 92121 

 

Re: [Siproxd-users] Bug#657070: embedded library ltdl

[Chí-Thanh C. N. <chi...@ge...>]

Mark Purcell schrieb:
> Whilst siproxd does detect if a system ltdl library is available it does
> fail to build from source (FTBFS) with the error:
> 
> plugins.c:65: undefined reference to 'lt__PROGRAM__LTX_preloaded_symbols'

Try this workaround from Gentoo:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/siproxd/files/siproxd-libtool-2.4.patch?view=markup


Best regards,
Chí-Thanh Christopher Nguyễn

[Siproxd-users] Bug#657070: embedded library ltdl

[Mark P. <ma...@pu...>]

Package: siproxd
Version: 1:0.8.1-1
Severity: important
Tags: security upstream help

siproxd currently ships an embedded copy of the ltdl library.

The original version of ltdl shipped was vunerable to 
'CVE-2009-3736 local privlege esclation'

siproxd upstream (Thomas) have now upgraded the embedded copy of ltdl
as a result siproxd is no longer vunerable to CVE-2009-3736.

The current version of siproxd in Debian Fixed in version siproxd/1:0.8.1-1.

However this Debian version is still using the embedded ltdl library, rather
than the preferred system provided ltdl library.

Whilst siproxd does detect if a system ltdl library is available it does
fail to build from source (FTBFS) with the error:

plugins.c:65: undefined reference to 'lt__PROGRAM__LTX_preloaded_symbols'

which has also been reported here:
http://blog.gmane.org/gmane.network.siproxd/month=20110201

Assistance to fix this issue in the Debian package would be appreciated.

Mark

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages siproxd depends on:
ii  adduser     3.113
ii  libc6       2.13-24
ii  libosip2-7  3.6.0-2

siproxd recommends no packages.

Versions of packages siproxd suggests:
ii  linphone  3.5.0-2

-- no debconf information

Re: [Siproxd-users] Siproxd doesnt' listen on Ipv6

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

Siproxd does not support IPv6.
As with IPv6 no NAT is supposed to be used anymore, there will be no
need to masquerade IPv6 VoIP devices.

Antonio Carlos Salzvedel Furtado Junior wrote:
> Hello,
> 
> I notice that siproxd is only listening on the ipv4 adressess of my
> interface. That's what netstat tells me.
> I cannot find any documentation about how to make siproxd work with
> ipv6. Is it possible?
> 
> I need to test the Ipv6 support of my SIP client.
> 
> Att.
> 
> Antonio Carlos
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users

[Siproxd-users] Siproxd doesnt' listen on Ipv6

[Antonio C. S. F. J. <mar...@gm...>]

Hello,

I notice that siproxd is only listening on the ipv4 adressess of my
interface. That's what netstat tells me.
I cannot find any documentation about how to make siproxd work with ipv6.
Is it possible?

I need to test the Ipv6 support of my SIP client.

Att.

Antonio Carlos

[Siproxd-users] siproxd errors in system logs on pfsense 2.0

[Doug H. <dou...@gm...>]

Hello

I would like to see if I can get help for this issue here. I had installed
pfsense 1.2.3 along with siproxd package almost a year ago. Everything has
been working just fine with my Asterisk sip connections back to
callcentric.com and voip.ms. I then had a smart idea and decided to upgrade
to pfsense 2.0. The upgrade went just fine until I noticed that my
telephone like coming in was not hitting my asterisk box all the time. I
logged into callcentric and see that it would show periodically "Your phone
is not registered". I didn't have this problem before I upgraded! So in my
research to resolve this I find the following errors in the system logs for
pfsense. Nov 7 01:24:52 siproxd[53118]: sock.c:469 ERROR:tcp_connect()
failed Nov 7 01:25:00 siproxd[53118]: proxy.c:706 ERROR:proxy_response:
list_get via failed Nov 7 01:25:16 siproxd[53118]: proxy.c:706
ERROR:proxy_response: list_get via failed Nov 7 01:25:20 siproxd[53118]:
proxy.c:706 ERROR:proxy_response: list_get via failed Nov 7 01:25:46
siproxd[53118]: sock.c:469 ERROR:tcp_connect() failed Nov 7 01:25:56
siproxd[53118]: sock.c:469 ERROR:tcp_connect() failed Nov 7 01:26:41
siproxd[53118]: proxy.c:706 ERROR:proxy_response: list_get via failed Nov 7
01:27:00 siproxd[53118]: proxy.c:706 ERROR:proxy_response: list_get via
failed Nov 7 01:27:07 siproxd[53118]: sock.c:469 ERROR:tcp_connect() failed
Nov 7 01:28:03 siproxd[53118]: sock.c:310 WARNING:recv() returned error
[Connection reset by peer], disconnecting TCP [192.168.123.200] fd=13 Nov 7
01:28:26 siproxd[53118]: proxy.c:706 ERROR:proxy_response: list_get via
failed Nov 7 01:28:30 siproxd[53118]: proxy.c:706 ERROR:proxy_response:
list_get via failed So I figure that something is broken for this package
in the new version of pfsense 2.0. I did search on the forums here to see
if I can find any resolution for this but came up empty. Maybe someone
could help me out as I need to have my phones working Thanks Doug --

[Siproxd-users] I'm trying to delete a VIA but it's not mine

[Niccolò B. <dar...@li...>]

Hi,
Here is my setup:
- The router has ip 192.168.1.1 and has a built-in wifi access point.
- My laptop is connected through wifi and has ip 192.168.1.2 (network 
192.168.1.0/24)
- Another access point is attached to my laptop's eth0 ethernet, which 
has ip 192.168.100.1 (network 192.168.100.0/24).
- The router is too far and so the laptop shares the connection through 
the access point (which has ip 192.168.100.2).
- My mobile phone is connected with ip 192.168.100.10 using the access 
point attached to the laptop and tries to login to an asterisk server in 
a completely different network outside mine.


Here is my siproxd.conf:

if_inbound  = eth0
if_outbound = wlan1
host_outbound = <external_ip>
hosts_allow_reg = 192.168.100.0/24
sip_listen_port = 5060
daemonize = 0
silence_log = 0
user = siproxd
registration_file = /var/lib/siproxd_registrations
pid_file = /var/run/siproxd/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low  = 7070
rtp_port_high = 7089
rtp_timeout = 300
default_expires = 600
debug_level = 0x00000080
debug_port = 0


And here is the error in the log:
ERROR:sip_utils.c:627 I'm trying to delete a VIA but it's not mine! 
host=192.168.1.2

192.168.1.2 is laptop's wlan1 ip.

I'm using latest snapshot of siproxd (20111009).
That's obviously using 192.168.100.1 as proxy server in my mobile phone.


Thanks,
Niccolò

[Siproxd-users] Siproxd suddenly stopped "masking" IP's.

[Henrik A. S. <hen...@gm...>]

I've had Siproxd running for about an hour successfully.

Whenever connecting a client to a SIP server through the server with
Siproxd, it would change the SIP messages to come from the server IP with
Siproxd. As it should.

But suddenly it doesn't do that anymore.

I've used tshark (wireshark) to trace the SIP messages and I can see that
Siproxd doesn't do anything else but forward the SIP messages with the
original IP.

I've tried to restart the server completely and start Siproxd again. Without
any luck.

Can anyone help me out to fix this problem, so Siproxd works again?

All it should as to take SIP (and RTP) packets and send it through with the
IP of the server it's running on.

[Siproxd-users] Siproxd as "middle-man" fails.

[Henrik A. S. <hen...@gm...>]

I'm running Kamailio SIP server on one server. It works fine with SIP
clients etc.

Now I'm trying to run Siproxd SIP Proxy on another server.

I've installed Siproxd and calling netstat -tulpn | grep 5060 shows:

tcp 0 0 0.0.0.0:5060 0.0.0.0:* LISTEN 22216/siproxd

udp 0 0 0.0.0.0:5060 0.0.0.0:* 22216/siproxd

So it is running.

But when I try to connect clients to my original Kamailio SIP server with
the server IP from the one running Siproxd as proxy, it fails.

Can anyone help my out debug the problem?

And shouldn't this solution, when it works, make my clients looks as if they
come from the IP of the server running Siproxd?

[Siproxd-users] New Release 0.8.1

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

A new release of siproxd is available.

Release Notes for siproxd-0.8.1
===============================

Major changes since 0.8.0:
 - new Plugins:
   plugin_prefix: add a prefix on outgoing calls
   plugin_regex: regular expression rewriting (To header) for outgoing calls
 - adjustable pthrad stack size (smaller memory footprint on small
   embedded systems like OpenWRT routers)
 - plus various bugfixes

Upgrade Notes 0.8.0 to 0.8.1:
 - merge your configuration file siproxd.conf (new config options)

General Overview:
 - SIP (RFC3261) Proxy for SIP based softphones hidden behind a
   masquerading firewall
 - basic support for SIP TCP transport
 - Support for PRACK messages (RFC3262)
 - Support for UPDATE messages (RFC3311)
 - SIP UDP and TCP supported
 - 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)
 - 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 (Spec file)
 - 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"
 - configurable RFC3581 (rport) support for sent SIP packets

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

Mainly tested on:
- CentOS 5, 32bit Linux
  This is the main development and testing environment. Other platforms
  are not extensively tested.

Builds on (tested by dev-team or reported to build):
- Linux:	CentOS/RedHat EL
(		Fedora 64bit		)*
(		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		)*

* Note: As the compile farm of sourceforge.net has been discontinued our
        building test possibilities are now very limited. Currently
        no explicit testing for systems/distributions other than
        CentOS/RHEL (x86 architecture) is made. We'll be looking into
        possibilities to perform some broader testing in future.
        Of course, external testers are welcome :-)

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
 - Asterisk PBX (using a SIP Trunk, masqueraded via siproxd)
 - Ekiga
 - FreePBX

Reported interoperability with SIP service providers:
 - Sipgate	(http://www.sipgate.de)
 - Stanaphone	(SIP Gateway to PSTN)
 - Sipcall.ch	(Swiss VoIP provider)
 - Ekiga


 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 interoperability issues with SIP service providers:
 - callcentric.com	(afaik callcentric fails with "500 network failure"
 			during REGISTER if more than one Via header is
			present in a SIP packet. Having multiple Via headers
			is completely in compliance with RFC3261. This might
			be related to their "NAT problem avoidance magic".
			There is nothing that can be done within siproxd
			to avoid this issue as callcentric does not comply
			with the SIP specification.

 - asterisk PBX		Asterisk has an issue finding the proper peer
			if multiple peers originate from the same IP/port
			tuple (a is the case if multiple phones are proxied
			via siproxd to the same asterisk instance).
			This is caused by the SIP implementation in
			asterisk (chan_sip).
			Note: This seems to be no longer valid with
			      asterisk version 1.6 and up.


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

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.


-----
Signatures for siproxd-0.8.1.tar.gz archive:
MD5 Hash:	1a6f9d13aeb2d650375c9a346ac6cbaf
SHA-256 Hash:
df2df04faf5bdb4980cbdfd5516a47898fc47ca1ebc2c628aa48305b20a09dad

GnuPG signature:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBOGgSbB2xLpFxU+GURAt/gAJ9uWS01n7Tr7G7HlX8Zp8+W33OYZACfX69S
mTpcbCWOxuoKDp5R3GWZ+zg=
=BFqD
-----END PGP SIGNATURE-----

Re: [Siproxd-users] Re-writing RFC 3605 SDP attributes

[Darrin S. <dar...@gm...>]

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
@@ -965,6 +965,14 @@
                    "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)) {

[Siproxd-users] Re-writing RFC 3605 SDP attributes

[Darrin S. <dar...@gm...>]

Hi All,

In this example I have a Aastra 9480i phone at 10.1.0.244. 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.

Thanks

Darrin



    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
                Session Version: 1
                Owner Network Type: IN
                Owner Address Type: IP4
                Owner Address: 64.60.XX.YY
            Session Name (s): SIP Call
            Connection Information (c): IN IP4 64.60.XX.YY
                Connection Network Type: IN
                Connection Address Type: IP4
                Connection Address: 64.60.XX.YY
            Time Description, active time (t): 0 0
                Session Start Time: 0
                Session Stop Time: 0
            Media Description, name and address (m): audio 17114
RTP/AVP 9 18 107 113 110 111 96 106 0 8 101
                Media Type: audio
                Media Port: 17114
                Media Proto: RTP/AVP
                Media Format: ITU-T G.722
                Media Format: ITU-T G.729
                Media Format: 107
                Media Format: 113
                Media Format: 110
                Media Format: 111
                Media Format: 96
                Media Format: 106
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.711 PCMA
                Media Format: 101
            Media Attribute (a): rtpmap:9 G722/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 9
                MIME Type: G722
            Media Attribute (a): rtpmap:18 G729/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 18
                MIME Type: G729
            Media Attribute (a): rtpmap:107 BV32/16000
                Media Attribute Fieldname: rtpmap
                Media Format: 107
                MIME Type: BV32
            Media Attribute (a): rtpmap:113 L16/16000
                Media Attribute Fieldname: rtpmap
                Media Format: 113
                MIME Type: L16
            Media Attribute (a): rtpmap:110 PCMU/16000
                Media Attribute Fieldname: rtpmap
                Media Format: 110
                MIME Type: PCMU
            Media Attribute (a): rtpmap:111 PCMA/16000
                Media Attribute Fieldname: rtpmap
                Media Format: 111
                MIME Type: PCMA
            Media Attribute (a): rtpmap:96 G726-40/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 96
                MIME Type: G726-40
            Media Attribute (a): rtpmap:106 BV16/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 106
                MIME Type: BV16
            Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 0
                MIME Type: PCMU
            Media Attribute (a): rtpmap:8 PCMA/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 8
                MIME Type: PCMA
            Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 101
                MIME Type: telephone-event
            Media Attribute (a): silenceSupp:on - - - -
                Media Attribute Fieldname: silenceSupp
                Media Attribute Value: on - - - -
            Media Attribute (a): fmtp:101 0-15
                Media Attribute Fieldname: fmtp
                Media Format: 101 [telephone-event]
                Media format specific parameters: 0-15
            Media Attribute (a): ptime:30
                Media Attribute Fieldname: ptime
                Media Attribute Value: 30
            Media Attribute (a): rtcp:3001 IN IP4 10.1.0.244
                Media Attribute Fieldname: rtcp
                Media Attribute Value: 3001 IN IP4 10.1.0.244
            Media Attribute (a): sendrecv

[Siproxd-users] Debian 'lt_preloaded_symbols' link error

[Felix L. <fel...@am...>]

Hello,

I am packaging a snapshot for Debian, but have a stubborn symbol error.

The Autoconf website states that: "If you
use `LTDL_SET_PRELOADED_SYMBOLS' in your module loader, you must also
specify something to preload to avoid compilation failure due to
undefined `lt_preloaded_symbols'. You can name modules on the Libtool link
command line using one of `-dlopen' or `-dlpreopen'."

Looks like that is properly done in 'src/Makefile.am'.

DLOPENPLUGINS = -dlopen plugin_demo.la \
 -dlopen plugin_shortdial.la \
 -dlopen plugin_logcall.la \
-dlopen plugin_defaulttarget.la \
 -dlopen plugin_fix_bogus_via.la \
-dlopen plugin_stun.la
 siproxd_LDADD = $(LIBLTDL) $(DLOPENPLUGINS)

Yet it results in the error below this message.

I can probably force a build by updating 'libtool' but thought I would ask
this brief question to the developers first.

Autoconf picks Debian's own 'ldtl' library (and not the convenience
library).

Thank you for any pointers,
Felix

* * *

Output below:

/bin/bash ../libtool --tag=CC --mode=link gcc -D_GNU_SOURCE
 -DBUILDSTR="\"`cat .buildno`\"" -g -O2 -g -Wall -O2 -pthread
-D_POSIX_THREAD_SAFE_FUNCTIONS   -o siproxd -export-dynamic siproxd.o
proxy.o register.o sock.o utils.o sip_utils.o sip_layer.o log.o readconf.o
rtpproxy.o rtpproxy_relay.o accessctl.o route_processing.o security.o auth.o
fwapi.o resolve.o dejitter.o plugins.o  -dlopen plugin_demo.la -dlopen
plugin_shortdial.la -dlopen plugin_logcall.la -dlopen
plugin_defaulttarget.la -dlopen plugin_fix_bogus_via.la -dlopen
plugin_stun.la -lresolv -lresolv -losipparser2 -losip2   -lltdl
rm -f .libs/siproxd.nm .libs/siproxd.nmS .libs/siproxd.nmT
creating .libs/siproxdS.c
(cd .libs && gcc  -g -O2 -g -Wall -O2 -c -fno-builtin "siproxdS.c")
rm -f .libs/siproxdS.c .libs/siproxd.nm .libs/siproxd.nmS .libs/siproxd.nmT
gcc -D_GNU_SOURCE -DBUILDSTR=\"5831\" -g -O2 -g -Wall -O2 -pthread
-D_POSIX_THREAD_SAFE_FUNCTIONS -o siproxd siproxd.o proxy.o register.o
sock.o utils.o sip_utils.o sip_layer.o log.o readconf.o rtpproxy.o
rtpproxy_relay.o accessctl.o route_processing.o security.o auth.o fwapi.o
resolve.o dejitter.o plugins.o .libs/siproxdS.o -Wl,--export-dynamic
 -lresolv /usr/lib/libosip2.so -lnsl /usr/lib/libosipparser2.so
/usr/lib/libltdl.so -ldl
plugins.o: In function `load_plugins':
/root/siproxd/siproxd-05Feb2011/src/plugins.c:65: undefined reference to
`lt__PROGRAM__LTX_preloaded_symbols'
collect2: ld returned 1 exit status
rm -f .libs/siproxdS.o
make[3]: *** [siproxd] Error 1
make[3]: Leaving directory `/root/siproxd/siproxd-05Feb2011/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/siproxd/siproxd-05Feb2011'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/siproxd/siproxd-05Feb2011'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed

Re: [Siproxd-users] multi-wan set-up help needed

[Philip <ph...@no...>]

I'm having some issues making sipproxd work in a multiwan environment 
due to the 2 interface limit thing. (inside int, outside int)

my network looks a bit like this

lan 192.168.0.x/24 (emo)=> router(freebsd 8.1 setup as a load balancer) 
(em1) 74.10.x.x   => internet provider a
                                                                         
                                               (em2) 120.10.x.x => 
internet provider b

I'm trying to get sipproxd to work properly on fail-over however I'm 
running into the scenario where it looks like I have to change the 
config manually each time.

Is there a way to set it up for a mult-wan environment?

Thanks

[Siproxd-users] multiwan setup help needed

[Philip <ph...@no...>]

Im having some issues making sipproxd work in a multiwan environment due 
to the 2 interface limit thing. (inside int, outside int)

my network looks a bit like this

lan 192.168.0.x/24 (emo)=> router(freebsd 8.1 setup as a load balancer) 
(em1) 74.10.x.x   => internet provider a
                                                                         
                                               (em2) 120.10.x.x => 
internet provider b

I'm trying to get sipproxd to work properly on fail-over however I'm 
running into the scenario where it looks like I have to change the 
config manually each time.

Is there a way to set it up for a mult-wan environment?

Thanks

Re: [Siproxd-users] Failure to receive ACK with Ekiga

[Felix L. <fel...@gm...>]

My suggestion would be to handle this the way my old Sony Ericsson mobile
matched caller IDs to numbers in the address book.  It resembled the issue
at hand.

On mobile phones, incoming caller IDs can show up with various international
access codes (for example, for a call from Germany while in the US, +49,
01149 and 0049).  The goal is to match the caller ID to an entry in the
address book so the caller's name can be displayed.

My old phone compared caller IDs by matching digits digits backwards from
the end.  It matched across various international access codes and showed
the right name for the caller from the address book even when the access
codes did not match or were missing (our case).

Another, completely different way would be to forward the ACK to all active
sessions.  The clients then could decide if the URL matches their session,
and respond as required by the standard.


On Sun, Dec 5, 2010 at 1:41 AM, Thomas Ries <tr...@gm...> wrote:

> I might think of something that would allow siproxd to deal with such
> providers.
>
> On  1 Dec, Felix Lechner wrote:
> > It is a problem with the username.  Looks like Sipphone/Gizmo5/Google
> > does not send the initial '1' back in the ACK, even though it is
> > required for SIP registration.  Siproxd correctly complains that the
> > UA is not registered.
> >
> > The ACK is not forwarded to the client.  Ekiga drops the call after a
> > timeout.
> >
> > To solve, I changed the function 'compare_url()' in file 'sip_utils.c'
> > from
> >
> >       if (strcmp(url1->username, url2->username) != 0) {
> >          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
> >          return STS_FAILURE;
> >       }
> >
> > to
> >
> >       if (strcmp(url1->username, url2->username) != 0
> >         && strncmp(url2->username, "1", 1) == 0
> >         && strcmp(url1->username, url2->username + 1) != 0) {
> >          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
> >          return STS_FAILURE;
> >       }
> >
> > It probably isn't the best way to deal with this Sipphone/Google Voice
> > quirk, but it works for me.  The ACK is now passed onto the Ekiga
> > client.
> >  This is for incoming Gizmo5 calls that were originated on the Google
> > Voice web interface or a browser plugin.
> >
> > Just made two calls that were longer than thirty seconds.  Previously,
> > Ekiga dropped the call after approximately 32 seconds.
> >
> >
> > ---------- Forwarded message ----------
> > From: Felix Lechner <fel...@gm...>
> > Date: Tue, Nov 30, 2010 at 5:47 PM
> > Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga
> > To: Siproxd-users <sip...@li...>
> >
> >
> > Hello Thomas,
> >
> > The excerpt below is from the debug log.
> >
> > Server is Sipphone.  Client is Ekiga.  Network is complex.  Nested NAT.
> >
> > Is it possible the user name mismatch has anything to do with it?
> >
> > Thank you,
> > Felix
> >
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526
> > received SIP type REQ:ACK
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> > fetching outbound IP by HOSTNAME
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89
> > proxy_request Nov 30 17:15:01 buffalo-linkstation siproxd[6237]:
> > route_processing.c:63 route_preprocess: no Route header present
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> > lookup - from cache: 192.168.11.177 -> 192.168.11.177
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018
> > sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> > comparing urls: sip:7476686228@74.125.66.80<sip%3A7476686228@74.125.66.80>
> > <sip%3A7476686228@74.125.66.80 <sip%253A7476686228@74.125.66.80>> ->
> sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
> > <sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>
> Nov 30 17:15:01 buffalo-linkstation
> > siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> > comparing urls: sip:7476686228@74.125.66.80<sip%3A7476686228@74.125.66.80>
> > <sip%3A7476686228@74.125.66.80 <sip%253A7476686228@74.125.66.80>> ->
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> > compare_url: username mismatch
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> > comparing urls: sip:7476686228@72.254.95.107<sip%3A7476686228@72.254.95.107>
> > <sip%3A7476686228@72.254.95.107 <sip%253A7476686228@72.254.95.107>> ->
> sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
> > <sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>
> Nov 30 17:15:01 buffalo-linkstation
> > siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> > comparing urls: sip:7476686228@72.254.95.107<sip%3A7476686228@72.254.95.107>
> > <sip%3A7476686228@72.254.95.107 <sip%253A7476686228@72.254.95.107>> ->
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> > compare_url: username mismatch
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382
> > fetching interface IP by INTERFACE [1]
> >  Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 ifaddr
> > lookup - from cache: eth0 -> 192.168.11.1 UP
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> > fetching outbound IP by HOSTNAME
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> > lookup - from cache: 72.254.95.107 -> 72.254.95.107
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179
> > sip_find_direction: unable to determine direction of SIP packet
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:120
> > INFO:ACK Call: +16172295005@10.218.1.144 -> 7476686228@74.125.66.80
> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request
> > [ACK] from/to unregistered UA (RQ: +16172295005@10.218.1.144 ->
> > 7476686228@72.254.95.107)
> >
> >
> >
> > On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <tr...@gm...> wrote:
> >
> >> Can you provide a debug log of siproxd?
> >> I'd like to see how the dropped ACK looks like. There is/was a know
> >> issue with ekiga.net. In that articular case a wrong Content-Lenght
> >> did cause the packet to be dropped by libosip2.
> >> Are there any warnings/errors in the siproxd log file?
> >>
> >> Regards,
> >> /Thomas
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to
> build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>
>

Re: [Siproxd-users] Failure to receive ACK with Ekiga

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

I might think of something that would allow siproxd to deal with such
providers.

On  1 Dec, Felix Lechner wrote:
> It is a problem with the username.  Looks like Sipphone/Gizmo5/Google
> does not send the initial '1' back in the ACK, even though it is
> required for SIP registration.  Siproxd correctly complains that the
> UA is not registered.
> 
> The ACK is not forwarded to the client.  Ekiga drops the call after a
> timeout.
> 
> To solve, I changed the function 'compare_url()' in file 'sip_utils.c'
> from
> 
>       if (strcmp(url1->username, url2->username) != 0) {
>          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
>          return STS_FAILURE;
>       }
> 
> to
> 
>       if (strcmp(url1->username, url2->username) != 0
>         && strncmp(url2->username, "1", 1) == 0
>         && strcmp(url1->username, url2->username + 1) != 0) {
>          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
>          return STS_FAILURE;
>       }
> 
> It probably isn't the best way to deal with this Sipphone/Google Voice
> quirk, but it works for me.  The ACK is now passed onto the Ekiga
> client.
>  This is for incoming Gizmo5 calls that were originated on the Google
> Voice web interface or a browser plugin.
> 
> Just made two calls that were longer than thirty seconds.  Previously,
> Ekiga dropped the call after approximately 32 seconds.
> 
> 
> ---------- Forwarded message ----------
> From: Felix Lechner <fel...@gm...>
> Date: Tue, Nov 30, 2010 at 5:47 PM
> Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga
> To: Siproxd-users <sip...@li...>
> 
> 
> Hello Thomas,
> 
> The excerpt below is from the debug log.
> 
> Server is Sipphone.  Client is Ekiga.  Network is complex.  Nested NAT.
> 
> Is it possible the user name mismatch has anything to do with it?
> 
> Thank you,
> Felix
> 
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526
> received SIP type REQ:ACK
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> fetching outbound IP by HOSTNAME
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89
> proxy_request Nov 30 17:15:01 buffalo-linkstation siproxd[6237]:
> route_processing.c:63 route_preprocess: no Route header present
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> lookup - from cache: 192.168.11.177 -> 192.168.11.177
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018
> sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228@74.125.66.80
> <sip%3A7476686228@74.125.66.80> -> sip:17476686228@72.254.95.107
> <sip%3A17476686228@72.254.95.107> Nov 30 17:15:01 buffalo-linkstation
> siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228@74.125.66.80
> <sip%3A7476686228@74.125.66.80> -> 
> sip:174...@pr...<sip%3A1...@pr...>
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228@72.254.95.107
> <sip%3A7476686228@72.254.95.107> -> sip:17476686228@72.254.95.107
> <sip%3A17476686228@72.254.95.107> Nov 30 17:15:01 buffalo-linkstation
> siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228@72.254.95.107
> <sip%3A7476686228@72.254.95.107> -> 
> sip:174...@pr...<sip%3A1...@pr...>
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382
> fetching interface IP by INTERFACE [1]
>  Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 ifaddr
> lookup - from cache: eth0 -> 192.168.11.1 UP
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> fetching outbound IP by HOSTNAME
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> lookup - from cache: 72.254.95.107 -> 72.254.95.107
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179
> sip_find_direction: unable to determine direction of SIP packet
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:120
> INFO:ACK Call: +16172295005@10.218.1.144 -> 7476686228@74.125.66.80
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request
> [ACK] from/to unregistered UA (RQ: +16172295005@10.218.1.144 ->
> 7476686228@72.254.95.107)
> 
> 
> 
> On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <tr...@gm...> wrote:
> 
>> Can you provide a debug log of siproxd?
>> I'd like to see how the dropped ACK looks like. There is/was a know
>> issue with ekiga.net. In that articular case a wrong Content-Lenght
>> did cause the packet to be dropped by libosip2.
>> Are there any warnings/errors in the siproxd log file?
>>
>> Regards,
>> /Thomas
>>
>>

Re: [Siproxd-users] Failure to receive ACK with Ekiga

[Felix L. <fel...@gm...>]

It is a problem with the username.  Looks like Sipphone/Gizmo5/Google does
not send the initial '1' back in the ACK, even though it is required for SIP
registration.  Siproxd correctly complains that the UA is not registered.

The ACK is not forwarded to the client.  Ekiga drops the call after a
timeout.

To solve, I changed the function 'compare_url()' in file 'sip_utils.c' from

      if (strcmp(url1->username, url2->username) != 0) {
         DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
         return STS_FAILURE;
      }

to

      if (strcmp(url1->username, url2->username) != 0
        && strncmp(url2->username, "1", 1) == 0
        && strcmp(url1->username, url2->username + 1) != 0) {
         DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
         return STS_FAILURE;
      }

It probably isn't the best way to deal with this Sipphone/Google Voice
quirk, but it works for me.  The ACK is now passed onto the Ekiga client.
 This is for incoming Gizmo5 calls that were originated on the Google Voice
web interface or a browser plugin.

Just made two calls that were longer than thirty seconds.  Previously, Ekiga
dropped the call after approximately 32 seconds.


---------- Forwarded message ----------
From: Felix Lechner <fel...@gm...>
Date: Tue, Nov 30, 2010 at 5:47 PM
Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga
To: Siproxd-users <sip...@li...>


Hello Thomas,

The excerpt below is from the debug log.

Server is Sipphone.  Client is Ekiga.  Network is complex.  Nested NAT.

Is it possible the user name mismatch has anything to do with it?

Thank you,
Felix

Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526 received
SIP type REQ:ACK
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349 fetching
outbound IP by HOSTNAME
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89 proxy_request
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: route_processing.c:63
route_preprocess: no Route header present
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS lookup -
from cache: 192.168.11.177 -> 192.168.11.177
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018
sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@74.125.66.80 <sip%3A7476686228@74.125.66.80> ->
sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@74.125.66.80 <sip%3A7476686228@74.125.66.80> ->
sip:174...@pr...<sip%3A1...@pr...>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@72.254.95.107 <sip%3A7476686228@72.254.95.107> ->
sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@72.254.95.107 <sip%3A7476686228@72.254.95.107> ->
sip:174...@pr...<sip%3A1...@pr...>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382 fetching
interface IP by INTERFACE [1]
 Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 ifaddr
lookup - from cache: eth0 -> 192.168.11.1 UP
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349 fetching
outbound IP by HOSTNAME
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS lookup -
from cache: 72.254.95.107 -> 72.254.95.107
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179
sip_find_direction: unable to determine direction of SIP packet
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:120
INFO:ACK Call: +16172295005@10.218.1.144 -> 7476686228@74.125.66.80
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request [ACK]
from/to unregistered UA (RQ: +16172295005@10.218.1.144 ->
7476686228@72.254.95.107)



On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <tr...@gm...> wrote:

> Can you provide a debug log of siproxd?
> I'd like to see how the dropped ACK looks like. There is/was a know
> issue with ekiga.net. In that articular case a wrong Content-Lenght did
> cause the packet to be dropped by libosip2.
> Are there any warnings/errors in the siproxd log file?
>
> Regards,
> /Thomas
>
>

Re: [Siproxd-users] Failure to receive ACK with Ekiga

[Felix L. <fel...@am...>]

Hello Thomas,

The excerpt below is from the debug log.

Server is Sipphone.  Client is Ekiga.  Network is complex.  Nested NAT.

Is it possible the user name mismatch has anything to do with it?

Thank you,
Felix

Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526 received
SIP type REQ:ACK
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349 fetching
outbound IP by HOSTNAME
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89 proxy_request
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: route_processing.c:63
route_preprocess: no Route header present
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS lookup -
from cache: 192.168.11.177 -> 192.168.11.177
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018
sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@74.125.66.80 <sip%3A7476686228@74.125.66.80> ->
sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@74.125.66.80 <sip%3A7476686228@74.125.66.80> ->
sip:174...@pr...<sip%3A1...@pr...>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@72.254.95.107 <sip%3A7476686228@72.254.95.107> ->
sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279 comparing
urls: sip:7476686228@72.254.95.107 <sip%3A7476686228@72.254.95.107> ->
sip:174...@pr...<sip%3A1...@pr...>
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
compare_url: username mismatch
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382 fetching
interface IP by INTERFACE [1]
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 ifaddr lookup
- from cache: eth0 -> 192.168.11.1 UP
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349 fetching
outbound IP by HOSTNAME
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS lookup -
from cache: 72.254.95.107 -> 72.254.95.107
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179
sip_find_direction: unable to determine direction of SIP packet
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:120
INFO:ACK Call: +16172295005@10.218.1.144 -> 7476686228@74.125.66.80
Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request [ACK]
from/to unregistered UA (RQ: +16172295005@10.218.1.144 ->
7476686228@72.254.95.107)



On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <tr...@gm...> wrote:

> Can you provide a debug log of siproxd?
> I'd like to see how the dropped ACK looks like. There is/was a know
> issue with ekiga.net. In that articular case a wrong Content-Lenght did
> cause the packet to be dropped by libosip2.
> Are there any warnings/errors in the siproxd log file?
>
> Regards,
> /Thomas
>
> On 29 Nov, Felix Lechner wrote:
> > Hello,
> >
> > Is anyone aware of a situation when Siproxd would swallow the ACK in
> > an INVITE handshake?
> >
> > Below are my logs.
> >
> > Ekiga terminates because of failure to receive ACK.
> >
> > Siproxd runs on gateway at 192.168.11.1.  Client is 192.168.11.177.
> > Call is an inbound Google Voice call via Sipphone/Gizmo5.
> >
> > Regards,
> > Felix
> >
> > * * * Between Ekiga and my gateway running Siproxd:
> >
> > No.     Time        Source                Destination
> > Protocol Info
> >       1 0.000000    192.168.11.1          192.168.11.177
> > SIP/SDP Request: INVITE
> > sip:17476686228@192.168.11.177 <sip%3A17476686228@192.168.11.177><
> sip%3A17476686228@192.168.11.177 <sip%253A17476686228@192.168.11.177>>,
> > with session description
> >       2 0.004324    192.168.11.177        192.168.11.1          SIP
> >  Status: 100 Trying
> >       3 0.011226    192.168.11.177        192.168.11.1          SIP
> >  Status: 180 Ringing
> >       4 1.221986    192.168.11.177        192.168.11.1          SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >       5 1.668841    192.168.11.1          192.168.11.177        SIP
> >  Status: 200 OK    (1 bindings)
> >       6 1.676359    192.168.11.177        192.168.11.1          SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >       7 2.116070    192.168.11.1          192.168.11.177        SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@192.168.11.177 <sip%3A17476686228@192.168.11.177><
> sip%3A17476686228@192.168.11.177 <sip%253A17476686228@192.168.11.177>>
> >       8 2.119343    192.168.11.177        192.168.11.1          SIP
> >  Status: 405 Method Not Allowed
> >       9 2.178203    192.168.11.177        192.168.11.1          SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      10 2.208363    192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      11 2.598451    192.168.11.1          192.168.11.177        SIP
> >  Status: 405 Method Not Allowed
> >      12 2.638144    192.168.11.1          192.168.11.177        SIP
> >  Status: 405 Method Not Allowed
> >      13 2.709676    192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      14 3.674083    192.168.11.177        192.168.11.1
> >  SIP/SDP Status: 200 OK, with session description
> >      15 3.710301    192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      16 4.174685    192.168.11.177        192.168.11.1
> >  SIP/SDP Status: 200 OK, with session description
> >      17 5.710938    192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      18 31.680208   192.168.11.177        192.168.11.1          SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >      19 32.181097   192.168.11.177        192.168.11.1          SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >      20 32.814627   192.168.11.1          192.168.11.177        SIP
> >  Status: 200 OK    (1 bindings)
> >      21 32.822995   192.168.11.177        192.168.11.1          SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      22 32.829732   192.168.11.1          192.168.11.177        SIP
> >  Status: 200 OK    (1 bindings)
> >      23 33.328976   192.168.11.1          192.168.11.177        SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@192.168.11.177 <sip%3A17476686228@192.168.11.177><
> sip%3A17476686228@192.168.11.177 <sip%253A17476686228@192.168.11.177>>
> >      24 33.331561   192.168.11.177        192.168.11.1          SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      25 33.333971   192.168.11.177        192.168.11.1          SIP
> >  Status: 405 Method Not Allowed
> >      26 33.448979   192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      27 33.733403   192.168.11.1          192.168.11.177        SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@192.168.11.177 <sip%3A17476686228@192.168.11.177><
> sip%3A17476686228@192.168.11.177 <sip%253A17476686228@192.168.11.177>>
> >      28 33.738981   192.168.11.177        192.168.11.1          SIP
> >  Status: 405 Method Not Allowed
> >      29 33.761589   192.168.11.1          192.168.11.177        SIP
> >  Status: 405 Method Not Allowed
> >      30 33.950697   192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      31 34.951540   192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      32 35.745194   192.168.11.177        192.168.11.1          SIP
> >  Request: BYE sip:+16172295005@74.125.46.80:24000
> >      33 36.246353   192.168.11.177        192.168.11.1          SIP
> >  Request: BYE sip:+16172295005@74.125.46.80:24000
> >      34 36.266313   192.168.11.1          192.168.11.177        SIP
> >  Status: 404 Not here
> >      35 36.715199   192.168.11.1          192.168.11.177        SIP
> >  Status: 404 Not here
> >      36 36.951550   192.168.11.177        198.65.166.131
> > SIP/XML Request: PUBLISH
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >
> > * * * Between Siproxd and the outside world:
> >
> > No.     Time        Source                Destination
> > Protocol Info
> >       1 0.000000    198.65.166.131        10.11.39.174
> > SIP/SDP Request: INVITE
> > sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107><
> sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>,
> > with session description
> >       2 0.017487    10.11.39.174          198.65.166.131        SIP
> >  Status: 100 Trying
> >       3 0.024133    10.11.39.174          198.65.166.131        SIP
> >  Status: 180 Ringing
> >       4 1.234185    10.11.39.174          198.65.166.131        SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >       5 1.673553    198.65.166.131        10.11.39.174          SIP
> >  Status: 200 OK    (1 bindings)
> >       6 1.688100    10.11.39.174          198.65.166.131        SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >       7 2.120416    198.65.166.131        10.11.39.174          SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107><
> sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>
> >       8 2.131477    10.11.39.174          198.65.166.131        SIP
> >  Status: 405 Method Not Allowed
> >       9 2.189953    10.11.39.174          198.65.166.131        SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      10 2.603282    198.65.166.131        10.11.39.174          SIP
> >  Status: 405 Method Not Allowed
> >      11 2.643286    198.65.166.131        10.11.39.174          SIP
> >  Status: 405 Method Not Allowed
> >      12 3.689478    10.11.39.174          198.65.166.131
> >  SIP/SDP Status: 200 OK, with session description
> >      13 4.188695    10.11.39.174          198.65.166.131
> >  SIP/SDP Status: 200 OK, with session description
> >      14 4.289813    198.65.166.131        10.11.39.174          SIP
> >  Request: ACK sip:7476686228@72.254.95.107:5060
> >      15 4.297488    10.11.39.174          198.65.166.131        SIP
> >  Status: 408 Request Timeout
> >      16 4.797679    198.65.166.131        10.11.39.174          SIP
> >  Request: ACK sip:7476686228@72.254.95.107:5060
> >      17 4.804459    10.11.39.174          198.65.166.131        SIP
> >  Status: 408 Request Timeout
> >      18 32.231665   10.11.39.174          198.65.166.131        SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >      19 32.236893   10.11.39.174          198.65.166.131        SIP
> >  Request: REGISTER sip:proxy01.sipphone.com
> >      20 32.819967   198.65.166.131        10.11.39.174          SIP
> >  Status: 200 OK    (1 bindings)
> >      21 32.831952   198.65.166.131        10.11.39.174          SIP
> >  Status: 200 OK    (1 bindings)
> >      22 32.834899   10.11.39.174          198.65.166.131        SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      23 33.332820   198.65.166.131        10.11.39.174          SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107><
> sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>
> >      24 33.343388   10.11.39.174          198.65.166.131        SIP
> >  Request: SUBSCRIBE
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@pr...>
> >
> >      25 33.347591   10.11.39.174          198.65.166.131        SIP
> >  Status: 405 Method Not Allowed
> >      26 33.736708   198.65.166.131        10.11.39.174          SIP
> >  Request: SUBSCRIBE
> > sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107><
> sip%3A17476686228@72.254.95.107 <sip%253A17476686228@72.254.95.107>>
> >      27 33.752125   10.11.39.174          198.65.166.131        SIP
> >  Status: 405 Method Not Allowed
> >      28 33.765718   198.65.166.131        10.11.39.174          SIP
> >  Status: 405 Method Not Allowed
> >      29 35.063947   10.11.39.174          198.65.166.165        STUN
> > Message: Binding Request
> >      30 35.543214   198.65.166.165        10.11.39.174          STUN
> > Message: Binding Response
> >      31 35.759343   10.11.39.174          74.125.46.80          SIP
> >  Request: BYE sip:+16172295005@74.125.46.80:24000
> >      32 36.257008   74.125.46.80          10.11.39.174          SIP
> >  Status: 404 Not here
> >      33 36.271817   10.11.39.174          74.125.46.80          SIP
> >  Request: BYE sip:+16172295005@74.125.46.80:24000
> >      34 36.720896   74.125.46.80          10.11.39.174          SIP
> >  Status: 404 Not here
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>
>