Hi, >We're mixing different cases here. The 3GPP non-register emergency call >scenario is for an endpoint, I was talking about >the proxy-to-proxy case (I believe the 3GPP case can be addressed using >standard mechanisms available today, it's only >about authorization policies and identification of what calls are emergency >calls). > >It doesn't make sense for a proxy to keep-alive connections with arbitrary >other proxies. Either it has a limited set of >peers (such as in case of an IP-PBX peering with a service provider), or it >routes using DNS based on the domain in the >request URI (or top Route header). >For the latter case, the act of sending the INVITE itself will detect >reachability. > >So I suggest to limit the proxy-to-proxy use-case for keep-alive to proxies >that route towards a limited set of next hops >(instead of DNS on domain). According to RFC3261, such proxies would insert a >Route header (with loose routing)
Ok. Thanks for the clarification. So, if I understand you correctly you either: 1. Propose that proxy-to-proxy should not be part of the scope of the draft 2. Proxy-to-proxy could be part of the scope of the draft, but we would not necessarily use the same mechanism for UA-to-proxy and proxy-to-proxy. Correct? Regards, Christer Christer Holmberg wrote: > 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
