On Thu, Jun 18, 2009 at 5:13 PM, Dale Worley<[email protected]> wrote: > On Mon, 2009-06-15 at 16:48 -0400, M. Ranganathan wrote: >> The private domain ( sipx.example.local ) is never visible across systems. >
> > As you point out, From headers can be a problem. In theory, From > headers are almost documentation. But some phones use them as the URI > to call if the user applies "Call Back" to an entry from the "Received > Calls" list. And the P-Asserted-Identity mechanism assumes that if the > >From URI is that of a user on the local system, then the caller can > provide credentials for the local SIP domain. If one system's user URIs > look like the other system's user URIs, some careful coordination needs > to be done to avoid trouble with that test. Thanks for the detailed answer. If the first system used its public alias ( i.e. public address ) in its From header as many ITSPs do, then the other sipx to which the request is headed will see it as a foreign domain. > > The two systems will crate GRUUs that are difficult to distinguish, and > many elements will assume that their assigned GRUU is globally > comprehensible. > > And consider that dialog events will carry URIs from phones on one > system to phones on the other system -- does sipXbridge rewrite those > completely? No it does not because ITSPs are not sending subscribes for DIalog Events. 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. Regards, Ranga > > Etc... > > Dale > > > -- M. Ranganathan _______________________________________________ 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/
