> From: Lawrence, Scott (BL60:9D30) > > On Fri, 2008-10-17 at 11:28 -0400, Steinmann, Martin > (BL60:2500) wrote: > > Let me propose the following resolution: > > > > a) We agree that we need source routing based on location for > > multi-branch deployments > > > > b) We agree that the main mechanism will be based on auto-detecting > > the current location on a per call basis > > > > c) We agree that sipXconfig will allow the specification of > a location > > for users and gateways and that this mechanism will be used if > > auto-detection is not possible > > > > d) We agree that this source routing mechanism is done per dialing > > rule, so that least cost routing for e.g. international calls still > > works based on called destination > > This problem with (d) is that we don't currently have any > explicit 'least-cost' routing. We just have routing - we > don't know which rules are for cost and which are for some > other reason. So (d) can't really be done at the moment.
If the dialplan rule was created with the intention of providing least-cost routing then the admin can turn off the source-based routing for that dialplan rule. See f). > > > e) We agree that it would be a nice to have feature to be able to > > manually control source routing on a per call basis using a DTMF > > feature code. Main use case is for debugging. The feature is turned > > off by default and only implemented if time permits. > > I strongly disagree with (e) > > > f) We agree that this source routing mechanism can be turn > on or off > > per dialing rule. > > See the problem with (d) above. > > > g) For remote workers who are not currently in a known location > > ordinary destination based dialing rules apply. > > I'm still not sure I understand how the IP-based location > discovery really works... until I do, I can't evaluate how > this applies. I tried to provide some information on the topic in one of my previous e-mails. This information is essentially provided by the NAT Traversal feature and is based on a few simplifying assumptions (that can be revised if needed). For more information, please refer to a sub-section called "Adding caller's topology information to Contact header" on page 8 of the NAT traversal design document found at http://sipxecs.sipfoundry.org/ViewVC/sipXecs/branches/merge_proxy/sipXpr oxy/doc/NAT-traversal/NAT_Traversal_Design_Doc.doc <snip> _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
