This is what sip-outbound is for. John
> -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > Sent: 26 June 2008 05:03 > To: Jeroen van Bemmel; Christer Holmberg > Cc: [email protected]; [EMAIL PROTECTED]; Elwell, John; > [EMAIL PROTECTED] > Subject: RE: [Sip] Progress draft-holmberg-sip-keep: > proxy-to-proxy use case > > 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
