Messages

1

Other Yate server issues / Re: DataTranslator::attachChain [0xb6aa6d70] (null)->[0xb69d5020] alaw not possible

« on: April 10, 2023, 03:32:33 PM »

Mea culpa. The error is based on a configuration error. Sorry, it's my fault.

2

Other Yate server issues / Yate-Error when SIP port other than 5060

« on: April 10, 2023, 03:29:48 PM »

I've installed yate 6.4.0-1-2 on an OpenWRT router. My current configuration: 4 VoIP accounts with 2 VoIP provider (yate connects as client), within my home network there are 2 IP phones with 5 extensions (they connect to yate as server). This configuration works flawlessly with 5060 as yate's SIP port (default).

Because I watched several connects to my router's port 5060 from IPs, which do not belong to my VoIP providers, I decided to change yate's SIP port from 5060 to 4711. Therefore I added the line 'port=4711' in ysipchan.conf within the [general] section and restarted yate.

Outgoing calls are okay, but not incoming calls. When I fork an incoming call to 2 or more extensions, yate fails to establish a connection to these extensions.

I turned on the sniffer and noticed, that yate propagates port 5060 and not 4711. The client acknowledges the request at port 5060, but yate is listing on port 4711. Therefore the fork fails with a timeout.

Following a snippet of my sniffer logs (yate listens for SIP traffic on 172.19.50.1:4711, my VoIP provider listens for SIP traffic on 195.185.37.60:5060, the incoming call should be forked to extension 12 and 22):

Sniffed 'call.cdr' time=1681154255.687560 age=0.001121 (broadcast)
  thread=0xb6952550 'Engine Worker'
  data=0
  retval='(null)'
  param['operation'] = 'combined'
  param['billid'] = '1681148041-3'
  param['time'] = '1681154248'
  param['chan'] = 'sip/6'
  param['runid'] = '1681148041'
  param['duration'] = '8'
  param['billtime'] = '0'
  param['ringtime'] = '0'
  param['status'] = 'accepted'
  param['external'] = '0471123456789'
  param['cdrwrite'] = 'true'
  param['address'] = '195.185.37.60:5060'
  param['caller'] = '0471123456789'
  param['called'] = '0049471198765432'
  param['username'] = '0049471198765432'
  param['reason'] = 'Service Unavailable'
  param['out_leg.time'] = '1681154248'
  param['out_leg.chan'] = 'sip/8'
  param['out_leg.duration'] = '8'
  param['out_leg.billtime'] = '0'
  param['out_leg.ringtime'] = '0'
  param['out_leg.status'] = 'outgoing'
  param['out_leg.external'] = '0049471198765432'
  param['out_leg.address'] = '172.19.50.1:5060'
  param['out_leg.caller'] = '0471123456789'
  param['out_leg.called'] = '0049471198765432'
  param['out_leg.username'] = '0049471198765432'
  param['out_leg.calledfull'] = '22'
  param['out_leg.reason'] = 'Request Timeout'
  param['out_leg.1.time'] = '1681154248'
  param['out_leg.1.chan'] = 'sip/7'
  param['out_leg.1.duration'] = '8'
  param['out_leg.1.billtime'] = '0'
  param['out_leg.1.ringtime'] = '0'
  param['out_leg.1.status'] = 'outgoing'
  param['out_leg.1.external'] = '0049471198765432'
  param['out_leg.1.address'] = '172.19.50.1:5060'
  param['out_leg.1.caller'] = '0471123456789'
  param['out_leg.1.called'] = '0049471198765432'
  param['out_leg.1.username'] = '0049471198765432'
  param['out_leg.1.calledfull'] = '12'
  param['out_leg.1.reason'] = 'Request Timeout'
Returned false 'call.cdr' delay=0.003338 (broadcast)
  thread=0xb6952550 'Engine Worker'
  data=0
  retval='(null)'
  param['operation'] = 'combined'
  param['billid'] = '1681148041-3'
  param['time'] = '1681154248'
  param['chan'] = 'sip/6'
  param['runid'] = '1681148041'
  param['duration'] = '8'
  param['billtime'] = '0'
  param['ringtime'] = '0'
  param['status'] = 'accepted'
  param['external'] = '0471123456789'
  param['cdrwrite'] = 'true'
  param['address'] = '195.185.37.60:5060'
  param['caller'] = '0471123456789'
  param['called'] = '0049471198765432'
  param['username'] = '0049471198765432'
  param['reason'] = 'Service Unavailable'
  param['out_leg.time'] = '1681154248'
  param['out_leg.chan'] = 'sip/8'
  param['out_leg.duration'] = '8'
  param['out_leg.billtime'] = '0'
  param['out_leg.ringtime'] = '0'
  param['out_leg.status'] = 'outgoing'
  param['out_leg.external'] = '0049471198765432'
  param['out_leg.address'] = '172.19.50.1:5060'
  param['out_leg.caller'] = '0471123456789'
  param['out_leg.called'] = '0049471198765432'
  param['out_leg.username'] = '0049471198765432'
  param['out_leg.calledfull'] = '22'
  param['out_leg.reason'] = 'Request Timeout'
  param['out_leg.1.time'] = '1681154248'
  param['out_leg.1.chan'] = 'sip/7'
  param['out_leg.1.duration'] = '8'
  param['out_leg.1.billtime'] = '0'
  param['out_leg.1.ringtime'] = '0'
  param['out_leg.1.status'] = 'outgoing'
  param['out_leg.1.external'] = '0049471198765432'
  param['out_leg.1.address'] = '172.19.50.1:5060'
  param['out_leg.1.caller'] = '0471123456789'
  param['out_leg.1.called'] = '0049471198765432'
  param['out_leg.1.username'] = '0049471198765432'
  param['out_leg.1.calledfull'] = '12'
  param['out_leg.1.reason'] = 'Request Timeout'
  param['handlers'] = 'cdrfile:100,cdrcombine:100'

3

Other Yate server issues / Re: DataTranslator::attachChain [0xb6aa6d70] (null)->[0xb69d5020] alaw not possible

« on: April 02, 2023, 03:31:02 PM »

Thanks for your reply.

I'll check with tcpdump and report back.

4

Other Yate server issues / DataTranslator::attachChain [0xb6aa6d70] (null)->[0xb69d5020] alaw not possible

« on: March 30, 2023, 01:42:33 PM »

I've installed YATE 6.4.0-1-2 on an OpenWRT router. There are 2 IP phones connected to the router.

A call from one IP phone to the other (no VoIP provider involved) works as expected: caller and callee can hear and talk to each other.

But an external call via the VoIP provider fails: the caller hears the ringing tone forever; the callee hears the ringing tone, answers but hears nothing.

The YATE log (debug level 9) shows the following entries:

2023-03-30_21:03:24.663961 <INFO> DataTranslator::attachChain [0xb6aa6d70] '(null)' -> [0xb69d5020] 'alaw' not possible
2023-03-30_21:03:24.664134 <INFO> DataTranslator::attachChain [0xb6aa6c70] 'alaw' -> [0xb69d52c0] '(null)' not possible


I have no idea, where to look in the conf files. Can anybody give a useful hint? If you need more information, let me know.

Thanks for reading and have a nice day.

5

Other Yate server issues / SIP line '0049xxxxxxxxxxxx' logon timeout

« on: October 02, 2019, 04:18:58 AM »

I'm running Yate 6.0 on an OpenWrt driven router. I have 4 SIP accounts with 2 SIP providers (defined in accfile.conf) and several IP phones (defined in regfile.conf). All other configuration values are pretty standard.

So far the system works as expected, but the warning message in the subject is irritating me. It appears with varying frequency for all SIP accounts: sometimes there are 5 to 15 messages within an hour, sometimes only 10 to 20 messages within a day.

I really don't know who's to blame for these warning messages:
- the servers of the SIP provider
- the quality of the internet connection between me and the SIP provider
- my yate configuration

So my first question is (others will follow depending on the answers): what triggers/influences the appearence of the timeout message?

Thanks for reading and have a nice day.

6

Other Yate server issues / Where is the sdp data ?

« on: November 09, 2018, 06:12:22 AM »

In order to see the codec, on which two ip phones agreed, I captured some network traffic with tcpdump resp. wireshark. See my topic "yate always chooses alaw codec, although other codecs preferred".

I have a SIP-only configuration with yate 5.5 running on an openwrt router. The router and the two ip phones reside on the same network (192.168.8.0/24). Both phones register at yate, yate registers at my SIP provider.

According to Marian's hint I have a line "forward_sdp=yes" in ysipchan.conf and a line "${rtp_forward}possible=;rtp_forward=yes" in regexroute.conf. As a result yate doesn't deal with codecs, but just relays all sdp data between the devices.

Now I capture the network traffic with tcpdump on the router's lan interface with the following expression:

Code: [Select]

udp port 5060 or udp portrange 5004-5020 or udp portrange 7078-7109
The two portranges are the rtp ports of the two ip phones.

When I get an outbound call or when I do an outbound call, I see rtp traffic from my SIP provider to the ip phone and vice a versa. This is what I expected.

But: when I do an inbound call (say: calling from one extension to the other extension), there is no rtp traffic on the network, although both parties can hear each other. So there must be rtp data, but I don't know on which route it is transfered from one phone to the other.

Even an 'tcpdump ... host <address-of-ip-phone>' yields only signalling traffic on port 5060, but no traffic on the rtp ports of the phone.

My question is now: why do I see rtp traffic with an outbound call, but no traffic with an inbound call?

Thanks for reading and have a nice day.

Barney

7

Other Yate server issues / Re: yate always chooses alaw codec, although other codecs preferred

« on: November 05, 2018, 08:00:53 AM »

According to your proposal I added the following line in ysipchan.conf (section [general]):

Code: [Select]

forward_sdp=yes
But that was not enough to achieve media negotiation between the end devices. According to some other yate docs I added the following line in regexroute.conf (section [default]):

Code: [Select]

${rtp_forward}possible=;rtp_forward=yes
Now I can see in the logs (with sniffer on) that the value of ${rtp_forward} changes from 'possible' to 'yes' and then to 'accepted' from both devices.

Based on these log entries I suppose that all SDP data is directly exchanged between the end devices. So Yate transfers the SDP data just from one party to the other without caring about the content of this data, specially what codecs are used. Is this correct?

If yes, how can I see the result of the media negotiation, specially on which codec both sides agreed.

8

Other Yate server issues / yate always chooses alaw codec, although other codecs preferred

« on: October 30, 2018, 05:10:15 AM »

I have two IP-phones (both GigaSet C430A GO), which use yate as registrar. Both phones support the following codecs: g729, g726, g722, alaw, µlaw. Both are configured to use g729 with highest and µlaw with lowest priority.

What I expect: yate creates a connection between both phones with g729 codec. But yate 5.5 establishes a connection with alaw codec. Why?

I would like yate to choose the codec with the highest possible priority. How can I achieve this goal?

My yate configuration is essentially standard installation with the exception of regfile.conf, accfile.conf and regexroute.conf.

Barney

9

Other Yate server issues / Re: Problem: one-way audio connection

« on: October 30, 2018, 04:46:03 AM »

Can you please dump a log with an outgoing call?
Just to compare the IPs

What dump? With the new configuration?

Barney

10

Other Yate server issues / Re: Problem: one-way audio connection

« on: October 27, 2018, 10:45:17 AM »

Hi Marian,

thanks for your reply.

In the meantime I asked the sipgate support team for help. They suggested to add the following lines to my configuration:

outbound=tcpproxy.sipgate.de:5060
ip_transport=tcp

The whole section for my sipgate basic account in accfile.conf is now:

===============================================
[sipgate-id]
enabled=yes
protocol=sip
username=sipgate-id
interval=120
authname=sipgate-id
password=top-secret
domain=sipgate.de
registrar=sipgate.de:5060
outbound=tcpproxy.sipgate.de:5060
localaddress=yes
; force transport via TCP
ip_transport=tcp
===============================================

With these changes the problem of the one-way audio connection vanished.

Thanks for your efforts and have a nice weekend.

Barney

11

Other Yate server issues / Re: Problem: one-way audio connection

« on: October 20, 2018, 02:24:35 PM »

The log contains more incoming calls.
Please specify which one is the one to track and what it's suppose to happen

Attached you'll find a shorter yate log, which shows a real outbound call from 01775757542 to my sipgate number 004950377779993 (sipgate-id 2538201e0). The result is the same as in the previous log: the caller can hear the called party, but the called party can't hear the caller.

Thanks a lot for your efforts und have a nice sunday.

Barney

12

Other Yate server issues / Re: Problem: one-way audio connection

« on: October 19, 2018, 08:08:43 AM »

Sorry for the missing information. :-(

The whole log is just on call, this is the call flow:

extension [11] on ip-phone 10.91.25.41
-> yate on router LAN=10.91.25.1 / WAN=192.168.91.52
-> easybell 004950379690842
-> sipgate 050377779993/2538201e0
-> yate on router LAN=10.91.25.1 / WAN=192.168.91.52
-> extension [15] on ip-phone 10.91.25.41

13

Other Yate server issues / Re: Problem: one-way audio connection

« on: October 19, 2018, 06:40:32 AM »

Attached a yate log with debug sip level 10 and sniffer on.

Thanks for your time and reading.

Barney

14

Other Yate server issues / Problem: one-way audio connection

« on: October 18, 2018, 10:55:39 AM »

Hi everybody,

I'm using Yate 5.5 on an OpenWRT router.

Since several weeks I'm using Yate with four easybell VoIP accounts (a
German VoIP provider). The configuration works flawlessly. Now I want to
add my sipgate VoIP account.

I used the easybell definitions as template for the new sipgate account
and made some relevant changes. Following the entry for sipgate in
accfile.conf:

===============================================
[sipgate-id]
enabled=yes
protocol=sip
username=sipgate-id
interval=120
authname=sipgate-id
password=sipgate-pw
domain=sipgate.de
registrar=sipgate.de:5060
outbound=sipgate.de:5060
localaddress=yes
===============================================

Everything else are yate default values.

With the above entry I can sucessfully register, start calls and other can
call me.

When my sipgate number is called, the caller hears me, but I cannot here
the caller. When I call someone via the sipgate number, both parties can
hear each other.

According to a hint on the sipgate support website I added the following
line in accfile.conf:

===============================================
ip_transport_localport=5160
===============================================

I defined an additional listener in ysipchan.conf:

===============================================
[listener sipgate]
port=5160
===============================================

But these changes did not solve the problem.

I think, there's no problem with the router's firewall definitions,
because phoning with easybell works without any problems.

The question is: why does easybell work with the yate standard
definitions, but not sipgate.

The yate log with the call to my sipgate number is attached.

There is one line in the log, which could indicate an error:

===============================================
<yrtp:WARN> Initial timeout in channel sip/3 wrapper [0xc9e980]
===============================================

I hope, someone has an idea how to solve the problem.

Barney