[Home]

Summary:ASTERISK-19443: realtime peers are not loaded during start
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2012-02-28 19:33:36.000-0600Date Closed:2012-05-21 08:53:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:1.8.9.3 Frequency of
Occurrence		Constant
Related
Issues:
is the original version of this clone:ASTERISK-19522 realtime peers are not loaded during start
Environment:Attachments:( 0) realtimepeer.patch
Description:When starting asterisk no peer's are shown in "sip show peers". Peers become visible after making the outbound call.
It may cause some problems where incoming connections are declined due to fact that no peer is loaded. Here is an example logs for declined connections:
{code}
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4
[2012-02-29 02:25:41] NOTICE[31801]: chan_sip.c:22353 handle_request_invite: Sending fake auth rejection for device "+48xxxxxxxx" <sip:xxxxxxxx@sbc.freeconet.pl>;tag=as2fbe7eb4{code} - Ive covered the number by placing xxx

However after preforming "sip show peer $name load" - everything works ok.

I think it might be connected to ASTERISK-17523
Comments:By: Walter Doekes (wdoekes) 2012-02-29 01:28:38.094-0600

Your other issue from ASTERISK-17523 is a feature in 1.6.2 and earlier this is a feature -- and I don't think this was changed in 1.8:

- realtime peers cannot do qualify
- realtime peers are not loaded at startup

In fact, they don't exist in the peers (by name) and peers_by_ip internal lists, unless rtcache=yes, which would be the only situation when qualify makes sense. But even then, they are not preloaded as far as I know.

I don't know what the problem is you're seeing here though. Can you tell us what should be matched (IP? hostname? username (from From or auth)?).

If you have a hostname in your host= peer setting and no ipaddr= set and rtcache=yes then what you describe would be expected behaviour, I think.
By: Maciej Krajewski (jamicque) 2012-02-29 02:40:53.875-0600

Hi Walter,
thanks for fast reply.
I have set the rtcachefriends before, I don't see rtcache parameter in configuration file.
In my host and ipaddr I have a domain name, not an IP address. It is very useful if Voip carrier uses DNS SRV - you do not have to configure peer for every ip address, you can configure only one setting domain name. However for such configuration to work - you have to have sip peer loaded in your configuration (and dns manager enabled).

By: Maciej Krajewski (jamicque) 2012-03-01 13:23:18.437-0600

I've done some test, and I do not know why in asterisk 1.6 "domain name peer" could be found after the chan_sip reload when dnsmanager was on.
In 1.8 it is not longer possible.
domain name peer = peer where host and ip are domain names

By: Maciej Krajewski (jamicque) 2012-03-01 17:50:04.914-0600

I've done some tests and problem does occurs in asterisk 10.1.3 - peer is correctly recognized in incoming call.
The problem seems only to happen in 1.8 branch in 1.6 and 10 is ok.
By: Maciej Krajewski (jamicque) 2012-03-02 02:33:12.854-0600

Both asterisk 1.6 and 10 reject the first call. However after this asterisk refreshes dnsmanager here is the log from asterisk 10.

{code}
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4
[2012-03-02 09:25:03] NOTICE[7602]: chan_sip.c:22918 handle_request_invite: Sending fake auth rejection for device "xxxx" <sip:5863040002@sip.freeconet.pl>;tag=as42b66ee2
      > doing dnsmgr_lookup for 'sip.freeconet.pl'
   -- adding dns manager for 'sip.freeconet.pl'
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4
 == Using SIP RTP TOS bits 136
 == Using SIP RTP CoS mark 4
   -- Executing [test@TEST:1] GotoIf("SIP/test-00000000", "0?3") in new stack

{code}

in asterisk 1.8:
{code}
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4
[2012-03-02 12:18:58] NOTICE[25832]: chan_sip.c:22358 handle_request_invite: Sending fake auth rejection for device "xxxx" <sip:586304000@sip.freeconet.pl>;tag=as5d3491e2
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4
[2012-03-02 12:19:00] NOTICE[25832]: chan_sip.c:22358 handle_request_invite: Sending fake auth rejection for device "xxxx" <sip:586304000@sbc.freeconet.pl>;tag=as0f80489d
 == Using UDPTL TOS bits 136
 == Using UDPTL CoS mark 4

{code}
By: Maciej Krajewski (jamicque) 2012-03-02 18:40:28.134-0600

I've attached the file that fixes the problem - and the behaviour of astersik 1.8 is more less the same as in 10 - the realitme peer after the first rejection is loaded to asterisk.
Asterisk 10 has the same function in security_events.c which is not available in 1.8.

SUMMARY - WHAT THE PATCH DOES:
When realtime peer is configured using domain names (no ip), all the incoming calls are rejected by asterisk till peer will be loaded or by preforming the outbound call through it or preforming "sip show peer $name load" command.
What patch does - it loads peer to asterisk when first incoming call is made (match is made on SIP URI - extension), so the second call is picked up correctyl.
The patch should be made aginst 1.8 only.
By: Matt Jordan (mjordan) 2012-05-21 08:53:18.888-0500

I am currently unable to reproduce the behavior you're describing.

In both Asterisk 1.8 and Asterisk 10, I get the same behavior.  With the dnsmgr enabled and rtcachefriends set to yes, before a realtime peer is loaded, a realtime peer with a  host value set to a domain name will have that name queried if something attempts to Dial it.  The standard mechanisms in Asterisk will be utilized to query that domain name.

As it is, I don't see the patch you've provided changing the behavior in Asterisk 1.8 versus Asterisk 10.

1) In both Asterisk 1.8 and Asterisk 10, the dnsmgr is queried in the exact same locations.
2) In both Asterisk 1.8 and Asterisk 10, find_peer/sip_find_peer (the method was renamed) is utilized in the same fashion in the portion of code that you've modified.
3) In both Asterisk 1.8 and Asterisk 10, a lookup of realtime_peer_by_name will occur on the first call to find_peer/sip_find_peer, if the peer cannot be found in the ao2 peers container.  This should already perform an address resolution of the peer's domain.

Finally, as pointed out by Walter, SIP realtime peers are not loaded at startup, and qualify attempts are not performed.  While its possible that I may be missing some subtle aspect of what you're reporting, at this time, I do not feel this is a bug.
By: Walter Doekes (wdoekes) 2012-05-21 09:16:07.970-0500

Maciej, isn't this a matter of setting your peers to type=friend instead of type=peer ? Then they can be found by From and consequently be loaded into memory.
By: Maciej Krajewski (jamicque) 2012-05-21 09:25:18.336-0500

Walter I can check this. However, I've checked this again and in Asterisk 10, the problem did not occur, in Asterisk 1.8 it does.
Maybe you could not reproduce this problem because the peer I was testing uses DNS SRV?

In my past comment from second March I was analysing the codecs line by line, and what I have found was the thing I have written before - Asterisk 10 uses security_events and during the not recognizable peer it refreshed the realtime peers.