John,
The problem with "not appropriate" is that it's subjective and
ambiguous. I think we understand "not strictly needed" (or "overkill" as
some say), e.g. when there is no NAT device in between.
A case I can imagine where outbound wouldn't work, is if the proxies in
question are connected indirectly (i.e. not hop-by-hop). Then the
outbound keep-alive mechanism doesn't work, and you'd need some SIP
request instead (or some elaborate scheme to pass on keep-alive
information across multiple hops in some other way)
Regards,
Jeroen
Elwell, John wrote:
Jeroen,
Yes, this is effectively what you have when an IPPBX is required to register
with a service provider. But in that case, there might also be a need to
implement sip-outbound if there are unadministered NATs/firewalls in the way.
Indeed, sip-outbound would operate between a virtual UA on the IPPBX side and a
registrar on the service provider side.
What I am interested in gaining from this discussion is whether there are
proxy-to-proxy cases where sip-outbound is not appropriate but keep-alive (or
heartbeat) is needed.
John
-----Original Message-----
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED]
Sent: 25 June 2008 22:56
To: Christer Holmberg
Cc: Hadriel Kaplan; [EMAIL PROTECTED]; Elwell, John;
[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]; [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
