Hi, Another thing.
As currently defined in the draft, when the "keep" parameter is used for non-registration calls (no matter whether it's UA-to-proxy or proxy-to-proxy) the duration is only for the lifetime of the call. When the "keep" parameter is used for registration calls, the duration is for the lifetime of the registration (as for Outbound). Regards, Christer -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christer Holmberg Sent: 26. kesäkuuta 2008 11:06 To: Jeroen van Bemmel Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case 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 _______________________________________________ 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
