STUN usage with SIP

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

STUN usage with SIP

Paolo Compagnini
Hi,

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.
- it only sends one STUN Request when registering, and don't updates its
public address
- it has no keepalive


regards



_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: STUN usage with SIP

Eugen Dedu-2
On 06/06/15 15:04, [hidden email] 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.

> - 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

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.

I put this on my TODO list also, if it will still be relevant.

--
Eugen
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: STUN usage with SIP

Paolo Compagnini


Am 01.07.2015 um 11:43 schrieb Eugen Dedu:

> On 06/06/15 15:04, [hidden email] 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 ?

>
>> - 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 ?
>
> 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?
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

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: STUN usage with SIP

Eugen Dedu-2
On 01/07/15 22:32, [hidden email] wrote:

>
>
> Am 01.07.2015 um 11:43 schrieb Eugen Dedu:
>> On 06/06/15 15:04, [hidden email] 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
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list