On Thu, 2009-06-18 at 19:37 -0400, M. Ranganathan wrote: > On Thu, Jun 18, 2009 at 5:13 PM, Dale Worley<[email protected]> w
> I am not recommending rewriting working code but I don't see how any > system can get away from having to rewrite addresses to those that are > comprehensible by the other system. If the addresses that are in such > events are private, something has to re-write it. I assume that it is > being re-written somehwere by our current federation solution as well. > Yes I agree that there are a large number of cases to cover where > address translation needs to happen. I am pretty impressed that our > current solution for federating two autonomous sipx installations > actually supports a User Agent on one of those sytems being able to > subscribe to the dialog events of the other system. > > Another change that has to be made if we were to do this using > sipxbridge : night now sipxbridge never has to deal with forwarding > REFER and NOTIFY as the Transfer controller can reside on one system > and the calling party and transfer target can reside on the other > system. > > Needless to say all of this adds complexity to sipxbridge if we were > to implement a solution there while such a solution does solve name > clashes in SIP domain. If the problem has already been solved using > other means ( as our current remote worker solution does ) , we should > leave it as is. The bottom line is pretty simple - if you want to do SIP between domains, you MUST use real registered globally unique DNS names. That is not an unreasonably high bar. The whole '.local' (or other private) domain name concept is a convenient hack, but it's just that - a local hack. If you want traffic to work non-locally, don't use a private domain name. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
