TAU-8 кодеки и версия выше 2.0.0

[mustdie]

Странное поведение железки после обновления на новые прошивки. Откат помогает, но думаю пришло время разобраться. Проблема заключается в том, что через некоторое время работы железки при входящем звонке абонент слышит в трубке тишину. Подозреваю, что проблема в отсутствующем rtpmap в SDP. Вот к примеру сделал дамп на самой железке:

Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.631[app:dbg]sdp_tail: 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.631[app:dbg]make_sdp: SDP: s=Session SDP m=audio 23024 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.631[app:dbg]sdp_codecs_set_ptime() ptime present : 20
Jun 2 12:09:32 premiumelectro user.info syslog: 12:09:32.641[app:info]SLIC 4: from state 'ringing' to state 'talking'
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]CMD_STOP_TONE: port = 4
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]Port 4: check vapi queue ('free') at vapi_stop_tone_chan:1518
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]Chan 4: current state is CREATED
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]Port 4: set vapi queue MSP to 'busy' with 'stop_tone' at vapi_stop_tone_chan:1564
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]VQ Conn 4 = MSP : 'stop_tone' =
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]chan 4 stop tone
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]Port 4: user port 2, old state talking, new state
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]Set port 4 led to state 'LED_ON'
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]pbx -[msg_fxs_state]-> group
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]ITC: [msg_fxs_state] -> group
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.641[app:dbg]-----[GM] self_fxs_state()
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.651[app:dbg]Port 4: new state is talking
Jun 2 12:09:32 premiumelectro user.debug syslog: 12:09:32.631[app:dbg]sdp_codecs_get_rfc2833: present=1 pt=101
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip]send 1053 bytes to udp/[xxx.xxx.115.14]:5080 at 12:11:03.530000: ------------------------------------------------------------------------
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] SIP/2.0 200 OK
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Via: SIP/2.0/UDP xxx.xxx.115.14:5080;branch=z9hG4bK2dcb.779cf0db93d836fd3ca857035817a8d2.0
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Via: SIP/2.0/UDP 172.16.122.5:5060;received=172.16.122.5;rport=5060;branch=z9hG4bK-oS1s-269531-1824
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Record-Route: <sip:xxx.xxx.115.14:5080;lr;nat=yes>
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] From: "8xxx2463xxx" <sip:8xxx2463xxx@172.16.122.5;user=phone>;tag=269464dOr1824p0D1635D0t17
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] To: <sip:429950@xxx.xxx.115.14;user=phone>;tag=H53B8K9U24p7r
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Call-ID: 1496-387364-269421
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] CSeq: 2 INVITE
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Contact: <sip:429950@172.16.121.21:5060>
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] User-Agent: TAU-8.IP/2.3.0 SN/VI33021987 sofia-sip/1.12.10
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Require: timer
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Supported: timer, 100rel, replaces
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Session-Expires: 1800;refresher=uac
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Min-SE: 90
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Content-Type: application/sdp
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Content-Disposition: session
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] Content-Length: 210
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip]
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] v=0
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] o=- 4506442485165641306 2468174764569235977 IN IP4 172.16.121.21
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] s=Session SDP
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] c=IN IP4 172.16.121.21
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] t=0 0
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] m=audio 23024 RTP/AVP 8 101
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] a=rtpmap:101 telephone-event/8000
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] a=fmtp:101 0-16
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] a=ptime:20
Jun 2 12:09:32 premiumelectro user.notice syslog: 12:09:32.651[sip] ----------------------------------------------------------------------

Насколько я все это понимаю, что в дебаге список кодеков (rtpmap) есть, а в самом сообщении они куда-то пропали.

[Dmitriy_eltex]

Здравствуйте.

В приложенном фрагменте представлено формирование answerSDP, т.к. сообщение 200ОК.

В RFC3264 написано:

Код: Выделить всё

In the case of RTP, if a particular codec was referenced with a
   specific payload type number in the offer, that same payload type
   number SHOULD be used for that codec in the answer.  Even if the same
   payload type number is used, the answer MUST contain rtpmap
   attributes to define the payload type mappings for dynamic payload
   types, and SHOULD contain mappings for static payload types.


Т.е. в случае answerSDP агент пользователя ОБЯЗАН (MUST) вставлять payload type только для динамических типов нагрузки (for dynamic payload types), что собственно tau8 и делает. Для статических типов, таких как a=rtpmap:8 PCMA/8000, a=rtpmap:0 PCMU/8000 такого требования нет. Если агент пользователя их не указывает, то в RFC3264 описан этот случай:

Код: Выделить всё

In the case of RTP streams, all media descriptions SHOULD contain
   "a=rtpmap" mappings from RTP payload types to encodings.  If there is
   no "a=rtpmap", the default payload type mapping, as defined by the
   current profile in use (for example, RFC 1890 [5]) is to be used.


Поэтому ничего странного в данном поведении tau8 нет, выбранный 8 кодек(PCMA G.711) она указывает в атрибуте m, а статический payload type выставляется как default по RFC1890.

Чтобы разобраться в Вашей проблеме:

Проблема заключается в том, что через некоторое время работы железки при входящем звонке абонент слышит в трубке тишину.

Нужно установить последнюю версию ПО:
http://eltex-co.ru/upload/iblock/3a9/ta ... .22_ru.tgz
Далее отзеркалировать порт WAN и писать .pcap дамп до возникновения проблемы.
Как только слышимость пропадет, то остановить дамп и отправить его на почту в моей подписи с ссылкой на данную тему.