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
