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
