[Home]

Summary:ASTERISK-07202: chan_h323 channel driver looks up SRV records for outbound calls
Reporter:Petkan Petkanov (badpi)Labels:
Date Opened:2006-06-19 13:10:24Date Closed:2011-06-07 14:08:27
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) DEBUG.txt
( 1) h323.conf
( 2) h323channel2.cap
( 3) sip.conf
( 4) sip-h323.21062006.cap
( 5) sip-h32321062006debug.txt
Description:Even with setting srvlookup=no in sip.conf, when i try to contact channel oh323, the asterisk contacts the dns.


****** ADDITIONAL INFORMATION ******

FreeBSD 6.1-STABLE
asterisk-oh323-0.7.3_2
asterisk-1.2.9.1
Comments:By: Serge Vecher (serge-v) 2006-06-19 13:27:45

as requested in the bug guidelines, you need to provide a sip debug here.

1) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
2) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
3) Save complete log to file and _attach_ said file to the bug.
By: Olle Johansson (oej) 2006-06-19 14:56:28

srvlookup in sip conf does not affect any other channel, like the H.323 channel.
By: Petkan Petkanov (badpi) 2006-06-19 18:02:12

yes, but it delays it unreasonabely. If i don't have anything in the resolv.conf. it connects almost imediately to the other party, but if I have defined one it query the dns server several times until it sends messages to the h323(or maybe any other) channel


By: Petkan Petkanov (badpi) 2006-06-19 18:16:14

vechers, i have uploaded it, but here what tells the tcpdump:
02:13:25.722107 IP 212.21.135.250.61404 > 212.39.90.42.53:  37134+ SRV? _h323ls._udp.212.39.70.49. (43)
02:13:25.727113 IP 212.39.90.42.53 > 212.21.135.250.61404:  37134 NXDomain* 0/0/0 (43)
02:13:25.727213 IP 212.21.135.250.58018 > 212.39.90.42.53:  37135+ SRV? _h323ls._udp.212.39.70.49.xxx.com. (53)
02:13:30.727706 IP 212.21.135.250.58337 > 212.39.90.42.53:  37135+ SRV? _h323ls._udp.212.39.70.49.xxx.com. (53)
02:13:30.790998 IP 212.39.90.42.53 > 212.21.135.250.58337:  37135 NXDomain* 0/0/0 (53)
02:13:30.791213 IP 212.21.135.250.60109 > 212.39.90.42.53:  37136+ SRV? _h323rs._udp.212.39.70.49. (43)
02:13:35.791666 IP 212.21.135.250.65414 > 212.39.90.42.53:  37136+ SRV? _h323rs._udp.212.39.70.49. (43)
02:13:35.796546 IP 212.39.90.42.53 > 212.21.135.250.65414:  37136 NXDomain* 0/0/0 (43)
02:13:35.796646 IP 212.21.135.250.54445 > 212.39.90.42.53:  37137+ SRV? _h323rs._udp.212.39.70.49.xxx.com. (53)
02:13:40.797623 IP 212.21.135.250.53903 > 212.39.90.42.53:  37137+ SRV? _h323rs._udp.212.39.70.49.xxx.com. (53)
02:13:40.867179 IP 212.39.90.42.53 > 212.21.135.250.53903:  37137 NXDomain* 0/0/0 (53)
02:13:40.867426 IP 212.21.135.250.56060 > 212.39.90.42.53:  37138+ SRV? _h323cs._tcp.212.39.70.49. (43)
02:13:45.867583 IP 212.21.135.250.55941 > 212.39.90.42.53:  37138+ SRV? _h323cs._tcp.212.39.70.49. (43)
02:13:55.868647 IP 212.21.135.250.65328 > 212.39.90.42.53:  37139+ MX? 212.39.70.49. (30)
02:13:55.875825 IP 212.39.90.42.53 > 212.21.135.250.65328:  37139 0/0/0 (30)
02:13:55.875920 IP 212.21.135.250.58592 > 212.39.90.42.53:  37140+ MX? 212.39.70.49.xxx.com. (40)
02:14:00.876449 IP 212.21.135.250.50225 > 212.39.90.42.53:  37140+ MX? 212.39.70.49.xxx.com. (40)
02:14:00.881495 IP 212.39.90.42.53 > 212.21.135.250.50225:  37140 NXDomain* 0/0/0 (40)




while :
asterisk@asterisk# grep srvlook sip.conf
srvlookup=no                    ; Enable DNS SRV lookups on outbound calls
By: Petkan Petkanov (badpi) 2006-06-19 18:38:36

here is my extensions.conf line:
exten => _9900ZXXXX.,n,Dial(OH323/${EXTEN:2}@212.39.70.49,60,T)

is it possible to be a problem of the extensions app?
By: Serge Vecher (serge-v) 2006-06-19 20:15:47

badpi: as oej said, the srvlookup setting only affects outgoing SIP calls, meaning your extensions.conf line would have to look like this:
exten => _9900ZXXXX.,n,Dial(SIP/${EXTEN....)

AFAIK the Asterisk architecture, Dial() application (what you call an 'extension application') is agnostic of the underlying channel technology, passing the responsibility for establishing communication to that channel driver. Therefore, it must be the oh323 channel driver that is responsible for the SRV lookup. The problem now is that this driver is maintained separately by inAccess network and is not officially supported by Digium/Asterisk Project.

I think your options are:
1) Contact inAccess network to resolve the issue with oh323.
2) Or switch to one of the officially supported H.323 drivers: 1) chan_ooh323 from asterisk-addons-1.2.3 or chan_h323 from Asterisk 1.2.9.1 source itself.
By: Serge Vecher (serge-v) 2006-06-19 20:45:48

ok, at this point, I will close this issue. I have given you enough information to work on the next step. If one of the official asterisk h.323 also exhibits this problem (i.e. looks up an SRV record unnecessarily), please open a new bug report for that channel driver. Thanks.
By: Petkan Petkanov (badpi) 2006-06-20 00:43:49

vechers, now I have tried the H323 native asterisk channel.
exten => _9900ZXXXX.,1,Dial(H323/${EXTEN:2}@xxx,60,T)
i have uploaded trace to see when the H323 channel is called
By: Serge Vecher (serge-v) 2006-06-20 08:40:19

ok the h323channel2.cap is garbled. Can you please make sure that you attach a verbose debug from the console? Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
Then at cli type set verbose 4, set debug 4

Also, an ethereal capture separately would be helpful. Thanks.
By: Petkan Petkanov (badpi) 2006-06-21 00:52:14

ok, here are the logs you requested.
i am not absolutely sure that it is chan_h323 problem, because the chan_oh323 reacts the same way ... maybe the dial application ?

I thought that it could be enum, but i put
noload => app_enumlookup.so
noload => func_enum.so
in modules.conf and the query was done again


By: Paul Cadach (pcadach) 2006-06-21 12:34:45

SRV lookups is done by OpenH323 library:
ccm2:/usr/src/OpenH323/openh323/src# grep "SRV" *.cxx
h323ep.cxx:static BOOL FindSRVRecords(std::vector<LookupRecord> & recs,
h323ep.cxx:  PDNS::SRVRecordList srvRecords;
h323ep.cxx:    PDNS::SRVRecord * recPtr = srvRecords.GetFirst();
h323ep.cxx:      PTRACE(4, "H323\tFound " << rec.addr << ":" << rec.port << " with SRV " << srv << " using domain " << domain);
h323ep.cxx:  BOOL hasGK = FindSRVRecords(    routes, domain, LookupRecord::LRQ,        "_h323ls._udp.");
h323ep.cxx:  hasGK = hasGK || FindSRVRecords(routes, domain, LookupRecord::LRQ,        "_h323rs._udp.");
h323ep.cxx:  FindSRVRecords(                 routes, domain, LookupRecord::CallDirect, "_h323cs._tcp.");


To know what's doing within OpenH323, you should enable OpenH323 debugging in your chan_h323/chan_oh323.


By: Andrey S Pankov (casper) 2006-06-23 11:14:52

SRV lookups should go away if you disable gatekeeper discovery...
By: Andrey S Pankov (casper) 2006-06-24 16:20:36

Not a bug.. rather the intended behavior of OpenH323 library... Let's close this one since it does not require any change in Asterisk.