Yate sending an incorrect address to PBX

[hilander]

Dear developers. We propose to use your product YATE as a converter H.323 signaling to SIP and back (H.323 to SIP Signaling Proxy). Acquainted with the recommendations:
http://docs.yate.ro/wiki/H323_To_SIP_Signaling_Proxy,
http://yate.null.ro/pmwiki/index.php?n=Main.H323ToSIPSignallingProxy
Connection diagram :
IPGW Panasonic (H.323, UDP) - YATE - MS Lync (SIP, TCP).
At the moment, the connection from the MS Lync towards PBX succeeds (Signalling, voice) .
When callback (PBX-MS Lynk) connection failed. When analyzing the trace call that during the exchange of signaling messages YATE towards PBX sends a broadcast address xxx.xxx.xxx.255 . And a voice PBX directed to that broadcast address xxx.xxx.xxx.255. We can send settings YATE, success and failure trace calls. If you will need additional information, I send. Prompt what went wrong

[marian]

Yes, we need the log (configuration would help also).

Start yate with -Dt to see the debug message time.
Also start it with max debug level: -vvvvv
Message sniffer would help also (see http://docs.yate.ro/wiki/Debugging_and,_or_Investigation_of_messages)

[hilander]

OK!
first file: bad call from PBX with numbers 1032  to MS Link number 01032 
second file: successful call from a MS Link number 01032  to PBX number 1032

[marian]

So you have an H323 issue.
I can't see the problem: the failed H323 call is not even routed.

I'm not sure I can help you with h323, but:

You should post the h323chan.conf file along with a wireshark capture and yate log.
Set debug=10 in h323chan.conf, 'general' section. This will put a lot of debug from H323 library.

[hilander]

IP GW PBX address 10.1.64.100, call from 1032 to 01032
Yate address 10.1.64.63

[marian]

The log shows a call to a sip line (lync) who is not registered.
There is no such line.

Also the correct regexroute target to route is:

rule=sip/01032;line=lync

[hilander]

The rule does not work.
The logs found that the H323 module tries to connect to the PBX over TCP. PBX can be connected only by UDP. Is it possible for the module H323 forced to run only on UDP?

[marian]

Can you be more clear?
What do you mean by rule not working? Does it match? Is the line connected?

I don't understand the other phrase.
Which h323 module tries to connect to which PBX?

[hilander]

The phrase "rule does not work," I mean, the connection between Lync and IPGW PBX via Yate did not take place.
The logs Yate shows that YATE is trying to connect to the IPGW PBX  transport - TCP.
IPGW PBX supports only the protocol H323, transport - UDP. In an exchange of signaling messages between IPGW PBX  and YATE gives an error message.
Line Yate-Lync shows no errors.

[marian]

I'm afraid you lost me.
Is the sip line connected or not?
Can you post again the config files, including the accfile.conf (I suppose you are using it to login on sip)?
Can you post a wireshark capture to see the sip account login and a failed call?
Post yate log also.

[hilander]

Why do you think that the problem in the SIP line? I see a problem in H323 channel (area between IPGW PBX and YATE).
See the log. Channel between Link and Yacht starts successfully. Next section starts "H323TSP".

0:16.585     H323 Listener:8a40dc0     transports.cxx(1615)   H323TCP   Started connection:  host=10.1.64.100:1127, if=10.1.64.63:1720, handle=15
  0:16.586     H323 Listener:8a40dc0     transports.cxx(1410)   TCP   Waiting on socket accept on ip$10.1.64.63:1720
  ...
    q931pdu = {
      protocolDiscriminator = 8
      callReference = 19368
      from = originator
      messageType = Setup
      IE: Bearer-Capability = {88 c0 a5 ...}
      IE: Calling-Party-Number = {81 31 30 33 32 .1032}
      IE: Called-Party-Number = {81 30 31 30 33 32.01032}
...

But IPGW PBX works only  with transport - UDP.
Therefore, on the following error message establishing a channel H323

data=(nil)
  retval='(null)'
  param['id'] = 'h323/1'
  param['module'] = 'h323'
  param['status'] = 'incoming'
  param['address'] = '10.1.64.100:1127'
  param['billid'] = '1401359777-1'
  param['answered'] = 'false'
  param['direction'] = 'incoming'
Returned false 'chan.startup' delay=0.002923

So I ask: is it possible to force the module H323 start transport protocol-only UDP?

[marian]

You did received the H323 call. So TCP works.


Check your setup.
The call is accepted by H323.
It is rejected with reason 'offline'.
The log is showing you are trying to route the incoming call on 'lync' sip line which is offline.
A sip line is an account you are registering to a server (yate is the client).
The log shows nothing about any sip line registering to another server.