If they pretend to be a CO trunk, and simply dial a number, they want to be connected to something that provides talk battery and dialtone. Just pickup and dial, so they want an FXO port, not an FXS port.
I don't see, if this worked on an FXS sipx would provide callerid for the user portion. What you are doing here is the correct method for an FXO port. The Patton is the obvious choice to me, because it is highly configurable. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: [email protected] <[email protected]> To: Eric Varsanyi <[email protected]> Cc: sipXecs users <[email protected]> Sent: Tue Jan 26 00:09:11 2010 Subject: Re: [sipx-users] Patton caller ID mapping OK, with the clue injection that I could use a routing table in interface FXO I came up with this (which works and transforms the no-callerid call to a call from Lobby extension 270): interface fxo IF-FXO0 route call dest-table FXO0-TO-SIP disconnect-signal loop-break disconnect-signal busy-tone ring-number on-caller-id mute-dialing use profile tone-set US routing-table calling-e164 FXO0-TO-SIP route default dest-interface IF-SIP-PP FXO0-CID-FUNC complex-function FXO0-CID-FUNC execute 1 FXO0-CID-MAP-NAME execute 2 FXO0-CID-MAP-E164 mapping-table calling-name to calling-name FXO0-CID-MAP-NAME map ^$ to Lobby mapping-table calling-e164 to calling-e164 FXO0-CID-MAP-E164 map ^$ to 270 Instead of using a different routing table for each interface an optimization might be to have a single routing table which keys on called e164 (different doors ring different users in this case) and has a mapping function for each one. This is the only way to do it if all doors ring to the same hunt group as far as I can tell. These Patton boxes are great, complicated and feature rich but logical and easy to debug. -Eric Varsanyi On Jan 25, 2010, at 10:02 PM, Eric Varsanyi wrote: > These devices generate ring voltage and pretend to be an FXS. I thought > that sending ring voltage TO an FXS port would at best do nothing and at > worst blow it up (though unlikely unless both were glaring ring voltage at > each other). > > These doorphones do not look for dialtone then dial out, they pretend to > be a CO trunk line so they look like an inbound call to your PBX (they > provide ring voltage and talk battery): > http://www.vikingelectronics.com/products/view_product.php?pid=268 > (W1000A). > > I'll try the (now obvious) method of just routing to a table instead of an > interface then attaching the map to the table. Thanks! > > -Eric > > > On Jan 25, 2010, at 6:27 PM, Jim Canfield wrote: > >> On Mon, Jan 25, 2010 at 2:31 PM, Eric Varsanyi <[email protected]> wrote: >>> Thank you very much for the response. >>> >>> I would think I could have a different route table for each IF_FXO >>> interface that uses a different mapping table, the devil (for me) is >>> that the example config doesn't have any route table at all for IF_FXO >>> calls, the FXO interface just points right at the SIP interface -- so >>> I'm not sure how to attach the route. >> >> Just point IF_FXO to the table. >> >> interface fxo IF_FXO0 >> >> route call dest-table YOUR_TABLE >> disconnect-signal loop-break >> disconnect-signal busy-tone >> ring-number on-caller-id >> dial-after timeout 2 >> mute-dialing >> use profile tone-set US >> >> ..there is no rule that says you have to direct to an interface. >> >>> >>> Now that I know I'm on the right track at least I'll study the docs some >>> more (and probably ping Patton) and let you and the list know what I >>> come up with. >>> >> >> After thinking about this, it sounds like you have several in-house >> devices like 'Lobby' or 'Dock' It would be much cleaner if you used >> FXS ports and have them register as sip users rather than try and >> remap FXO ports. > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
