Topics

1

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'

2

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.

3

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.

4

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

5

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

6

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