Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Barney

Pages: [1]
1
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.

2
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

3
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.


4
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

5
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

6
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

7
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

8
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

9
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

10
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

Pages: [1]