In the asymmetric case, if the registration is established with a long duration, and for some reason if IP-PBX crashes before the registration expires, then SP n/w will not know about it until the registration expires, or it tries to send a request to that PBX. If the registration interval is short, then this becomes similar to using short registration intervals to keep nat bindings open.
Sanjay >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Jeroen van Bemmel >Sent: Wednesday, June 25, 2008 5:56 PM >To: Christer Holmberg >Cc: [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]; [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
