Re: [Ekiga-devel-list] alien registrar problem

[Dave Allan <dallan redhat com>]

Christian Schäfer wrote:
> Damien Sandras wrote:
> > Le lundi 29 juin 2009 à 11:02 -0400, Christian Schäfer a écrit :
> > > Damien Sandras wrote:
> > >
> > > [...]
> > >
> > >  >>> It tells:
> > >  >>> SIP/2.0 403 Keine RFC1918-IPs erlaubt
> > >
> > > [...]
> > >
> > >  > What happens is that your contact field has 2 IP addresses :
> > >  > - 1 public IP
> > >  > - 1 private IP (with lower priority)
> > >  >
> > >  > The remote SER is misconfigured and rejects the packets because 
> > > one of
> > >  > the IPs is private while the public one is reachable. You should 
> > > contact
> > >  > them.
> > >
> > > I'm having the same problem, however with another provider 
> > > (bluesip.net). The relevant debug output is:
> > >
> > > rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 
> > >
> > > SIP/2.0 479 Please don't use private IP addresses
> > >
> > > Concerning to another voip forum, the responsibilty of this issue is 
> > > on the client site, i.e. ekiga in this case. It seems that ekiga's 
> > > behavior isn't sip-standard conform here (I'm no expert, though). The 
> > > only unsatisfactory solution for me rigth now is to use twinkle with 
> > > this specific provider. Is there a chance that ekiga switches it's 
> > > behavior?
> >
> > I would be happy to change the behavior if Ekiga was not sip conform,
> > but I have no idea what to change. I also have some doubts.
> >
> > Wouldn't it be STUN? Have you tried disabling it?
>
> The problem is independent from whether using STUN or not, and it only 
> appears when I am behind a NAT. As a result, the local IP address 
> (192.168.1.36 in my case) somehow gets through to the provider. To my 
> understanding the IP needs to be replaced with the WAN address by ekiga. 
> Most providers seem to ignore this non-sip-standard behavior, however 
> bluesip (and some others) seem to be more strict.
> (google for "Please don't use private IP addresses")

Just out of curiousity, can anybody point me to the section of the SIP 
spec that covers this behavior?  I looked for it briefly but could not 
find any mention of 479 as a valid response code.

> Chris
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list