Re: [asterisk-users] How to have callers not being billed when in waiting queue ?
Hi, in Germany, this kind of regulation is in effect for phone numbers which cost more than a normal landline call. The regulation states, that the waiting time must not be charged to the customer. Most companies implemented this by simply switching their telephone numbers to those, which are charged per call (so there's no difference in price between waiting for someone to pick up or being connected to someone) ;-) Or they decided to use a normal landline phone number for which this regulation does not apply. The second method was to not answer the call before really connected to a person on the queue and using Early Media as you mentioned. But: The maximum length of this Early Media stream is in most telephone networks limited to somewhat around 90 to 180 seconds, then the call gets disconnected by the network. I'm not very familiar with regulations and numbering plans in France, but maybe there's also something called "offline billing". Using this, your call is not billed by the caller's telephone company until you send them the amount of time that should be billed for a specific call. Your best choice will be, that - if you ever get those regulations - you should rely on what your telephone number provider tells you to do ;-) Greetings Max Am 28.03.2017 um 15:24 schrieb Olivier: > Hello, > > In France, years ago, there was some discussions about a new regulation > forcing some providers to not charge anything to callers while those are > waiting for a call center agent to become available. > Once caller and agent are on call with each other, nominal charging applies. > > No matter if those discussions ever did or didn't change current regulation, > I wonder which dialplan statements could technically comply this dual billing > requirement ? > > > same = n,Progress() > same = n,Queue(whatever,...,macro-option, ...) > > To me, coupling Progress app with Queue's macro or gosub option like above, > would let a sysadmin answer a queued call. > Doing so, time spent before connection with queue agent should not be billed > to anyone (caller nor callee), while time spent after connection is billed > normaly. > > 1. Should this work ? Am I missing something ? > > 2. Is there an alternative way to implement this ? > > 3. Comments ? Suggestions ? > > Regards > > signature.asc Description: OpenPGP digital signature -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SipVicious scans getting through iptables firewall - but how?
OK, I understand, Clever - I didn't know anything could read packets before iptables. And sorry about the formatting - I tried to make it all neat, but it looks like it got excessively word wrapped. Thanks for putting my mind at ease. On 28 March 2017 at 16:12, Andres wrote: > On 3/28/17 9:32 AM, Jonathan H wrote: > >> My firewall and asterisk pjsip config only has "permit" options for my >> ITSP's (SIP trunk) IPs. >> >> Here's the script that sets it up. >> >> -- >> #!/bin/bash >> EXIF="eth0" >> >> /sbin/iptables --flush >> /sbin/iptables --policy INPUT DROP >> /sbin/iptables --policy OUTPUT ACCEPT >> /sbin/iptables -A INPUT -i lo -j ACCEPT >> /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >> /sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP >> /sbin/iptables -A INPUT -f -j DROP >> /sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j REJECT >> /sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP >> >> # Voipfone >> /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s >> 195.189.173.0/24 -j ACCEPT >> /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s >> 195.189.173.0/24 -j ACCEPT >> /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s >> 46.31.225.0/24 -j ACCEPT >> /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s >> 46.31.225.0/24 -j ACCEPT >> /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s >> 46.31.231.0/24 -j ACCEPT >> /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s >> 46.31.231.0/24 -j ACCEPT >> >> # my SSH >> /sbin/iptables -A INPUT -p tcp --dport 22XXX -m conntrack --ctstate >> NEW,ESTABLISHED -j ACCEPT >> /sbin/iptables -A OUTPUT -p tcp --sport 22XXX -m conntrack --ctstate >> ESTABLISHED -j ACCEPT >> >> # HTTP >> /sbin/iptables -A INPUT -p tcp --dport 8443 -m conntrack --ctstate >> NEW,ESTABLISHED -j ACCEPT >> /sbin/iptables -A OUTPUT -p tcp --sport 8443 -m conntrack --ctstate >> ESTABLISHED -j ACCEPT >> >> >> # Allow icmp input so that people can ping us >> /sbin/iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW -j >> ACCEPT >> >> # Log then drop any packets that are not allowed. You will probably >> want to turn off the logging >> # /sbin/iptables -A INPUT -j LOG >> /sbin/iptables -A INPUT -j REJECT >> >> -- >> >> Then one day, sngrep was running in the background, and I noticed lots >> of these... >> > ngrep and tcpdump will show you packets before they reach iptables, so you > can see attacks like below. > You should not see responses if the firewall is working and I don't see > any responses below so you > should be safe. > > >> >> OPTIONS sip:50901@46.101.X.X SIP/2.0 >> 163.172.210.65:508946.101.X.X:5060 │Via: >> SIP/2.0/UDP 127.0.1.1:5089;branch=z9hG4bK-786048925;rport >>──┬─ ──┬─│Content-Length: >> 0 >> │ OPTIONS │ │From: >> "sipvicious";tag=32653635303466303133633401 >> 32333439343631383137 >>13:26:10.350316 │ ──> │ │Accept: >> application/sdp >> │ │ >> │User-Agent: friendly-scanner >> │ │ │To: >> "sipvicious" >> │ │ │Contact: >> sip:50901@127.0.1.1:5089 >> │ │ │CSeq: 1 >> OPTIONS >> │ │ │Call-ID: >> 67968489840845542823418 >> │ │ >> │Max-Forwards: 70 >> >> [ ] 4OPTIONS100@1.1.1.1 100@1.1.1.1 >> 1 163.172.210.65:508946.101.X.X:5060 >> [ ] 5OPTIONS100@1.1.1.1 100@1.1.1.1 >> 1 89.163.242.118:508946.101.X.X:5060 >> [ ] 6OPTIONS100@1.1.1.1 100@1.1.1.1 >> 1 142.54.162.58:5061 46.101.X.X:5060 >> [ ] 7OPTIONS100@1.1.1.1 100@1.1.1.1 >> 1 95.211.197.176:506546.101.X.X:5060 >> >> >> - >> >> This is what nmap from a remote machine can see: >> >> Not shown: 65534 filtered ports >> PORT STATE SERVICE >> 22XXX/tcp open unknown >> 8443/tcp open https-alt >> >> -- >> >> How are these SipVicious probes getting through? Clearly the firewall >> is misconfigured.. or maybe not? >> I'm not seeing these warnings in Asterisk of course, as it's not >> listening on these other ports. >> >> Together with the allow/deny pjsip settings, I *think* I'm reasonably >> safe? >> >> What bothers me is that don't understand how/why this is happening. >> And that makes me nervous! >> >> Thanks. >> >> > > -- > Andres > > -- > _
Re: [asterisk-users] SipVicious scans getting through iptables firewall - but how?
On 3/28/17 9:32 AM, Jonathan H wrote: My firewall and asterisk pjsip config only has "permit" options for my ITSP's (SIP trunk) IPs. Here's the script that sets it up. -- #!/bin/bash EXIF="eth0" /sbin/iptables --flush /sbin/iptables --policy INPUT DROP /sbin/iptables --policy OUTPUT ACCEPT /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP /sbin/iptables -A INPUT -f -j DROP /sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j REJECT /sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # Voipfone /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 195.189.173.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 195.189.173.0/24 -j ACCEPT /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 46.31.225.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 46.31.225.0/24 -j ACCEPT /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 46.31.231.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 46.31.231.0/24 -j ACCEPT # my SSH /sbin/iptables -A INPUT -p tcp --dport 22XXX -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport 22XXX -m conntrack --ctstate ESTABLISHED -j ACCEPT # HTTP /sbin/iptables -A INPUT -p tcp --dport 8443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport 8443 -m conntrack --ctstate ESTABLISHED -j ACCEPT # Allow icmp input so that people can ping us /sbin/iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW -j ACCEPT # Log then drop any packets that are not allowed. You will probably want to turn off the logging # /sbin/iptables -A INPUT -j LOG /sbin/iptables -A INPUT -j REJECT -- Then one day, sngrep was running in the background, and I noticed lots of these... ngrep and tcpdump will show you packets before they reach iptables, so you can see attacks like below. You should not see responses if the firewall is working and I don't see any responses below so you should be safe. OPTIONS sip:50901@46.101.X.X SIP/2.0 163.172.210.65:508946.101.X.X:5060 │Via: SIP/2.0/UDP 127.0.1.1:5089;branch=z9hG4bK-786048925;rport ──┬─ ──┬─│Content-Length: 0 │ OPTIONS │ │From: "sipvicious";tag=3265363530346630313363340132333439343631383137 13:26:10.350316 │ ──> │ │Accept: application/sdp │ │ │User-Agent: friendly-scanner │ │ │To: "sipvicious" │ │ │Contact: sip:50901@127.0.1.1:5089 │ │ │CSeq: 1 OPTIONS │ │ │Call-ID: 67968489840845542823418 │ │ │Max-Forwards: 70 [ ] 4OPTIONS100@1.1.1.1 100@1.1.1.1 1 163.172.210.65:508946.101.X.X:5060 [ ] 5OPTIONS100@1.1.1.1 100@1.1.1.1 1 89.163.242.118:508946.101.X.X:5060 [ ] 6OPTIONS100@1.1.1.1 100@1.1.1.1 1 142.54.162.58:5061 46.101.X.X:5060 [ ] 7OPTIONS100@1.1.1.1 100@1.1.1.1 1 95.211.197.176:506546.101.X.X:5060 - This is what nmap from a remote machine can see: Not shown: 65534 filtered ports PORT STATE SERVICE 22XXX/tcp open unknown 8443/tcp open https-alt -- How are these SipVicious probes getting through? Clearly the firewall is misconfigured.. or maybe not? I'm not seeing these warnings in Asterisk of course, as it's not listening on these other ports. Together with the allow/deny pjsip settings, I *think* I'm reasonably safe? What bothers me is that don't understand how/why this is happening. And that makes me nervous! Thanks. -- Andres -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] SipVicious scans getting through iptables firewall - but how?
My firewall and asterisk pjsip config only has "permit" options for my ITSP's (SIP trunk) IPs. Here's the script that sets it up. -- #!/bin/bash EXIF="eth0" /sbin/iptables --flush /sbin/iptables --policy INPUT DROP /sbin/iptables --policy OUTPUT ACCEPT /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP /sbin/iptables -A INPUT -f -j DROP /sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j REJECT /sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # Voipfone /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 195.189.173.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 195.189.173.0/24 -j ACCEPT /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 46.31.225.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 46.31.225.0/24 -j ACCEPT /sbin/iptables -A INPUT -p tcp -i $EXIF -m state --state NEW -s 46.31.231.0/24 -j ACCEPT /sbin/iptables -A INPUT -p udp -i $EXIF -m state --state NEW -s 46.31.231.0/24 -j ACCEPT # my SSH /sbin/iptables -A INPUT -p tcp --dport 22XXX -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport 22XXX -m conntrack --ctstate ESTABLISHED -j ACCEPT # HTTP /sbin/iptables -A INPUT -p tcp --dport 8443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport 8443 -m conntrack --ctstate ESTABLISHED -j ACCEPT # Allow icmp input so that people can ping us /sbin/iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW -j ACCEPT # Log then drop any packets that are not allowed. You will probably want to turn off the logging # /sbin/iptables -A INPUT -j LOG /sbin/iptables -A INPUT -j REJECT -- Then one day, sngrep was running in the background, and I noticed lots of these... OPTIONS sip:50901@46.101.X.X SIP/2.0 163.172.210.65:508946.101.X.X:5060 │Via: SIP/2.0/UDP 127.0.1.1:5089;branch=z9hG4bK-786048925;rport ──┬─ ──┬─│Content-Length: 0 │ OPTIONS │ │From: "sipvicious";tag=3265363530346630313363340132333439343631383137 13:26:10.350316 │ ──> │ │Accept: application/sdp │ │ │User-Agent: friendly-scanner │ │ │To: "sipvicious" │ │ │Contact: sip:50901@127.0.1.1:5089 │ │ │CSeq: 1 OPTIONS │ │ │Call-ID: 67968489840845542823418 │ │ │Max-Forwards: 70 [ ] 4OPTIONS100@1.1.1.1 100@1.1.1.1 1 163.172.210.65:508946.101.X.X:5060 [ ] 5OPTIONS100@1.1.1.1 100@1.1.1.1 1 89.163.242.118:508946.101.X.X:5060 [ ] 6OPTIONS100@1.1.1.1 100@1.1.1.1 1 142.54.162.58:5061 46.101.X.X:5060 [ ] 7OPTIONS100@1.1.1.1 100@1.1.1.1 1 95.211.197.176:506546.101.X.X:5060 - This is what nmap from a remote machine can see: Not shown: 65534 filtered ports PORT STATE SERVICE 22XXX/tcp open unknown 8443/tcp open https-alt -- How are these SipVicious probes getting through? Clearly the firewall is misconfigured.. or maybe not? I'm not seeing these warnings in Asterisk of course, as it's not listening on these other ports. Together with the allow/deny pjsip settings, I *think* I'm reasonably safe? What bothers me is that don't understand how/why this is happening. And that makes me nervous! Thanks. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] How to have callers not being billed when in waiting queue ?
Hello, In France, years ago, there was some discussions about a new regulation forcing some providers to not charge anything to callers while those are waiting for a call center agent to become available. Once caller and agent are on call with each other, nominal charging applies. No matter if those discussions ever did or didn't change current regulation, I wonder which dialplan statements could technically comply this dual billing requirement ? same = n,Progress() same = n,Queue(whatever,...,macro-option, ...) To me, coupling Progress app with Queue's macro or gosub option like above, would let a sysadmin answer a queued call. Doing so, time spent before connection with queue agent should not be billed to anyone (caller nor callee), while time spent after connection is billed normaly. 1. Should this work ? Am I missing something ? 2. Is there an alternative way to implement this ? 3. Comments ? Suggestions ? Regards -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Questions regarding Dial's D option
Hello, I'm currently playing with Application Dial D option. This option is documented with: D([called][:calling[:progress]]): Send the specified DTMF strings *after* the called party has answered, but before the call gets bridged. The DTMF string is sent to the called party, and the DTMF string is sent to the calling party. Both arguments can be used alone. If is specified, its DTMF is sent to the called party immediately after receiving a 'PROGRESS' message. See 'SendDTMF' for valid digits. My questions are: 1. Shall I expect those DTMF to be logged (in dtmf logs) with lines such as the one bellow ? In my testing, it doesn't seem to be the case. [2017-03-28 12:25:03] DTMF[9943][C-0041]: channel.c:4103 __ast_read: DTMF begin '#' received on PJSIP/Foobar-004e 2. When my Dial call contains D(#::) option, I'm reading this in Asterisk console: -- Sending DTMF '#' to the called party. When my Dial call contains D(#::progress) option, I'm reading this in Asterisk console: -- Sending DTMF 'progress' to the called party as result of receiving a PROGRESS message. What is the proper way to send to called party, a DTMF sequence when Progress tone is received ? Would you rate "Sending DTMF 'progress' to the called party as result of receiving a PROGRESS message" as misleading or not ? 3. The service I'm testing the above things with, works this way: - you dial the service number, - caller hear an announcement like "next time, to skip legal announcement, type #", - if caller effectively dials #, the rest of the announcement is skipped, - call is answered - caller is then welcomed with another message and things go on. My understanding is: - whatever is done before call is answered is never billed - as such, providers are likely to forbid anything (either voice or DTMF) to be sent from caller to callee before call's answering. Do you agree ? Best regards -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
