Re: [OpenSIPS-Users] Weird behaviour in B2BUA with provisional media

[Johan De Clercq]

Opensips is not a full b2b, use something else for refer

On Thu, Dec 17, 2020, 12:25 Virgílio Cunha  wrote:

> Hello everyone,
>
> I have a problem in B2B behaviour with provisional media configured.
>
> In my scenario, I have a call to a call center that transfers the call
> (REFER) to another one. So, as I have a provisional media configured, a new
> SIP leg is generated by B2B between the user terminal and the media server
> until the call center answers it.
>
> Up to this point the call doesn't show any problem, but if the user
> terminal does a reINVITE to negotiate the SDP, I see weird behaviour.
>
> In the provisional media SIP leg, everything seems right. The media server
> answers to the reINVITE with 200 OK, but the 200 OK never was generated by
> B2B on the terminal SIP leg, instead of it I saw a new ACK forwarded to the
> user terminal (should be a 200 OK) and the B2B generates a new SIP leg to
> same call center referred previously.
>
> Why was a new SIP leg generated to the referred destination? If there's
> not any reinvite from the user terminal the REFER scenario doesn't have any
> problem.
>
> Does anyone know if this behavior was fixed in the latest version?
> Is there any additional configuration that I can do to fix this behaviour?
>
> I am currently using opensips 3.0.2.
>
> Best Regards,
> Virgílio Cunha
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour when replying to an OPTIONS with a Cseq of 0

[Karolis Pabijanskas]

Thanks. I will see if I can post the actual packet tomorrow.

The only reason the contact header has 127.0.0.1 is because this test
example is generated with sipp and ir is picking that off from [local_ip]
there. Even with an identical packet, if you change the cseq to 1 it will
work as expected. Hence cseq 0 is the suspect as that can reliably be
replicated with it being the only difference.

While these particular packets were generated, we are actually hitting this
in real world where we have someone constantly pinging us starting with
cseq 0. The packet with cseq 0 never gets a reply. All others (1-100, then
they start from 0 again) get a reply. I'll post a copy of that packet
tomorrow too.

Thanks.
On 6 Jul 2016 5:55 p.m., "Eric Tamme"  wrote:

> obscuring the ip/hostnames in this makes it difficult to troubleshoot -
> please dont do that in the future.
>
> I am not certain the CSeq is the issue.  I believe that the contact is
> broken, aka it contains localhost, so when opensips tries to route it, it
> fails on udp_send: sendto.
>
> Again, this is my guess, but since you have manipulated and obscured the
> complete sip trace it makes it difficult to confirm.
>
> -Eric
>
> On 07/06/2016 10:44 AM, Karolis Pabijanskas wrote:
>
> Hi List,
>
> We seem to be hitting a strange behaviour when we get an OPTIONS ping with
> a Cseq of 0. (latest 1.11 branch).
>
> Our routing script contains this at the very beginning to decline OPTIONS
> messages:
> route {
> if (is_method("OPTIONS")) {
> sl_send_reply("501", "Method not allowed");
> exit;
> };
>## blah...
> }
>
> If we send this OPTIONS request:
>
> 2016-07-06 17:12:05 +0100 : CLIENT_IP:5061 -> OPENSIPS_IP:5060
> OPTIONS sip:200@HOSTNAME:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5061
> ;branch=z9hG4bK-895-1-0 From: sipp ;tag=1 To:  HOSTNAME:5060> Call-ID: 1-895@127.0.0.1 CSeq: 0 OPTIONS Contact: sip:100@1
> 27.0.0.1:5061 Max-Forwards: 100 Content-Length: 0
>
> There is no reply from OpenSIPS. Interestingly, siptrace module is also
> running and saving captures in Homer. Homer, actually, is getting a copy of
> the generated reply:
> 2016-07-06 17:12:05 +0100 : OPENSIPS_IP:5060 -> CLIENT_IP:5061
> SIP/2.0 501 Method not allowed Via: SIP/2.0/UDP 127.0.0.1:5061;received=
> *CLIENT_IP*;branch=z9hG4bK-895-1-0 From: sipp ;tag=1
> To: ;tag=06a366df8881a48001f15f72f7138d9f.7522
> Call-ID: 1-895@127.0.0.1 CSeq: 0 OPTIONS Server: User Agent String
> Content-Length: 0
> But running a tcpdump on the OpenSIPS host reveals that no actual packet
> is ever sent to the client. Debug shows:
> Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:core:udp_send:
> sendto(sock,0x7f7867aee470,324,0,0x7fff77d00090,16): Operation not
> permitted(1)
> Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:sl:msg_send:
> udp_send failed
>
> OpenSIPS is running as root.
>
> Switching Cseq to 1 in that original OPTIONS message works. But in this
> particular case we have no control over the Cseq of the host we are being
> pinged from, and need to reply. According to the RFC, Cseq should be a
> 32bit unsigned integer, so 0 should not be an issue.
>
> Any ideas?
>
> Thanks!
> Karolis
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour when replying to an OPTIONS with a Cseq of 0

[Eric Tamme]

obscuring the ip/hostnames in this makes it difficult to troubleshoot - 
please dont do that in the future.


I am not certain the CSeq is the issue.  I believe that the contact is 
broken, aka it contains localhost, so when opensips tries to route it, 
it fails on udp_send: sendto.


Again, this is my guess, but since you have manipulated and obscured the 
complete sip trace it makes it difficult to confirm.


-Eric

On 07/06/2016 10:44 AM, Karolis Pabijanskas wrote:

Hi List,

We seem to be hitting a strange behaviour when we get an OPTIONS ping 
with a Cseq of 0. (latest 1.11 branch).


Our routing script contains this at the very beginning to decline 
OPTIONS messages:

route {
if (is_method("OPTIONS")) {
sl_send_reply("501", "Method not allowed");
exit;
};
   ## blah...
}

If we send this OPTIONS request:

2016-07-06 17:12:05 +0100 : CLIENT_IP:5061 -> OPENSIPS_IP:5060
OPTIONSsip:200@HOSTNAME:5060 SIP/2.0 Via: SIP/2.0/UDP 
127.0.0.1:5061;branch=z9hG4bK-895-1-0 From: sipp 
;tag=1To:  Call-ID: 
1-895@127.0.0.1CSeq: 0 OPTIONSContact: 
sip:100@127.0.0.1:5061Max-Forwards: 100 Content-Length: 0


There is no reply from OpenSIPS. Interestingly, siptrace module is 
also running and saving captures in Homer. Homer, actually, is getting 
a copy of the generated reply:

2016-07-06 17:12:05 +0100 : OPENSIPS_IP:5060 -> CLIENT_IP:5061
SIP/2.0 501 Method not allowed Via: SIP/2.0/UDP 
127.0.0.1:5061;received=*CLIENT_IP*;branch=z9hG4bK-895-1-0 From: sipp 
;tag=1To: 
;tag=06a366df8881a48001f15f72f7138d9f.7522 
Call-ID: 1-895@127.0.0.1CSeq: 0 OPTIONS Server: User Agent String 
Content-Length: 0
But running a tcpdump on the OpenSIPS host reveals that no actual 
packet is ever sent to the client. Debug shows:
Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:core:udp_send: 
sendto(sock,0x7f7867aee470,324,0,0x7fff77d00090,16): Operation not 
permitted(1)
Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:sl:msg_send: 
udp_send failed


OpenSIPS is running as root.

Switching Cseq to 1 in that original OPTIONS message works. But in 
this particular case we have no control over the Cseq of the host we 
are being pinged from, and need to reply. According to the RFC, Cseq 
should be a 32bit unsigned integer, so 0 should not be an issue.


Any ideas?

Thanks!
Karolis



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour

[Dave Singer]

Juri,

Thanks for the compliment!
Great addition yourself!
I hadn't looked at the premissions module before and it looks to be a
good resource for potentially many tasks.
Using it as you show would be much faster than trying to do db lookup
and cache_store method!
Only one thing, you are only showing to do it for OPTIONS, what about NOTIFY?

Dave,

On Sun, Feb 13, 2011 at 11:40 PM, Juri Nysschen j...@greydotelecom.com wrote:
 Hi All

 Filtering OPTIONs is brilliant, I've taken it one step further by also
 filtering against the opensips address table.

 So if the ip is listed in the table OR had registered beforehand there will
 be a reply on the OPTIONs message:

    if (is_method(OPTIONS)){
                xlog(L_INFO,OPTIONS [$fd/$fu/$rd/$ru/$si/]\n);
                if (check_source_address(1)) ||
 (cache_fetch(local,ip_allowed_$si,$avp(i:60))){
                        xlog(L_INFO,OPTIONS OK
 [$fd/$fu/$rd/$ru/$si/]\n);
                sl_send_reply(200, Got it);
                exit;
                };
                drop;
    };


 On a successful register:
        cache_store(local,ip_allowed_$si,$si,1200);


 Regards
 Juri Nysschen


 -Original Message-
 From: users-boun...@lists.opensips.org
 [mailto:users-boun...@lists.opensips.org] On Behalf Of Adrian Vasile
 Sent: Saturday, February 12, 2011 9:26 AM
 To: OpenSIPS users mailling list
 Subject: Re: [OpenSIPS-Users] Weird behaviour

 That's why I dropped the ideea of having numbered usernames.

 On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:

 Adrian,

 Probably want to only respond to registers that are to valid user
 accounts, drop the rest, as they start scanning with like 100, 101,
 ., 5000,  etc

 Dave

 On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi Dave,

 Yeah, you're right.. Basically allow only REGISTER requests from anywhere
 and
 the rest check the source ip.
 Great ideea.

 I will implement it as soon as possible.

 Thanks,
 Adrian Vasile
 y...@opennet.ro


 On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:

 Adrian,

 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.

 Dave

 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer
 dave.sin...@wideideas.com wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
     if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
        sl_send_reply(200, Ok);
     }
     drop;
  }

 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.

 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.

 Dave


 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro
 wrote:
 I know of these issues. And all client are either behind NAT either
 separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined

Re: [OpenSIPS-Users] Weird behaviour

[Juri Nysschen]

yeah, you're right, there's also probably no harm in filtering SUBSCIBE as
well...


Regards
Juri Nysschen


-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
Sent: Monday, February 14, 2011 10:42 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour

Juri,

Thanks for the compliment!
Great addition yourself!
I hadn't looked at the premissions module before and it looks to be a
good resource for potentially many tasks.
Using it as you show would be much faster than trying to do db lookup
and cache_store method!
Only one thing, you are only showing to do it for OPTIONS, what about
NOTIFY?

Dave,

On Sun, Feb 13, 2011 at 11:40 PM, Juri Nysschen j...@greydotelecom.com
wrote:
 Hi All

 Filtering OPTIONs is brilliant, I've taken it one step further by also
 filtering against the opensips address table.

 So if the ip is listed in the table OR had registered beforehand there
will
 be a reply on the OPTIONs message:

    if (is_method(OPTIONS)){
                xlog(L_INFO,OPTIONS [$fd/$fu/$rd/$ru/$si/]\n);
                if (check_source_address(1)) ||
 (cache_fetch(local,ip_allowed_$si,$avp(i:60))){
                        xlog(L_INFO,OPTIONS OK
 [$fd/$fu/$rd/$ru/$si/]\n);
                sl_send_reply(200, Got it);
                exit;
                };
                drop;
    };


 On a successful register:
        cache_store(local,ip_allowed_$si,$si,1200);


 Regards
 Juri Nysschen


 -Original Message-
 From: users-boun...@lists.opensips.org
 [mailto:users-boun...@lists.opensips.org] On Behalf Of Adrian Vasile
 Sent: Saturday, February 12, 2011 9:26 AM
 To: OpenSIPS users mailling list
 Subject: Re: [OpenSIPS-Users] Weird behaviour

 That's why I dropped the ideea of having numbered usernames.

 On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:

 Adrian,

 Probably want to only respond to registers that are to valid user
 accounts, drop the rest, as they start scanning with like 100, 101,
 ., 5000,  etc

 Dave

 On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi Dave,

 Yeah, you're right.. Basically allow only REGISTER requests from
anywhere
 and
 the rest check the source ip.
 Great ideea.

 I will implement it as soon as possible.

 Thanks,
 Adrian Vasile
 y...@opennet.ro


 On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:

 Adrian,

 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.

 Dave

 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer
 dave.sin...@wideideas.com wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
     if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
        sl_send_reply(200, Ok);
     }
     drop;
  }

 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.

 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen

Re: [OpenSIPS-Users] Weird behaviour

[Juri Nysschen]

Hi All

Filtering OPTIONs is brilliant, I've taken it one step further by also
filtering against the opensips address table.

So if the ip is listed in the table OR had registered beforehand there will
be a reply on the OPTIONs message:

if (is_method(OPTIONS)){
xlog(L_INFO,OPTIONS [$fd/$fu/$rd/$ru/$si/]\n);
if (check_source_address(1)) ||
(cache_fetch(local,ip_allowed_$si,$avp(i:60))){
xlog(L_INFO,OPTIONS OK
[$fd/$fu/$rd/$ru/$si/]\n);
sl_send_reply(200, Got it);
exit;
};   
drop;
};


On a successful register:
cache_store(local,ip_allowed_$si,$si,1200);


Regards
Juri Nysschen


-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Adrian Vasile
Sent: Saturday, February 12, 2011 9:26 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour

That's why I dropped the ideea of having numbered usernames.

On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:

 Adrian,
 
 Probably want to only respond to registers that are to valid user
 accounts, drop the rest, as they start scanning with like 100, 101,
 ., 5000,  etc
 
 Dave
 
 On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi Dave,
 
 Yeah, you're right.. Basically allow only REGISTER requests from anywhere
and
 the rest check the source ip.
 Great ideea.
 
 I will implement it as soon as possible.
 
 Thanks,
 Adrian Vasile
 y...@opennet.ro
 
 
 On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:
 
 Adrian,
 
 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.
 
 Dave
 
 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer
dave.sin...@wideideas.com wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
 if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
sl_send_reply(200, Ok);
 }
 drop;
  }
 
 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.
 
 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.
 
 Dave
 
 
 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro
wrote:
 I know of these issues. And all client are either behind NAT either
separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?
 
 
 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:
 
 Adrian,
 
 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register

Re: [OpenSIPS-Users] Weird behaviour

[Adrian Vasile]

Hi Dave,

Yeah, you're right.. Basically allow only REGISTER requests from anywhere and 
the rest check the source ip.
Great ideea. 

I will implement it as soon as possible.

Thanks,
Adrian Vasile
y...@opennet.ro


On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:

 Adrian,
 
 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.
 
 Dave
 
 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer dave.sin...@wideideas.com 
 wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
 if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
sl_send_reply(200, Ok);
 }
 drop;
  }
 
 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.
 
 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.
 
 Dave
 
 
 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro wrote:
 I know of these issues. And all client are either behind NAT either separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?
 
 
 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:
 
 Adrian,
 
 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.
 
 Dave
 
 On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:
 
 Hi,
 
 I attached the trace.
 
 
 why does the cisco spa ask for authorization?
 
 Thanks,
 
 Adrian Vasile
 
 y...@opennet.ro
 
 On Feb 10, 2011, at 12:42 PM, Laszlo wrote:
 
 Hi Adrian,
 
 2011/2/10 Adrian Vasile y...@opennet.ro
 
 Hello all,
 
 Maybe it has happened to you too.. I've got a couple 

Re: [OpenSIPS-Users] Weird behaviour

[Dave Singer]

Adrian,

Probably want to only respond to registers that are to valid user
accounts, drop the rest, as they start scanning with like 100, 101,
., 5000,  etc

Dave

On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi Dave,

 Yeah, you're right.. Basically allow only REGISTER requests from anywhere and
 the rest check the source ip.
 Great ideea.

 I will implement it as soon as possible.

 Thanks,
 Adrian Vasile
 y...@opennet.ro


 On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:

 Adrian,

 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.

 Dave

 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer dave.sin...@wideideas.com 
 wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
     if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
        sl_send_reply(200, Ok);
     }
     drop;
  }

 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.

 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.

 Dave


 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro wrote:
 I know of these issues. And all client are either behind NAT either 
 separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?


 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:

 Adrian,

 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.

 Dave

 On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:

 Hi,

 I attached the trace.


 why does the cisco spa ask for 

Re: [OpenSIPS-Users] Weird behaviour

[Adrian Vasile]

That's why I dropped the ideea of having numbered usernames…

On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:

 Adrian,
 
 Probably want to only respond to registers that are to valid user
 accounts, drop the rest, as they start scanning with like 100, 101,
 ., 5000,  etc
 
 Dave
 
 On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi Dave,
 
 Yeah, you're right.. Basically allow only REGISTER requests from anywhere and
 the rest check the source ip.
 Great ideea.
 
 I will implement it as soon as possible.
 
 Thanks,
 Adrian Vasile
 y...@opennet.ro
 
 
 On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:
 
 Adrian,
 
 I was just thinking about the implementing no response for INVITE a
 little more...
 You would want to handle the response checking similar to the
 register.  If not found in the cache where you check the location
 table if there is a registered user at the source ip.
 That way it can handle opensips reboots and other situations where the
 cache is lost or unavailable. Like a memcached server fails.
 Advantage to using external memcached vs local cache would be that
 cache would not be cleared on opensips restart.
 
 Dave
 
 On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer dave.sin...@wideideas.com 
 wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
 if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
sl_send_reply(200, Ok);
 }
 drop;
  }
 
 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.
 
 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.
 
 Dave
 
 
 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro wrote:
 I know of these issues. And all client are either behind NAT either 
 separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?
 
 
 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:
 
 Adrian,
 
 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.
 
 Dave
 

Re: [OpenSIPS-Users] Weird behaviour

[Laszlo]

Hi Adrian,

2011/2/10 Adrian Vasile y...@opennet.ro

 Hello all,

 Maybe it has happened to you too.. I've got a couple of cisco spa504g
 everything is fine with them, registering, calling out, but there seems to
 be a problem with the calling in feature..

 When I try to call the spa's all they return is 403 Forbidden. Any ideas
 how I could remedy the situation?


Try to capture one call with ngrep, and post here the output.
Use ngrep like this: ngrep 'xxx' port 5060 -Wbyline -q -dany -t 
mytrace.txt

(where xxx is the number/extension what you going to trace)





 Thanks,
 Adrian Vasile
 y...@opennet.ro




 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour

[Adrian Vasile]

Hi,I attached the trace.U 2011/02/10 15:56:10.164605 94.176.168.124:63810 - 94.176.170.3:5060
INVITE sip:1...@opennet.ro SIP/2.0.
Via: SIP/2.0/UDP 
94.176.168.124:63810;rport;branch=z9hG4bKPjBXMfDzNg7rw1NPuIo6.lXrG7emL9tyHF.
Max-Forwards: 70.
From: Adrian Vasile 
sip:te...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro.
Contact: Adrian Vasile sip:test1@94.176.168.124:63810.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9292 INVITE.
Route: sip:94.176.170.3;lr.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS.
Supported: replaces, 100rel, norefersub.
User-Agent: Telephone 0.14.3.
Content-Type: application/sdp.
Content-Length:   465.
.
v=0.
o=- 3506331370 3506331370 IN IP4 94.176.168.124.
s=pjmedia.
c=IN IP4 94.176.168.124.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 103 102 104 117 3 0 8 9 101.
a=rtcp:4005 IN IP4 94.176.168.124.
a=rtpmap:103 speex/16000.
a=rtpmap:102 speex/8000.
a=rtpmap:104 speex/32000.
a=rtpmap:117 iLBC/8000.
a=fmtp:117 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:9 G722/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.


U 2011/02/10 15:56:10.165318 94.176.170.3:5060 - 94.176.168.124:63810
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 
94.176.168.124:63810;rport=63810;branch=z9hG4bKPjBXMfDzNg7rw1NPuIo6.lXrG7emL9tyHF.
From: Adrian Vasile 
sip:te...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro;tag=3a0f43c67d6d39d6305fd30beca51cd4.15f6.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9292 INVITE.
Proxy-Authenticate: Digest realm=opennet.ro, 
nonce=4d53e088004b5d6674ffbd8c2f67782b5b6c18cbfa71.
Server: OpenSIPS (1.6.4-tls (i386/linux)).
Content-Length: 0.
.


U 2011/02/10 15:56:10.170241 94.176.168.124:63810 - 94.176.170.3:5060
ACK sip:1...@opennet.ro SIP/2.0.
Via: SIP/2.0/UDP 
94.176.168.124:63810;rport;branch=z9hG4bKPjBXMfDzNg7rw1NPuIo6.lXrG7emL9tyHF.
Max-Forwards: 70.
From: Adrian Vasile 
sip:te...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro;tag=3a0f43c67d6d39d6305fd30beca51cd4.15f6.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9292 ACK.
Route: sip:94.176.170.3;lr.
Content-Length:  0.
.


U 2011/02/10 15:56:10.171935 94.176.168.124:63810 - 94.176.170.3:5060
INVITE sip:1...@opennet.ro SIP/2.0.
Via: SIP/2.0/UDP 
94.176.168.124:63810;rport;branch=z9hG4bKPj3ZrwhS434LzLkqbbQlE2eJsDKfmAJ-0J.
Max-Forwards: 70.
From: Adrian Vasile 
sip:te...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro.
Contact: Adrian Vasile sip:test1@94.176.168.124:63810.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9293 INVITE.
Route: sip:94.176.170.3;lr.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS.
Supported: replaces, 100rel, norefersub.
User-Agent: Telephone 0.14.3.
Proxy-Authorization: Digest username=test1, realm=opennet.ro, 
nonce=4d53e088004b5d6674ffbd8c2f67782b5b6c18cbfa71, 
uri=sip:1...@opennet.ro, response=abec3b70f69a425b459ac5109ca1785a.
Content-Type: application/sdp.
Content-Length:   465.
.
v=0.
o=- 3506331370 3506331370 IN IP4 94.176.168.124.
s=pjmedia.
c=IN IP4 94.176.168.124.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 103 102 104 117 3 0 8 9 101.
a=rtcp:4005 IN IP4 94.176.168.124.
a=rtpmap:103 speex/16000.
a=rtpmap:102 speex/8000.
a=rtpmap:104 speex/32000.
a=rtpmap:117 iLBC/8000.
a=fmtp:117 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:9 G722/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.


U 2011/02/10 15:56:10.177843 94.176.170.3:5060 - 94.176.168.124:63810
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 
94.176.168.124:63810;rport=63810;branch=z9hG4bKPj3ZrwhS434LzLkqbbQlE2eJsDKfmAJ-0J.
From: Adrian Vasile 
sip:te...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9293 INVITE.
Server: OpenSIPS (1.6.4-tls (i386/linux)).
Content-Length: 0.
.


U 2011/02/10 15:56:10.178324 94.176.170.3:5060 - 94.176.168.99:5060
INVITE sip:spatest@94.176.168.99:5060 SIP/2.0.
Record-Route: 
sip:94.176.170.3;lr;ftag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN;vsf=AEVVQ0VxLx8VCwALEVpcHW8-.
Via: SIP/2.0/UDP 94.176.170.3;branch=z9hG4bK8f16.8d48097.0.
Via: SIP/2.0/UDP 
94.176.168.124:63810;received=94.176.168.124;rport=63810;branch=z9hG4bKPj3ZrwhS434LzLkqbbQlE2eJsDKfmAJ-0J.
Max-Forwards: 69.
From: Adrian Vasile 
sip:1...@opennet.ro;tag=O.sfAOsjP0tNcCvLEqEVfJnc-grVXqPN.
To: sip:1...@opennet.ro.
Contact: Adrian Vasile sip:test1@94.176.168.124:63810.
Call-ID: ppGHUXjRvBgzjymS-td3EK1WwokpmmOc.
CSeq: 9293 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS.
Supported: replaces, 100rel, norefersub.
User-Agent: Telephone 0.14.3.
Content-Type: application/sdp.
Content-Length: 481.
P-Hint:fix_nated_contact applied.
X-from-username: test1.
X-to-username: spatest.
X-application: local.

Re: [OpenSIPS-Users] Weird behaviour

[Dave Singer]

Adrian,

There are lots of people out there with servers doing sip scans to see
if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
they will either try to send register and/or invites for all sorts of
numbers trying to get a hit. Of course the invites are not actual
calls so if the sip scanner gets an ATA, the customer answers the
phone and there is no one there. Depending on the scanner it may keep
trying through it's whole list of common sip source accounts. Then it
can get interesting. The scanner would then mark the IP as a success
and the hacker can then start trying to send calls through it. Though
likely they would try a call to something like a Home Depot number and
when the customer answers they just say sorry wrong number and mark
the IP off their list. Customer is left alone till the next scanner
comes sniffing.
So ATA's many times have settings for not answering calls from places
that shouldn't be sending them calls. The options are usually
something like calls ok: from register server, from proxy server,
call to registered user, auth call or similar.
See what you can find in the docs for that model.

Dave

On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi,
 I attached the trace.


 why does the cisco spa ask for authorization?
 Thanks,
 Adrian Vasile
 y...@opennet.ro

 On Feb 10, 2011, at 12:42 PM, Laszlo wrote:

 Hi Adrian,

 2011/2/10 Adrian Vasile y...@opennet.ro

 Hello all,

 Maybe it has happened to you too.. I've got a couple of cisco spa504g
 everything is fine with them, registering, calling out, but there seems to
 be a problem with the calling in feature..

 When I try to call the spa's all they return is 403 Forbidden. Any ideas
 how I could remedy the situation?


 Try to capture one call with ngrep, and post here the output.
 Use ngrep like this: ngrep 'xxx' port 5060 -Wbyline -q -dany -t 
 mytrace.txt

 (where xxx is the number/extension what you going to trace)




 Thanks,
 Adrian Vasile
 y...@opennet.ro




 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour

[Adrian Vasile]

I know of these issues. And all client are either behind NAT either separate 
voice vlans.
As for securing the proxy. What methods either than Pike combined with fail2ban 
would you advise?


And I finally found the culprit. Auth INVITE:
When enabled, authorization is required for initial incoming INVITE requests 
from the SIP proxy.

On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:

 Adrian,
 
 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.
 
 Dave
 
 On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:
 Hi,
 I attached the trace.
 
 
 why does the cisco spa ask for authorization?
 Thanks,
 Adrian Vasile
 y...@opennet.ro
 
 On Feb 10, 2011, at 12:42 PM, Laszlo wrote:
 
 Hi Adrian,
 
 2011/2/10 Adrian Vasile y...@opennet.ro
 
 Hello all,
 
 Maybe it has happened to you too.. I've got a couple of cisco spa504g
 everything is fine with them, registering, calling out, but there seems to
 be a problem with the calling in feature..
 
 When I try to call the spa's all they return is 403 Forbidden. Any ideas
 how I could remedy the situation?
 
 
 Try to capture one call with ngrep, and post here the output.
 Use ngrep like this: ngrep 'xxx' port 5060 -Wbyline -q -dany -t 
 mytrace.txt
 
 (where xxx is the number/extension what you going to trace)
 
 
 
 
 Thanks,
 Adrian Vasile
 y...@opennet.ro
 
 
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Adrian Vasile
y...@opennet.ro



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Weird behaviour

[Dave Singer]

I've found that generally they start out with the sip NOTIFY or
OPTIONS message. So recently I set in the script to drop them from
sources I'm not expecting them from. Might not work so well for some
situation like ATA's sending pings for nat keep alives. But for the
nat to keep open, generally it doesn't need a response, just as long
as they keep sending the packets. Some devices I've seen actually send
essentially an empty packet to the sip port, just enough to keep the
nat alive but opensips just discards it because it is empty.
The one I do send a reply to is my network monitoring server. Kind of
helpful to know when things stop responding. :-)
If an ATA model need to actually get a reply you could on registration
check the model listed in the sip agent header and use localcache or
memcached to store the source IP as ok to respond to. See
http://www.opensips.org/Resources/DocsCoreFcn16#toc98
cache_store and cache_fetch
at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
 and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
 if( $si == monitor server || $cache_fetch(local,
pingok_$si, $avp(i:5)) {
sl_send_reply(200, Ok);
 }
 drop;
  }

Might not need pike if they never start the brute force scan because
they didn't get the initial reply.
I just came up with this the other day so it is an unproved theory.
The other day I left a packet capture running over night on the
testing server and in the morning I saw all the failed register
attempts. I looked back to the first packet from the registering
source and found the first one was an OPTIONS packet and thus my
theory.

Could apply it to INVITE and other messages. For registrations if
there wasn't a hit in the cache you would want to do a db lookup to
see if the from user is one of yours. But generally that would only be
for a first time registration since registrations usually happen every
30 min. (This is just brainstorming) ;-)
Let me know if you implement some of it and what results you find.

Dave


On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro wrote:
 I know of these issues. And all client are either behind NAT either separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?


 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:

 Adrian,

 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.

 Dave

 On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:

 Hi,

 I attached the trace.


 why does the cisco spa ask for authorization?

 Thanks,

 Adrian Vasile

 y...@opennet.ro

 On Feb 10, 2011, at 12:42 PM, Laszlo wrote:

 Hi Adrian,

 2011/2/10 Adrian Vasile y...@opennet.ro

 Hello all,

 Maybe it has happened to you too.. I've got a couple of cisco spa504g

 everything is fine with them, registering, calling out, but there seems to

 be a problem with the calling in feature..

 When I try to call the spa's all they return is 403 Forbidden. Any ideas

 how I could remedy the situation?


 Try to capture one call with ngrep, and post here the output.

 Use ngrep like this: ngrep 'xxx' port 5060 -Wbyline -q -dany -t 

 mytrace.txt

 (where xxx is the number/extension what you going to trace)




 Thanks,

 Adrian Vasile

 y...@opennet.ro




 ___

 Users mailing list

 Users@lists.opensips.org

 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 ___

 Users mailing list

 Users@lists.opensips.org

 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



 ___

 Users mailing list

 Users@lists.opensips.org

 

Re: [OpenSIPS-Users] Weird behaviour

[Dave Singer]

Adrian,

I was just thinking about the implementing no response for INVITE a
little more...
You would want to handle the response checking similar to the
register.  If not found in the cache where you check the location
table if there is a registered user at the source ip.
That way it can handle opensips reboots and other situations where the
cache is lost or unavailable. Like a memcached server fails.
Advantage to using external memcached vs local cache would be that
cache would not be cleared on opensips restart.

Dave

On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer dave.sin...@wideideas.com wrote:
 I've found that generally they start out with the sip NOTIFY or
 OPTIONS message. So recently I set in the script to drop them from
 sources I'm not expecting them from. Might not work so well for some
 situation like ATA's sending pings for nat keep alives. But for the
 nat to keep open, generally it doesn't need a response, just as long
 as they keep sending the packets. Some devices I've seen actually send
 essentially an empty packet to the sip port, just enough to keep the
 nat alive but opensips just discards it because it is empty.
 The one I do send a reply to is my network monitoring server. Kind of
 helpful to know when things stop responding. :-)
 If an ATA model need to actually get a reply you could on registration
 check the model listed in the sip agent header and use localcache or
 memcached to store the source IP as ok to respond to. See
 http://www.opensips.org/Resources/DocsCoreFcn16#toc98
 cache_store and cache_fetch
 at registration something like
   save(location);
   cache_store(local, ping_ok_$si, ok, 86000);
  and at ping
   if ( $rm =~ OPTIONS|NOTIFY ) {
     if( $si == monitor server || $cache_fetch(local,
 pingok_$si, $avp(i:5)) {
        sl_send_reply(200, Ok);
     }
     drop;
  }

 Might not need pike if they never start the brute force scan because
 they didn't get the initial reply.
 I just came up with this the other day so it is an unproved theory.
 The other day I left a packet capture running over night on the
 testing server and in the morning I saw all the failed register
 attempts. I looked back to the first packet from the registering
 source and found the first one was an OPTIONS packet and thus my
 theory.

 Could apply it to INVITE and other messages. For registrations if
 there wasn't a hit in the cache you would want to do a db lookup to
 see if the from user is one of yours. But generally that would only be
 for a first time registration since registrations usually happen every
 30 min. (This is just brainstorming) ;-)
 Let me know if you implement some of it and what results you find.

 Dave


 On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile y...@opennet.ro wrote:
 I know of these issues. And all client are either behind NAT either separate
 voice vlans.
 As for securing the proxy. What methods either than Pike combined with
 fail2ban would you advise?


 And I finally found the culprit. Auth INVITE:
 When enabled, authorization is required for initial incoming INVITE
 requests from the SIP proxy.
 On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:

 Adrian,

 There are lots of people out there with servers doing sip scans to see
 if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
 they will either try to send register and/or invites for all sorts of
 numbers trying to get a hit. Of course the invites are not actual
 calls so if the sip scanner gets an ATA, the customer answers the
 phone and there is no one there. Depending on the scanner it may keep
 trying through it's whole list of common sip source accounts. Then it
 can get interesting. The scanner would then mark the IP as a success
 and the hacker can then start trying to send calls through it. Though
 likely they would try a call to something like a Home Depot number and
 when the customer answers they just say sorry wrong number and mark
 the IP off their list. Customer is left alone till the next scanner
 comes sniffing.
 So ATA's many times have settings for not answering calls from places
 that shouldn't be sending them calls. The options are usually
 something like calls ok: from register server, from proxy server,
 call to registered user, auth call or similar.
 See what you can find in the docs for that model.

 Dave

 On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile y...@opennet.ro wrote:

 Hi,

 I attached the trace.


 why does the cisco spa ask for authorization?

 Thanks,

 Adrian Vasile

 y...@opennet.ro

 On Feb 10, 2011, at 12:42 PM, Laszlo wrote:

 Hi Adrian,

 2011/2/10 Adrian Vasile y...@opennet.ro

 Hello all,

 Maybe it has happened to you too.. I've got a couple of cisco spa504g

 everything is fine with them, registering, calling out, but there seems to

 be a problem with the calling in feature..

 When I try to call the spa's all they return is 403 Forbidden. Any ideas

 how I could remedy the situation?


 Try to capture one call with ngrep, and post here the