Jeroen,

Yes, this is effectively what you have when an IPPBX is required to register 
with a service provider. But in that case, there might also be a need to 
implement sip-outbound if there are unadministered NATs/firewalls in the way. 
Indeed, sip-outbound would operate between a virtual UA on the IPPBX side and a 
registrar on the service provider side.

What I am interested in gaining from this discussion is whether there are 
proxy-to-proxy cases where sip-outbound is not appropriate but keep-alive (or 
heartbeat) is needed.

John

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] 
> Sent: 25 June 2008 22:56
> To: Christer Holmberg
> Cc: Hadriel Kaplan; [EMAIL PROTECTED]; Elwell, John; 
> [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

Reply via email to