So far I have found http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx and this has clarified the question a little: it seems that Network Location Awareness (NLA) identifies the network differently and wants to assign a new (NLA) 'profile'. ... View more

Thanks Karthik.  Hi, yes all of the above are true, I believe.  The telco is Telstra, and the product is their ISDN10, which I believe uses an NI-2 type switch.  Their literature suggests that it is possible to subscribe to an ISDN-delivered transfer service like this.  (I will check all of this with them soon). But I would really like to know if it is feasible to instruct the NI-2 compliant switch to present the caller-ID of the transferee to the tranfer-to party? ... View more

Hmm, won't the original caller hear the DTMF sounds on the line?  Apart from that, I like this solution. Alternatively, I have located a whole bunch of information on doing redirects with TCBT (Two B-Channel Transfer) .  In that scenario, you can apparently tell the teclo switch to connect two call legs on the same ISDN trunk, even if the 2nd one is outbound (and even when the 2nd one is in the 'ringing' state, which is nice).  But it's not clear which Caller-ID will be presented to the eventual recipient of the call.  Do you have any experience with this? I'm asking around in the TclIVR community for some specifics on how to practically access this functionality in a script. thanks, David. ... View more

Yes, that would do.  The main point is not so much avoiding tying up the channels, but making sure that the eventual transferee has the original caller's number show up on caller-line-id.  (Although avoiding call redirection charges and 2 channels is a bonus). How does one typically invoke the TNT feature?  Is a TclIVR script indicated here, or is there some fancy things one can do with dial-peers? thanks, David. ... View more

Hi Steffen, I was going to call it a bug on 9.2.1 and get on with my life.  But if it's happening with later versions of everything for you, then I'll try to collect a few of my thoughts on it.  Maybe you will be motivated enough to chase it up. First, I'd triple-check checksums of phone firmware loads on the tftp flash, and your PC's downloads folder.  I was all in a muddle, but I might have seen a problem there.  It's a low likelihood, but quick to check. Secondly, I *know* that the phone doesn't even *attempt* to register, because I'm using both 'debug tftp server' (to know when I should expect the attempt to connect to port 2000) and 'debug ip tcp transaction' (to know if any such attempt is made).  Thridly, it's unsurprising that it never makes the attempt, since even though it fetched its configuration file (proven with 'debug tftp events') it still doesn't have an address for a CallManager. BUT, I *know* that my CNF files are 'right', because I fetched them myself with a TFTP client, and made sure that the section of the .cnf.xml file (ie. the same one the phone asked for) was good[1].  (I didn't run 'em through an XML validator yet tho', or comprehensively cross-reference if *all* the values in the XML file made it to their relevant spots in the phone's config). It seems for all the world like the phone *discards* the address of the CME server.  This characterisation is key to the problem I experienced.  Maybe the firmware has a dumb sense of what the CME server address 'ought' to be, or its view of the network is skewed by the particular phone it's on, or maybe the CME server address only gets read down one branch of the XML parsing code, or some other lame bug. I suppose if one were to draw a long bow, it could be an XML parsing bug when certain phone firmwares read certain .cnf.xml files made by certain CME versions.  If XML parser libraries were known to be phone-hardware-version-dependent, that'd be an interesting line of enquiry.  It'd be even more damning if more than just the CallManager parameters didn't make it to the phone.  Yes, this seems unlikely, but it's something which we can observe, alter, and test in black-box fashion ... by comparing .cnf.xml files that work/don't work, and differences in .cnf.xml files generated by various versions of CME, and by running them through an XML validator. Assuming the phone parses the .cnf.xml OK, then it's clear that the the phone firmware really is discarding the CallManager info for some reason.  If only we knew which reason! Ultimately, my guess is that it is something specific either to a batch of phone hardware, or (most likely) there is something about the way the phone is attached to the network, which the newer firmware is not expecting. My setup is:   6945's have MAC's in the range:  e8b7.48ee.2___   Attached to a Gi port on a SM-ES3G-24-P with 12.2(52)EX1 (ipbase)   Which in turn is enclosed by a CISCO2911/K9 with 15.2(3)T1   The Gi port configuration is typical from applying the cisco-phone macro: interface GigabitEthernet0/9 switchport access vlan 2 switchport mode access switchport voice vlan 100 switchport port-security maximum 2 switchport port-security switchport port-security aging time 2 switchport port-security violation restrict switchport port-security aging type inactivity srr-queue bandwidth share 10 10 60 20 queue-set 2 priority-queue out mls qos trust device cisco-phone mls qos trust cos auto qos voip cisco-phone macro description cisco-phone spanning-tree portfast spanning-tree bpduguard enable service-policy input AutoQoS-Police-CiscoPhone end In my scenario, my 3560 is routing for the phone's subnet (vlan 100), and thus the CME is not on on the same subnet as the phones themselves.  My sites were remote, and I wasn't in a position to alter the topology in this respect, but I'd be definitely trying it, if your topology is similar.  That's about all I've got, sorry.  Hopefully this triggers a thought and sends you down a useful diagnostic path.  Please report back if you crack it!  Maybe Cisco will pay us lots of money to be a QA team on CME.  :-P regards, David. [1]  Hmm, or did I just do a 'more flash://cme/blah.cnf.xml?  I can't get a 7912 phone working with CME 9.0 at the moment, because when the TFTP client tries to fetch the firmware, the automatic TFTP binding *times out*.   Maybe CME fusses with automatic bindings somehow, and the pre-tftp and post-tftp versions of the .cnf.xml file should be checked. ... View more

I have found a problem with option B1.  If I'm on R3 and try to ping R1, R1 has no route back to me, since by default the 'ping' command will use the interface nearest to the destination, and will thus us its IP address in the /30 address as the src of the IP packet. ip unnumbered looked like an interesting solution, at first.  But then, it only works on interface types which are NOT mulit-access, and Ethernet interfaces are multi-access.  So you can't "ip unnumbered" a Gi0/0 on a 2911 for example. Ultimately, only option B2 seems decent.  Based on pure instinct, I'm going to use a different IP address space for "router topology" versus "data topology" (ie. I think this is a good idea, but can't explain why yet).  So I'll pick some unrelated private address range and apply the usual hierarchical addressing principles.  My 'campuses' are small - I scarcely expect to have more than 2 routers and a diameter of 2 from the edge router at each branch. I could set aside 10.255.224.0/19 as my range for router addresses.   That gives me 13 bits to 'play with'.  So I'll break it up like this:    0000 0110  . 1111 1111  . 111s ssss . dddd ddrr where:    sssss:  is 32 sites    dddddd: up to 64 /30's per site    rr: 4 addrs: net, R1, R2, broadcast   Site 1 (sssss = 00000)       (ddd=000000)   -   0000 0110 . 1111 1111 . 1110 0000 . 0000 00xx = 10.255.224.0 /30       (ddd=000001)   -   0000 0110 . 1111 1111 . 1110 0000 . 0000 00xx = 10.255.224.4 /30       (ddd=000010)   -   0000 0110 . 1111 1111 . 1110 0000 . 0000 00xx = 10.255.224.8 /30       (etc) Site 2 (sssss = 00001)       (ddd=00000)    -   0000 0110 . 1111 1111 . 1110 0000 . 1000 00xx = 10.255.224.128 /30       (ddd=00001)    -   0000 0110 . 1111 1111 . 1110 0000 . 1000 01xx = 10.255.224.132 /30       (ddd=00010)    -   0000 0110 . 1111 1111 . 1110 0000 . 1000 01xx = 10.255.224.136 /30       (etc) Using this scheme, inter-site routes can be aggregated with a /24.  The 5 bits for 'ddddd' also allows some local aggregation at each site, if warranted. Athough there are now some additional entries in route tabes for the additional address range, I've gained something: some independence of the "routing infrastructure domain" and the "data traffic domain". ... View more

Hi Robert, Which SMB-series switches (eg. 300, 500) *do* support an ip-helper or DHCP relay feature? In my case, it's a design goal to keep chatty broadcast traffic off the wire to the server, so the vlan subinterface hack doesn't really help! cheers, David. ... View more

Which country are you from? If you have Number Portability regulations, you must be able to port these numbers. Other than that, you need an FXO gateway. Australia.  Regulations demand that we may retain local numbers when switching carriers, but don't demand that we can retain numbers when moving between telephone exchange areas.  http://www.dbcde.gov.au/mobile_services/number_portability I'm sure the carriers could do it if they chose, but they prefer to charge you for 'redirection fees' if they can get away with it. So how do I do an FXO gateway?  My guess so far: 1. Get a 2901 with a VIC-2FXO and the IOS UC Feature Set at BranchOffice 2. at BranchOffice, setup a dial-peer with port 0/0/0 and a voip dial peer with ipv4:addr.of.voxrouter.at.headoffice 3. (optionally, to place outward calls to the PSTN attached to BranchOffice) at HeadOffice, setup a voip dial-peer with ipv4:addr.of.voxrouter.at.branchoffice Is that the gist of it? thanks, David. ... View more