Hence what he is asking for is a call screening feature. Turn it on for a user, media server asks you to say your name, then rings you and plays the audio "who it is".
This is not an authorization thing, rather its a call screening feature. I imagine it would have to be inmplemented in the proxy as a service withing FS. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net 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: sipx-users-boun...@list.sipfoundry.org <sipx-users-boun...@list.sipfoundry.org> To: 'Matt White' <mwh...@thesummit-grp.com> Cc: sipx-users@list.sipfoundry.org <sipx-users@list.sipfoundry.org> Sent: Sat Aug 07 12:46:48 2010 Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet There is an analogy that works well here. Today, you can call any telephone number you want, ring the phone and hang up. This isn't much different, a user can use sip to call directly into a sip phone. And, as kids I think many of us can recall playing pranks on people over the phone - caller ID took the fun out of that. L Somebody ringing my PSTN phone can ring the phone, but they can't call out on it. Similarly, someone getting a two way audio path up with a SIP phone, can just do that, but can't call out. What I think Matt is proposing is a solution that says if you are calling one of the devices on my network, you need to have my permission to do so. Similar products have come on the market for the PSTN due to unsolicited calling that requires you to authenticate you are approved to call that PSTN number, before it would ring the telephone at the residence. Call blockers are what many call them. Example item - http://www.amazon.com/Caller-Phone-Ring-Control-Completed/dp/B0007R5TQ6/ref= sr_1_10?ie=UTF8&s=electronics&qid=1281199141&sr=8-10 If I'm understanding Matt correctly, he is suggesting a method of turning off the ability to ring a phone on your network randomly from the outside, or a method similar to the device that kept nuisance calls out. To me it is legitimate, as the last thing any business wants is some 10 year old hacker call all of the phones on the network playing "phone ring ditch". I agree with Matt, this isn't a protocol issue, but a method of controlling if each individual phone will participate in that portion of the protocol, or deny it explicitly. A URI access list comes to mind as well, saying I will accept incoming URI calls if they come from these domains, or these ranges of IP addresses. You could bounce unwanted URI calls to a common extension that had an announcement of a method to get permission to URL call into the system also. I think he brings up an excellent point that I hadn't considered. I'm sure someday I am going to get a call from a customer that they are getting prank calls that they want to end. Geez. From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Matt White Sent: Saturday, August 07, 2010 8:11 AM Cc: sipx-users@list.sipfoundry.org 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 9999...@sip.com 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 <tgrazi...@myitdepartment.net> 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: tgrazi...@myitdepartment.net 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: sipx-users-boun...@list.sipfoundry.org <sipx-users-boun...@list.sipfoundry.org> Cc: sipx-users@list.sipfoundry.org <sipx-users@list.sipfoundry.org> 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" <mstei...@gmail.com> 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> </mstei...@gmail.com> -- This email was Anti Virus checked by the Summit Technology Consulting Groups Astaro Security Gateway. http://www.astaro.com _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
