Christer,
The only solution I can think of that would give less processing, would
be to simply open a TCP connection (or UDP flow with STUN) without
sending any request. Less "overkill", but it would open up a bunch of
security issues ( e.g. TCP connection resources being consumed by
unauthorized elements, leading to DoS; all the concerns with STUNning
before checking support, etc. ). So I don't see how sending at least one
SIP request could be avoided. REGISTER is as good as any.
Which proxies to register with: that would of course have to be
provisioned somehow, this is no different from having to provision which
outbound proxy to use
UEs that don't register: the idea is to make all such UEs register, so
there'd be no such case left
Regards,
Jeroen
Christer Holmberg wrote:
Jeroen,
I don't understand what benefit it would be to establish outbound registrations between
all SIP entities that want to use the keep-alive/heartbeat. Yes, we would "re-use an
existing mechanism", but in my opinion it would really be an overkill,a hack - and
anything but keep-it-simple...
Also, how would the proxies know which proxies it should establish
registrations which?
Also, it wouldn't work in the use-case with UEs that don't register.
Regards,
Christer
-----Original Message-----
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED]
Sent: 26. kesäkuuta 2008 9:50
To: Hadriel Kaplan
Cc: Christer Holmberg; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[email protected]
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case
Hadriel,
I did not intend to suggest to use the registration interval timer for
keep-alive, of course all the regular flow keep-alive mechanisms of outbound
could be used.
The benefit is that we would reuse the efforts put in outbound, instead of
inventing yet another, only marginally different, mechanism for each specific
case. From the sending element point of view, sending a REGISTER isn't very
different from sending an OPTIONS; subsequent keep-alives can then become STUN
or double CRLF, until the registration needs to be refreshed.
Using REGISTER instead of OPTIONS also provides the means to use the standard
authentication mechanisms, besides reusing outbound (and there's a few other
reusable things, like Path headers, but let's keep it simple for the moment)
Regards,
Jeroen
Hadriel Kaplan wrote:
Hey Jeroen,
I'm not sure I follow you. The SIP Forum SIP-Connect profile, and now TISPAN,
make use of a REGISTER for an IP-PBX to register a whole set of AoR's to be
routed to. For those devices that need that ability, it makes sense to use
outbound of course, and its inherent keepalive, regardless of being behind a
NAT or not. And I don't think Christer's suggesting otherwise.
But for IP-PBX's or proxies which do not themselves represent an AoR target of
requests, or do not represent one in the domain of the device they want to
perform keepalive with, why would we want to make them add such registration
logic? What would be the gain over just simply sending OPTIONS at that point?
The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivial to
construct, trivial to parse, very small and fixed size, can be separated or
handled at a lower layer, explicit in its use, and does not get stopped by a
SIP-layer overload control. In short: it's a transport connection-layer
keepalive, no more no less. And indicating it in the Via keeps it a hop-link
thing, backwards-compatible, little or no provisioning, and with no URI target
addressing issues.
-hadriel
-----Original Message-----
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 5:56 PM
To: Christer Holmberg
Cc: Hadriel Kaplan; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy
use case
No, not a B2BUA. Each element would have a virtual UA function "in
parallel" to its regular function (e.g. being a proxy). And indeed,
one way to implement this would be to keep either one (one way) or
two (opposite ways) flows active between them.
Like so:
|-----------| |-----------|
| Proxy | | Proxy |
|-----------| |-----------|
| UA | <---------->| UA |
|-----------| |-----------|
Each "UA" would implement both a simple registrar and a UAC
performing registration. It could also be setup asymmetrically, with
the (smaller) IP-PBX doing a single registration towards the (bigger)
Service provider network. Registration expiry would denote a loss of connectivity.
Regards,
Jeroen
Christer Holmberg wrote:
Hi,
So, you are proposing that each element should be a B2BUA, and both
elements then register towards each other and use Outbound???
Regards,
Christer
-----Original Message-----
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED]
Sent: 25. kesäkuuta 2008 22:57
To: Hadriel Kaplan
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
lucent.com; [email protected]; Christer Holmberg
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy
use
case
Hadriel, Markus,
Instead of standardizing keep-alives between proxies, how about we
define a "virtual UA" on each element (similar to the one described
in
RFC3261 section 16.7 point 6) to be used to provide this functionality?
(using existing outbound functionality, perhaps both ways)
Regards,
Jeroen
Hadriel Kaplan wrote:
Yes I am of that same opinion - that any real "IP-PBX" or whatever
big enough NOT to be doing Registration, and to instead do static
provisioning or DNS, would be given a static hole/DMZ address in
their firewall/NAT. But some of my customers have told me otherwise.
(interestingly mostly in APAC region) There's also some concern that
while a static entry is there for inbound TCP connections, the PBX
creates outbound ones to the service provider which are ephemeral
port sources and need to live for very long durations (though why
they can't just do TCP keepalive is beyond me, but I'm no expert).
But anyway, the big issue we've seen is that we need both the PBX
and
the service provider box to detect failure before an active
call/request attempt is made; to trigger alternate route selection
without waiting for transport failure, and as a method to detect liveness again and revert.
Today that's almost exclusively done with Options requests as far as
I've seen, and lots of people don't seem to like that.
-hadriel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 3:11 PM
To: [EMAIL PROTECTED]; Hadriel Kaplan;
[EMAIL PROTECTED]; [email protected]
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip] Progress draft-holmberg-sip-keep:
proxy-to-proxy use case
Hi,
I'm a bit sceptical about the need for keep-alives between proxies.
It is of course entirely possible that an enterprise PBX is
connected to (or peering with) a service provider proxy through a
NAT and/or a firewall. However, wouldn't such a NAT or firewall be
under the administration of either the enterprise itself or its
ISP (who quite often would be the SIP service provider), and the
required port forwardings or firewall rules could be set through administration.
This means that there would not be need for keepalive traffic to
implicitely keep the mapping/pinhole open.
Or are there really deployment cases where there are SIP PBXs
behind unadministrated NATs or firewalls?
Wouldn't we then need keepalives for SMTP as well, or how has the
e-mail infrastructure managed to solve this problem?
Markus
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
