Hi, >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
There is a big difference. A UA will always send the requests via the outbound proxy, but a proxy can communicate with an unlimited number of other proxies. Those proxies are normally found (unless a service route exists) using DNS when the proxy receives a request to forward. >UEs that don't register: the idea is to make all such UEs register, so there'd >be no such case left As said earlier, at least 3GPP has a requirement for non-register emergency calls. Regards, Christer 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
