Re: [Ekiga-devel-list] STUN usage with SIP

[Eugen Dedu <eugen dedu univ-fcomte fr>]

On 01/07/15 22:32, schwatzi web de wrote:
> Am 01.07.2015 um 11:43 schrieb Eugen Dedu:
> > On 06/06/15 15:04, schwatzi web de wrote:
> > > Hi,
> >
> > Sorry Scwatzi to answer so late, we are too busy.
> >
> > > How does STUN work in ekiga?
> > >
> > > STUN is normaly used as followed:
> > > The STUN client should use the same socket as SIP and the received IP
> > > and Port should then be used for constructing Contact- , Via- field and
> > > SDP.
> > > Then a keepalive is needed to keep the NAT Session in the router alive (
> > > to refresh the mapping table entry).
> > > This could be a done in many ways.
> > > 1. sending registers more frequently
> > > 2. sending empty SIP packets
> > > 3. sending SIP Request like OPTIONS or NOTIFY(Event: keepalive).
> > > A STUN Request should be done frequently in case the public address (IP
> > > or port) changes( i.e. after a router restart )
> > >
> > > Looking at Ekiga
> > > - it uses a different socket for SIP and STUN ( therefor it cannot use
> > > the discovered port to build the contact SIP packets. So a user needs to
> > > configure his router, too. i.e. Portforwarding or SIP-ALG)
> > > - it adds the public IP in the contact but doesn't change the Via.
> >
> > Well, it does change the Via with the public address, see example below.
> really ? what about contact uri and the contact in SDP
> For my case (symatric NAT+SIP-ALG) ekiga does behave like i want it to.
> In my specific case, ekiga writes port 5061(returned by stun) in the Uri
> but it really should be 5060.
> is there a way to set the extern port manually ?

I do not know.

> > > - it only sends one STUN Request when registering, and don't updates its
> > > public address
> > > - it has no keepalive
> >
> > It does have a keepalive (OPTIONS), for example:
> >
> > ... Housekeepe...baac34b700 SIP     Sending PDU (586 bytes) to:
> > rem=udp$86.64.162.35:5060,local=udp$82.238.108.175:5060,if=192.168.0.1%wlan0
> >
> > OPTIONS sip:ededu 86 64 162 35 SIP/2.0
> > CSeq: 3 OPTIONS
> > Via: SIP/2.0/UDP
> > 82.238.108.175:5060;branch=z9hG4bK9a00c7ec-a144-e211-80bf-0024d693d8e8;rport
> >
> > User-Agent: Ekiga/4.1.0
> > From: "Eugen Dedu"
> > <sip:ededu 82 238 108 175>;tag=e6f5c6ec-a144-e211-80bf-0024d693d8e8
> > Call-ID: 22a3bfec-a144-e211-80bf-0024d693d8e8 snoopy
> > To: <sip:ededu 86 64 162 35>
> > Accept: application/sdp, application/media_control+xml,
> > application/dtmf, application/dtmf-relay
> > Allow:
> > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK
> >
> > Expires: 3600
> > Content-Length: 0
> > Max-Forwards: 70
> Also in my case ekiga does not send keepalives.
> How can I force ekiga to do so ?

You cannot, in my opinion.  It is strange it does not send keepalive in 
your case.  I would investigate this, but I prefer spending time on 
development code instead of the current 4.0 releases.  Sorry, but we 
have limited time.

> > The two other remarks are important, especially the first one!!
> > However, note that STUN is being dropped in ekiga, so this should no
> > longer apply for the next Ekiga release.
> This is interesting. How will ekiga handle NAT in the future?

I do not know exactly, Damien is working on this.

> Personally I don't wanna miss it. Well, its usage in ekiga should to be
> enhance though.
> (If you don't want to make the UI to complicated you could still provide
> some options which can only be set directly via gsettings (or whatever
> ekiga is using).
> i.e. lot of phones have parameters you can only set when using
> provisioning. just some thoughts.)
> If you come up with something different that works i think am fine with
> that, too.
>
> > I put this on my TODO list also, if it will still be relevant.
> Thank you for your effort. I really appreciate it. Ekiga is awsome

Cheers,
Eugen