Feature-request: AVPs for nat_traversal

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

Feature-request: AVPs for nat_traversal

Thomas Gelf
I would also like to take occasion to propose a new feature: adding a
parameter named "keepalive_interval_avp", allowing to set individual
keepalive intervals for customers with special needs.

Also "keepalive_method_avp" would be a useful addition. Both changes
would probably require modifications to keepalive_state_file and
corresponding internal structures, but I think this could be solved
in a backward-compatible manner.

Best regards,
Thomas Gelf


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Bogdan-Andrei Iancu
Dan, what about this? this will accelerate the migration from nathelper
to nat_tranversal module, what do you say?

As time as it is not technical nightmare (from implementation point of
view), this feature make sense to me.

Regards,
Bogdan

Thomas Gelf wrote:

> I would also like to take occasion to propose a new feature: adding a
> parameter named "keepalive_interval_avp", allowing to set individual
> keepalive intervals for customers with special needs.
>
> Also "keepalive_method_avp" would be a useful addition. Both changes
> would probably require modifications to keepalive_state_file and
> corresponding internal structures, but I think this could be solved
> in a backward-compatible manner.
>
> Best regards,
> Thomas Gelf
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Dan Pascu

On 10 Jun 2009, at 21:07, Bogdan-Andrei Iancu wrote:

> Dan, what about this? this will accelerate the migration from  
> nathelper to nat_tranversal module, what do you say?
>

I can see the benefit of having the keepalive interval customizable  
per user, but I'm not sure what's the advantage of having the  
keepalive method customizable per user. In my experience all devices  
I've encountered respond to either OPTIONS or NOTIFY and in the end it  
doesn't really matter if they give a positive or negative reply for  
that matter. All it matters that they give a reply back. I would be  
curious to hear how the keepalive method per user can help and in what  
cases. If one can imagine a use case for custom keepalive methods, I  
would rather see that on a per device basis not per SIP account basis.

Anyway, I'm open to patch submissions. But first let's see if these  
additions really serve real use cases that are not covered by the  
existing design, or just provide suboptimal solutions that could be  
achieved with the existing code. I'd like to hear some arguments and  
examples of real use cases for them. I'm interested to avoid getting  
in the creeping featurism zone.

> As time as it is not technical nightmare (from implementation point  
> of view), this feature make sense to me.
>
> Regards,
> Bogdan
>
> Thomas Gelf wrote:
>> I would also like to take occasion to propose a new feature: adding a
>> parameter named "keepalive_interval_avp", allowing to set individual
>> keepalive intervals for customers with special needs.
>>
>> Also "keepalive_method_avp" would be a useful addition. Both changes
>> would probably require modifications to keepalive_state_file and
>> corresponding internal structures, but I think this could be solved
>> in a backward-compatible manner.
>>
>> Best regards,
>> Thomas Gelf
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>


--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Bogdan-Andrei Iancu
Hi Dan,

Dan Pascu wrote:

>
> On 10 Jun 2009, at 21:07, Bogdan-Andrei Iancu wrote:
>
>> Dan, what about this? this will accelerate the migration from
>> nathelper to nat_tranversal module, what do you say?
>>
>
> I can see the benefit of having the keepalive interval customizable
> per user, but I'm not sure what's the advantage of having the
> keepalive method customizable per user. In my experience all devices
> I've encountered respond to either OPTIONS or NOTIFY and in the end it
> doesn't really matter if they give a positive or negative reply for
> that matter. All it matters that they give a reply back. I would be
> curious to hear how the keepalive method per user can help and in what
> cases. If one can imagine a use case for custom keepalive methods, I
> would rather see that on a per device basis not per SIP account basis.
>
> Anyway, I'm open to patch submissions. But first let's see if these
> additions really serve real use cases that are not covered by the
> existing design, or just provide suboptimal solutions that could be
> achieved with the existing code. I'd like to hear some arguments and
> examples of real use cases for them. I'm interested to avoid getting
> in the creeping featurism zone.

 From my personal opinion , what makes sense here is:
    - to be able to enable/disable pinging from script (per each
REGISTER  or dialog) - I guess the module already does this
    - to allow custom ping interval per ping session (similar as we do
with timeouts in TM - setting an AVP when enabling the ping, maybe)
    - to allow selection of ping type (UDP versus SIP) by simply setting
a flag (like we do now in nathelper - default is UDP ping and if you set
an extra flag, you get SIP  ping).

So three infos: if ping or not, the interval and the type - maybe we can
combine all this into an enable_ping() functions ?

All these options will give you the possibility to do all the crazy
combinations from script. At least I think so :)

Regards,
Bogdan

>
>> As time as it is not technical nightmare (from implementation point
>> of view), this feature make sense to me.
>>
>> Regards,
>> Bogdan
>>
>> Thomas Gelf wrote:
>>> I would also like to take occasion to propose a new feature: adding a
>>> parameter named "keepalive_interval_avp", allowing to set individual
>>> keepalive intervals for customers with special needs.
>>>
>>> Also "keepalive_method_avp" would be a useful addition. Both changes
>>> would probably require modifications to keepalive_state_file and
>>> corresponding internal structures, but I think this could be solved
>>> in a backward-compatible manner.
>>>
>>> Best regards,
>>> Thomas Gelf
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
>
> --
> Dan
>
>
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Dan Pascu

On 11 Jun 2009, at 12:23, Bogdan-Andrei Iancu wrote:

>> Anyway, I'm open to patch submissions. But first let's see if these  
>> additions really serve real use cases that are not covered by the  
>> existing design, or just provide suboptimal solutions that could be  
>> achieved with the existing code. I'd like to hear some arguments  
>> and examples of real use cases for them. I'm interested to avoid  
>> getting in the creeping featurism zone.
>
> From my personal opinion , what makes sense here is:
>   - to be able to enable/disable pinging from script (per each  
> REGISTER  or dialog) - I guess the module already does this

This already works.

>
>   - to allow custom ping interval per ping session (similar as we do  
> with timeouts in TM - setting an AVP when enabling the ping, maybe)

As I said, I can see why this could be useful.

>
>   - to allow selection of ping type (UDP versus SIP) by simply  
> setting a flag (like we do now in nathelper - default is UDP ping  
> and if you set an extra flag, you get SIP  ping).
>

I explicitly did not implement UDP pings, because over 40% of the  
routers out there will not keep the NAT open if they do not receive  
something from inside the NAT. As a consequence UDP pings are useless  
with those devices and unfortunately you cannot know which work and  
which don't. While UDP pings are cheaper and thus more appealing, in  
their case it applies the rule that you get what you pay for.

> So three infos: if ping or not, the interval and the type - maybe we  
> can combine all this into an enable_ping() functions ?

No extra function is needed, just some extra avps.

>
>
> All these options will give you the possibility to do all the crazy  
> combinations from script. At least I think so :)


--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Bogdan-Andrei Iancu
Dan Pascu wrote:

>
> On 11 Jun 2009, at 12:23, Bogdan-Andrei Iancu wrote:
>>> Anyway, I'm open to patch submissions. But first let's see if these
>>> additions really serve real use cases that are not covered by the
>>> existing design, or just provide suboptimal solutions that could be
>>> achieved with the existing code. I'd like to hear some arguments and
>>> examples of real use cases for them. I'm interested to avoid getting
>>> in the creeping featurism zone.
>>
>> From my personal opinion , what makes sense here is:
>>   - to be able to enable/disable pinging from script (per each
>> REGISTER  or dialog) - I guess the module already does this
>
> This already works.
>
>>
>>   - to allow custom ping interval per ping session (similar as we do
>> with timeouts in TM - setting an AVP when enabling the ping, maybe)
>
> As I said, I can see why this could be useful.
>
>>
>>   - to allow selection of ping type (UDP versus SIP) by simply
>> setting a flag (like we do now in nathelper - default is UDP ping and
>> if you set an extra flag, you get SIP  ping).
>>
>
> I explicitly did not implement UDP pings, because over 40% of the
> routers out there will not keep the NAT open if they do not receive
> something from inside the NAT. As a consequence UDP pings are useless
> with those devices and unfortunately you cannot know which work and
> which don't. While UDP pings are cheaper and thus more appealing, in
> their case it applies the rule that you get what you pay for.

I agree with you - to be honest I'm using only SIP ping ....so should we
obsolete the UDP ping :) ?
>
>> So three infos: if ping or not, the interval and the type - maybe we
>> can combine all this into an enable_ping() functions ?
>
> No extra function is needed, just some extra avps.
makes sense - if there are not so many vals to push.


Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Thomas Gelf
Bogdan-Andrei Iancu wrote:
> I agree with you - to be honest I'm using only SIP ping ....so should we
> obsolete the UDP ping :) ?

I have no concerns regarding this. IMO the additional load does not
really hurt small systems - and large systems should already be designed
to scale out ;-) Seriously: the only reason for "pings" is keeping "UDP
connections" (even if there is no such thing) alive. Most systems that
require such things need traffic from "inside" - so UDP ping is mostly
pretty useless, trash it!

>> No extra function is needed, just some extra avps.
> makes sense - if there are not so many vals to push.

In my initial feature request I mentioned keepalive_interval_avp and
keepalive_method_avp - while the naming could be subject to discussions
those should be the only two required AVPs to satisfy the proposed
enhancements.

It seems that we agree on the interval-part - this would allow to
use a not-so-frequent default interval (saving ressources) and grant
the option to make it more "aggressive" for users having issues with
the default setting.

As you asked for real-world example for the "per-user-ping-type"
feature request: while preparing our new VoIP platform I've switched
to nat_traversal and configured NOTIFY, as it seemed to be the more
elegant variant.

This went well, unless I've met problems with some UACs (tested AVM,
Snom, Grandsteam - don't remember which one had the problem) behind
an enterprise firewall (Nokia Checkpoint or Juniper Netscreen, both
cluster installations - don't remember even here which one it has
been). There have no longer been no replies to my NOTIFY, I switched
to OPTIONS and it worked.

I must confess that I didn't try to find out who caused the problem
(ALG or UAC) - I've just seen issues with NOTIFY and opted for the
second option (OPTIONS). Nonetheless I would welcome the possibility
to switch back to NOTIFY and use OPTIONS just where I encounter
problems.

Best regards,
Thomas Gelf



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Dan Pascu
In reply to this post by Bogdan-Andrei Iancu

On 11 Jun 2009, at 14:13, Bogdan-Andrei Iancu wrote:

>> I explicitly did not implement UDP pings, because over 40% of the  
>> routers out there will not keep the NAT open if they do not receive  
>> something from inside the NAT. As a consequence UDP pings are  
>> useless with those devices and unfortunately you cannot know which  
>> work and which don't. While UDP pings are cheaper and thus more  
>> appealing, in their case it applies the rule that you get what you  
>> pay for.
>
> I agree with you - to be honest I'm using only SIP ping ....so  
> should we obsolete the UDP ping :) ?

I think we should.

--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Dan Pascu
In reply to this post by Thomas Gelf

On 11 Jun 2009, at 14:46, Thomas Gelf wrote:

> As you asked for real-world example for the "per-user-ping-type"
> feature request: while preparing our new VoIP platform I've switched
> to nat_traversal and configured NOTIFY, as it seemed to be the more
> elegant variant.
>
> This went well, unless I've met problems with some UACs (tested AVM,
> Snom, Grandsteam - don't remember which one had the problem) behind
> an enterprise firewall (Nokia Checkpoint or Juniper Netscreen, both
> cluster installations - don't remember even here which one it has
> been). There have no longer been no replies to my NOTIFY, I switched
> to OPTIONS and it worked.

Hmm. Up to now I haven't encountered any device that doesn't reply to  
a request. If it doesn't understand it, it should at least reply with  
"Not supported". Having devices that completely ignore a request is  
bad for communication, because you cannot discern between the case  
where the device is not accessible anymore or it's just not willing to  
reply.

> I must confess that I didn't try to find out who caused the problem
> (ALG or UAC) - I've just seen issues with NOTIFY and opted for the
> second option (OPTIONS). Nonetheless I would welcome the possibility
> to switch back to NOTIFY and use OPTIONS just where I encounter
> problems.


There are some problems I see with your proposal:

1. It adds little value to the solution, but increases a lot the need  
to provision, monitor and manage this per device. This is a background  
activity and one should not need to manually configure it too much or  
at all. It should simply work as automatically as possible.

2. Sending pings with different methods may require different headers  
to be present. So it is not enough to just specify the method. It  
should rather have a few available profiles and let you choose from  
them.


IMO, a better solution would be to make it adaptive. It could monitor  
the replies and if it doesn't get a reply for a ping it can switch to  
use the other method for that particular endpoint. For example the  
first time the proxy has to send a ping to a newly added endpoint, it  
should send both a NOTIFY and an OPTIONS. If it gets a reply for both,  
it will use whatever the module is configured to use by default. If it  
only gets a reply for one of them, it will use that no matter what the  
module uses by default.


--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Thomas Gelf
Dan Pascu wrote:
> Hmm. Up to now I haven't encountered any device that doesn't reply to  
> a request. If it doesn't understand it, it should at least reply with  
> "Not supported". Having devices that completely ignore a request is  
> bad for communication, because you cannot discern between the case  
> where the device is not accessible anymore or it's just not willing to  
> reply.

Bad for communication -> it is. And I always thought the SIP universum
would be a perfect one ;-) However it was not necessarily the device's
fault - those ALG where both more than braindead :-(

> .. This is a background activity and one should not need to manually
> configure it too much or at all. It should simply work as automatically
> as possible.

Full ack!! As long as it doesn't do "everything" automatically managing
this "manually" is possible solely for small setups with just a few
thousand accounts (like ours) - of if your backoffice allows experienced
customers to manually adjust such settings, BUT:

> IMO, a better solution would be to make it adaptive. It could monitor  
> the replies and if it doesn't get a reply for a ping it can switch to  
> use the other method for that particular endpoint. For example the  
> first time the proxy has to send a ping to a newly added endpoint, it  
> should send both a NOTIFY and an OPTIONS. If it gets a reply for both,  
> it will use whatever the module is configured to use by default. If it  
> only gets a reply for one of them, it will use that no matter what the  
> module uses by default.

That would be absolutely great! It would for sure be more work for you,
but I would STRONGLY opt for this variant - great proposal!

Cheers,
Thomas Gelf


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu
Migration from nathelper? What's this you say?  :)


Can you for us "users" out here explain the implication of a new "nathelper"? Is nat_traveral intended to replace nathelper?  What's new? Am I jumping the gun asking these questions? :)

Thanks!
-Brett


On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Dan, what about this? this will accelerate the migration from nathelper
to nat_tranversal module, what do you say?

As time as it is not technical nightmare (from implementation point of
view), this feature make sense to me.

Regards,
Bogdan

Thomas Gelf wrote:
> I would also like to take occasion to propose a new feature: adding a
> parameter named "keepalive_interval_avp", allowing to set individual
> keepalive intervals for customers with special needs.
>
> Also "keepalive_method_avp" would be a useful addition. Both changes
> would probably require modifications to keepalive_state_file and
> corresponding internal structures, but I think this could be solved
> in a backward-compatible manner.
>
> Best regards,
> Thomas Gelf
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Bogdan-Andrei Iancu
let's keep the guns away :D.....

There is an older plan (since almost 1 year) of refurbishing the NAT
related traversal modules:
    nat_traversal module will be responsible for signalling part (ping +
mangling)
    mediaproxy and nathelper (future rtpproxy) will offer the
interfacing to the media relays...

The idea is:
    1) nat_traversal has more features on pinging area - can do pinging
without registration, simply monitoring presence and call sessions
    2) to avoid code duplicity between nathelper and mediaproxy (nat
tests, contact changing, etc)

so far there was no action in this direction.

Regards,
Bogdan

Brett Nemeroff wrote:

> Migration from nathelper? What's this you say?  :)
>
>
> Can you for us "users" out here explain the implication of a new
> "nathelper"? Is nat_traveral intended to replace nathelper?  What's
> new? Am I jumping the gun asking these questions? :)
>
> Thanks!
> -Brett
>
>
> On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Dan, what about this? this will accelerate the migration from
>     nathelper
>     to nat_tranversal module, what do you say?
>
>     As time as it is not technical nightmare (from implementation point of
>     view), this feature make sense to me.
>
>     Regards,
>     Bogdan
>
>     Thomas Gelf wrote:
>     > I would also like to take occasion to propose a new feature:
>     adding a
>     > parameter named "keepalive_interval_avp", allowing to set individual
>     > keepalive intervals for customers with special needs.
>     >
>     > Also "keepalive_method_avp" would be a useful addition. Both changes
>     > would probably require modifications to keepalive_state_file and
>     > corresponding internal structures, but I think this could be solved
>     > in a backward-compatible manner.
>     >
>     > Best regards,
>     > Thomas Gelf
>     >
>     >
>     > _______________________________________________
>     > Users mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>     >
>
>
>     _______________________________________________
>     Users mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Thomas Gelf
In reply to this post by Brett Nemeroff
Hi Brett,

I'm responding being just a "user", so please don't trust my words too
much ;-) Afaik nat_traversal is an approach to move keepalive methods
to a single module, and let rtpproxy (currently: nathelper) and media-
proxy do what there name says: being just an RTP (media) proxy.

At the times where there was one single OpenSER project there might
also have been some personal preference regarding one or the other
module - and not everybody seemed to be amused to remove functionality
from the nathelper/rtpproxy combo.

Personally I consider nat_traversal's keep-alive mechanism far better
than the one provided with rtpproxy. I started three threads some day
ago, all of them around this topic. My intention was to initiate some
discussion / brainstorming - as the status quo is confusing, migration
in a good direction has been started a while ago, but now this movement
seems to have fallen asleep.

Imo we should figure out:

- whether there are still keepalive-features in nathelper, that are
  missing in nat_traversal (so far I found only what I mentioned in
  my thread "Comparing client_nat_test with nat_uac_test"

- if there is some k.o. criteria forbidding us to rename the nathelper
  module to "rtpproxy" and remove the keepalive functions

As told before, I'm not involved in development, just trying to make
suggestion from my position as "OpenSIP user" ;-)

Cheers,
Thomas


Brett Nemeroff wrote:

> Migration from nathelper? What's this you say?  :)
>
>
> Can you for us "users" out here explain the implication of a new
> "nathelper"? Is nat_traveral intended to replace nathelper?  What's new?
> Am I jumping the gun asking these questions? :)
>
> Thanks!
> -Brett
>
>
> On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Dan, what about this? this will accelerate the migration from nathelper
>     to nat_tranversal module, what do you say?
>
>     As time as it is not technical nightmare (from implementation point of
>     view), this feature make sense to me.
>
>     Regards,
>     Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Thomas Gelf
In reply to this post by Bogdan-Andrei Iancu
I've overseen that you already replied...

Bogdan-Andrei Iancu wrote:
> ... The idea is:
>     1) nat_traversal has more features on pinging area - can do pinging
> without registration, simply monitoring presence and call sessions
>     2) to avoid code duplicity between nathelper and mediaproxy (nat
> tests, contact changing, etc)
>
> so far there was no action in this direction.

IMO it would be worth to re-animate this plan, don't you think so?

Cheers,
Thomas


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Feature-request: AVPs for nat_traversal

Bogdan-Andrei Iancu
Thomas Gelf wrote:

> I've overseen that you already replied...
>
> Bogdan-Andrei Iancu wrote:
>  
>> ... The idea is:
>>     1) nat_traversal has more features on pinging area - can do pinging
>> without registration, simply monitoring presence and call sessions
>>     2) to avoid code duplicity between nathelper and mediaproxy (nat
>> tests, contact changing, etc)
>>
>> so far there was no action in this direction.
>>    
>
> IMO it would be worth to re-animate this plan, don't you think so?
>  
We can start filling in :
http://www.opensips.org/Development/Nattraversal

with a migration plan.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users