KX-TDE200 + asterisk

[Mammon]

Добрый день!
Возникла проблема с "покрещением" TDE с астером по SIP. Ситуация такая: TDE по SIP зарегистрирова на астере. Астер зарегистрирован по SIP на сервере оператора связи(не спрашивайте зачем так сложно- клиент так хочет, запись разговоров и пр. пр.). Совершаем исходящий вызов с экстеншна панасоника на городской номер, получаем одностороннюю слышимость- исходящий голос есть, входящего нет. Смотрим дамп на интерфейсе астериска- видим, что обмен SIP сообщениями проходит нормально, RTP от панасоника идет, в сторону панасоника тоже идет, и даже на тот порт, который TDE указал в SDP, но в ответ приходит ICMP Destination Unreachable (Port Unreachable).
Дамп во вложении.
IP 192.168.0.101 - проц TDE
ip 192.168.0.102 - DSP TDE
ip 192.168.0.13 - Asteirsk
Да, астер версии 1.6.2.0, TDE 3.0001.

[LionB]

Была маза, что Панасоник в SDP указывает только RTCP номер порта.

Приходится догадываться Астеру, что RTP наверное порт = RTCP - 1 (обычно при указании обоих портов сначала указывается RTP потом RTCP)
Так вот это мы с Астером так думаем, а на самом деле Панасоник ждет RTP на RTCP+1
Аналогичная ситуация происходила при скрещивании с OS7400. И мы подумали, что причина именно в этом. А на самом деле ларчик открылся просто. На Панасонике для всяких тестов меняли IP. А комутатор запомнил старый IP на этот MAC и не успел обновить ARP табличку. В общем либо подождать пока он обновит ARP, либо перегрузить его. Вот оригинал ответа разработчика из Панасоника.
-------
>> Let's look at carefully the contents of the mentioning "faststart"
information at the SETUP message(with OpenLogicalChannel IE).
How many items are there in the "faststart" section is depending on the situation of how many CODEC is allowed for the But usually the number of item is always even number.
In our design, the contents of each item is followings.
Usually even number item(0, 2, 4, 6...) is carrying the CODEC and other voice data stream information of the forwarding direction.
If KX-TDE is making call(thus sending SETUP message), the item0 is carrying the 1st priority CODEC and the IP address and Port for the voice data from TDE to other end.
Odd number item(0, 2, 4, 6...) is carrying the CODEC and other voice data stream information of the reverse direction.
If KX-TDE is making call(thus sending SETUP message), the item1 is carrying the 1st priority CODEC and the IP address and Port for the voice data to TDE from other end.
According to the rule of ITU-T(it is defined in H.245), we need to add the information of RTCP(MediaControlChannel) for the information of the forwarding voice data stream, but do not need to add the information of RTP(MediaChannel).
On the other hand, for the information of the reverse(receiving) voice data stream, we do need to add both from the rule of UTU-T.
Therefore, the red-mark contents in the "faststart" section is quite normal from the rule of ITU-T.
I can see that the same "faststart" information in ALERTING or CONNECT message of Samsung has different manner from us.
Samsung adds both RTP and RTCP informations for both forwaring and backword direction informations.
This is not the wrong manner.
But it is not always necessary to be so, according to the ITU-T H.245.
Samsung should understand this rule of H.245.
And I think that their problem is not directly relating to this contents.
Without depending on the difference of the detailed manner of this point, our KX-TDE seems to be responding correctly.
And one more.
>> Therefore, OS7100 and OS7400 send RTP to the RTCP-1 port.
This manner is also very commonly used.
Because the actual receiving port-numbers for the RTP and RTCP are negotiated by the above mentioned informations(at the section of "faststart", or H.245 protocol in non-Faststart manner), it is not always necessary to follow this manner.

But our KX-TDE is also following to this usual manner.
We are usually using the receiving port-number of RTP by the RTCP-1 port-number.

Therefore, on this point, the design of our system and Samsung are not different.
(2) The real cause of the problem.
>> we generally use RTCP port as RTP +1 Therefore, OS7100 and OS7400
>> send RTP to the RTCP-1 port.
>> However, there is no RTP package from Panasonic system.
The above point is your explanation of the doubt of Samsung.
I reviewed the presented wireshark data for finding the problem.

First of all, in the capture data, I can see that KX-TDE is correctly sending the voice data from KX-TDE(192.168.3.61) to Samsung (192.168.3.59:30016).

Port30016 is the correct port-number which is requested from Samsung in the Q.931/H.225.0 faststart manner as the receiving port of Samsung side.
Therefore, KX-TDE is correctly sending the RTP to the requested port of Samsung.
And no ICMP message of transmission error of this packet in the capture data.
From this fact, I can understand that RTP from KX-TDE to Samsung has sent correctly.
I can believe that Samsung could receive the RTP packet from KX-TDE.
But in the same wireshark capture, I can also see the ICMP ("Destination Unreachable") message for the RTP packet which is sent from

Samsung(192.168.3.59) to KX-TDE(192.168.3.61:12142).
The destination IP address and port-number is correct again.
But error is reported for it.
This ICMP seems to be the error message which reported from router which is locating at the LAN of KX-TDE.
Samsung could not send the RTP packet to KX-TDE correctly.
I think that this is the reported problem from Samsung.
Please once again confirm the point of the problem to them.
I assume the problem is the RTP packet transmission from Samsung to TDE is not correctly done.
By assuming it, I would like to explain about the possible cause of this problem.
If I carefully see the successful RTP packet(from KX-TDE to Samsung), I can see that the MAC address of source of this packet(KX-TDE) is 00:80:f0:3c:dc:1d.
And if I also look at the unsuccessful RTP packet from Samsung to KX-TDE, I can see that the MAC address of destination of this packet is 00:80:f0:3b:f6:1b.

Please check that this destination MAC address is not same as the above mentioned source MAC address of the RTP packet from KX-TDE !
To describe the same equipment of the same IP address, the MAC address is different !
I think that this wrong MAC address on the Ethernet header was the essential cause of this problem.
So, why does such situation happen ?
To understand this, you have to understand the logics of searching for the MAC address which corresponds to the specific IP address.
This logics is existing at the Router.
Router is handling the packet by its IP address when it is handled between the routers.
But the actual communication on the LAN cable between each office IP equipment and Router/Hub(usually it is using Ethernet protocol) is done by basing on the MAC address of each IP equipment and is not basing on the IP address of them.
By this reason, the nearest Router to the destination IP equipment needs to know the relation of IP address and MAC address of each IP equipment which is handled by that router.
This table in the Router is called as ARP table.
In general, this ARP table of the router is maintained by the automatic studying of the router itself.
When router receives a packet from the IP equipment of the same office LAN, this packet includes both the IP address and the MAC address of the sending IP equipment.
The router memorizes this combination information whenever it finds the new IP address.
Because the ARP table has the limited memory size, the old combination data which is not used for long time is automatically overwritten by the new information if the memory becomes maximum.
By this logics, router is automatically studying the combination of IP address and MAC address.
And if the router receives new packet from the outside of the network which has new IP address of LAN and which is not known by the ARP table of the router, the router sends the broadcast ARP packet to the LAN and searches the IP equipment which has the desired IP address.
The router also memorize the response of the ARP packet into the ARP table of it.
This is very good logics because it is full automatic.
But there is one blind spot.
It is the situation that you are very frequently changing the IP address of the IP equipment in the office.
MAC address is fixed to each hardware(NIC) of the IP equipment.
But IP address is programmable.
By this reason, if you change the IP address setting of the equipment very frequently, the update of the ARP table of the router can get the delay.
In general, for the updating of the table, we need to wait for the expiring of the data by the above mentioned overwriting logics of the limited size of the ARP table data.
The refresh of ARP table data by this logic takes quite long time usually.
And in such situation(the router still kept the old combination of IP and MAC), this problem can happen.
The router does not use the broadcast ARP packet for urgently updating the table because the destination IP address is still in the ARP table still(even if it is not correct).
As the result of them, the router can use the wrong MAC address for sending the packet to the IP equipment of the LAN by following to the old(wrong) ARP table.
I think that this situation is happening.
Didn't you change the IP address of KX-TDE and other Panasonic IP equipment frequently ?
Because it is the test phase, I think that you did it...
I think that it made the problem.
This incorrect information of ARP table of router would be automatically refreshed if you take very long time.
Therefore, if you leave it, the problem will be solved some day.
But we can not know how long we need to wait it for because it is depending on the router.
Anyway, please remember that the IP network is not basically designed for changing the IP address so frequently in very short span.
If you do it, this kind of the trouble can happen temporary.
Of course, the router has some countermeasure to this situation.
One of the solution is the automatic timeout of the data on ARP table.
By defining the faster expiring of the data on the ARP table, the router can refresh of its ARP table data faster.
Another solution is the static ARP table settings.
Some of router has the extra-setting which allows the programming of the relation of IP and MAC by manual programming.
Anyway because they also has the side-effect of them, we can not always recommend you to use such setting. <<

[Mammon]

Спасибо, было интересно почитать
С MAC адресами там действительно что то не то! Астер отправляет пакеты с правильным IP адресом назначения, но неправильным MAC адресом назначения. При том, что они находятся в одной локальной сети и никаких маршрутизаторов между ними нет. Буду разбираться. Спасибо за наводку

[sotik]

У нас была подобная штука, заменили станцию с тде200 на тде600, IP соответственно поменяли чтоб не менять сетевых настроек на других станциях, так вот звонки ходили а слышимость была односторонняя, потом сбросили кэш (там были маки от 200) в сиске и все заработало

[Mammon]

Судя по всему дублировавние ip адреса на 2х хостах:
ARPING 192.168.0.102 from 192.168.0.13 eth0
Unicast reply from 192.168.0.102 [00:1B:11:B7:F7:E5] 0.673ms
Unicast reply from 192.168.0.102 [00:80:F0:A4:B6:EF] 1.252ms
Причем второй адрес- панасоник. Вобщем перебью ip на станции на заведомо свободные, отпишусь по результатам.

[Mammon]

Разобрался с дублированием ip на 2 хостах. Проблема ушла. всем спасибо!