> There are a lot of good reasons of not using STUN but there are no good
> reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely
> easy to implement. It is possible to verify packet validity and it can be
> used to detect local IP change.
Do you know any implementation (=p
On Mon, Dec 17, 2018 at 9:29 AM Philipp Schöning
wrote:
> >
> >
> > If UDP is used for transport, empty UDP packets can be sent to keep the
> >> NAT-binding alive.
> >>
> >
> > Sending empty UDP is not standard complaint. Sending a STUN binding
> > request, as described in
> https://tools.ietf.or
>
>
> If UDP is used for transport, empty UDP packets can be sent to keep the
>> NAT-binding alive.
>>
>
> Sending empty UDP is not standard complaint. Sending a STUN binding
> request, as described in https://tools.ietf.org/html/rfc5626#section-3.5.2
> is safer.
>
This is not an option, if you ar
There is no need to send REGISTER-Requests this often.
This will generate unnecessary load on the application level.
If UDP is used for transport, empty UDP packets can be sent to keep the
NAT-binding alive.
When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to
keep the NAT-bindi
On Thu, Nov 29, 2018 at 5:36 PM Alex Balashov
wrote:
> On Thu, Nov 29, 2018 at 05:35:19PM -0500, Roman Shpount wrote:
> Now that the philosophical question is out of the way, what's the right
> SIP response? ;-)
>
>
480 (Temporarily Unavailable) with Retry-After header.
You should also implement
On Thu, Nov 29, 2018 at 5:23 PM Alex Balashov
wrote:
> Yep, we agree. So the question is what the safest response would be to
> send for the largest number of endpoints, such that they don't mark the
> trunk as being out of service/decide that the gateway is permanently
> unreachable, and actuall
On Thu, Nov 29, 2018 at 05:35:19PM -0500, Roman Shpount wrote:
> Some applications do not support keep alive, so it is up to you to
> either not support such devices or handle frequent REGISTER messages
> gracefully.
Our position is to not support such devices.
Now that the philosophical questio
On Thu, Nov 29, 2018 at 4:49 PM Philipp Schöning
wrote:
> There is no need to send REGISTER-Requests this often.
> This will generate unnecessary load on the application level.
>
Some applications do not support keep alive, so it is up to you to either
not support such devices or handle frequent
Yep, we agree. So the question is what the safest response would be to
send for the largest number of endpoints, such that they don't mark the
trunk as being out of service/decide that the gateway is permanently
unreachable, and actually re-register as their binding comes up for
renewal.
On Thu, N
There is no need to send REGISTER-Requests this often.
This will generate unnecessary load on the application level.
If UDP is used for transport, empty UDP packets can be sent to keep the
NAT-binding alive.
When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to
keep the NAT-bindi
On Thu, Nov 29, 2018 at 2:44 PM Alex Balashov
wrote:
> On Thu, Nov 29, 2018 at 02:42:26PM -0500, Roman Shpount wrote:
>
> > Some devices do this to keep a pinhole in NAT firewall open. Pleases see
> if
> > you can enable keep-alive on your proxy and the device for the same
> purpose
> > (https://
On Thu, Nov 29, 2018 at 02:42:26PM -0500, Roman Shpount wrote:
> Some devices do this to keep a pinhole in NAT firewall open. Pleases see if
> you can enable keep-alive on your proxy and the device for the same purpose
> (https://tools.ietf.org/html/rfc5626#section-3.5).
Yep, they may. But a few
On Thu, Nov 29, 2018 at 2:33 PM Alex Balashov
wrote:
> I have a SIP registrar with a policy-based registration interval floor
> of 60 seconds.
>
> One would expect that this means most devices would register with such
> an expiry time, and then refresh the registration a few seconds before
> it e
Hi,
I have a SIP registrar with a policy-based registration interval floor
of 60 seconds.
One would expect that this means most devices would register with such
an expiry time, and then refresh the registration a few seconds before
it expires.
However, there are numerous endpoints out there wh
14 matches
Mail list logo
