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
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
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 time
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 me
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-And
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 th
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
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
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 ;-) Seriousl
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
>>> achi
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 existin
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
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
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 occasio
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
15 matches
Mail list logo
