But what you describe is a user privacy feature. Internal calls provide full username/line. The callee can hit dnd, reject or ignore the call. That is internal to the proxy. If I am called from a site and a number in their huntgroup shows up instead of their mail pilot number, how will I get the information from them (what is every number you might ever call me from) and maintain it?
I'd also worry about scalability. The "9999999" example is a simple case of the proxy checking dialplan and permissions. CEO's are so out of touch in some companies. I guess if we allow them to screen all calls automatically it keeps them insulated so they can say "I don't recall that conversation senator...". Ha! So much for an open door policy and transparency! ============================ 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]> Cc: [email protected] <[email protected]> Sent: Sat Aug 07 11:10:53 2010 Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet I don't think any RFC changes are required at all. Invites are challenged all the time. Example, Ext 345 sends invite to sipxproxy for [email protected] sipxproxy responds "404 not authorized" Ext 345 resends invite with authorization header sipxproxy checks authorized.xml and process the call. The only difference is that sipxproxy does not require any authorization when the destination is an internal domain. But its a feature that could be implemented and would not only help with the scenario of out unwanted inbound calls not from the itsp, but also for the CEO that has a phone and doesn't want all employees to be able to call him. -M >>> Tony Graziano <[email protected]> 08/07/10 10:27 AM >>> Then you would have to invent an authorization rfc for an simple invite, which kind of breaks the intent of sip in a way. Invites from the internet to the proxy (port 5060) can only reach your system (AA, conferernce, media, users), not place calls. Itsp's require auth to send calls to them. Sipx proxy does the same for outbound calls. Sipx does not need permissions or registration internally to dial internal calls. The only thing lacking in sip overall is a monitor or auto "clamp" feature when excessive failed attempts occur (sipvicious), which also has a script to combat it. Email: hello I have an email for user 200. I don't have a user 200. Sip: I have a call for user 200, ok hold on I'll ring that for you. If there isn't a user 200, its a failed call. ============================ 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]> Cc: [email protected] <[email protected]> Sent: Sat Aug 07 10:04:02 2010 Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet Yeah, I knew that it would for remote workers by determine the SIPX-NONAT status , I guess I didn't realize it would for non registered sip UA like an inbound sip call. Makes me wonder how hard it would be to get SipXproxy to work with ITSP that must send to port 5060 instead of port 5080. If the ITSP doesn't use registration and can handle REFERS, then it would likely work even while bypassing sipxbridge. -M >>> "Martin Steinmann" <[email protected]> 08/07/10 9:58 AM >>> <o:shapedefaults v:ext="edit" spidmax="1026" /> <![endif]--> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout><![endif]-->The proxy handles NAT and anchors media. This is used forremote workers and happens automatically<o:p></o:p> --martin<o:p></o:p> <o:p></o:p> </[email protected]> -- This email was Anti Virus checked by the Summit Technology Consulting Groups Astaro Security Gateway. http://www.astaro.com _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
