Problem no audio in asterisk + A104DE

Asterisk Asterisk Support
1

Hi, support

            I have installed, a card A104DE with a link E1 working,  but presented a problem.  The calls that originate from client come without audio to a telephone connected to the asterisk.   The problem appears in 4 of 10 calls,

            In the capture of wireshark they are seen rtp, but there is no audio. In the same capture the dtmf happen without problems.  After 60 seconds this call ends.
            This behavior is that of all the calls with problems.

            I have realized tests with calls that originate from a trunk SIP in the asterisk towards a telephone and this call do not have problems.
  
            This alone problem originates with the calls that come from the PSTN.

            Attached graph, configurations, and capture of wireshark and wanpipon.

            B002.pcap  :  wanpipemon -i w1g1 -pcap -pcap_file /home/B002.pcap -prot ISDN -full -systime -c trd
            habitad-A0000101.pcap : tethereal -i eth0 -w /home/habitad-A0000101.pcap

Time | 172.27.28.34 | 172.16.244.12 |
|11,696 | INVITE SDP ( g711A telephone-event) |SIP From: sip:Anonymous@anonymous.invalid To:sip:9010@172.16.244.12:14438
| |(5060) ------------------> (14438) |
|11,799 | 180 Ringing |SIP Status
| |(5060) <------------------ (14438) |
|11,901 | 200 OK SDP ( g711A telephone-event) |SIP Status
| |(5060) <------------------ (14438) |
|11,901 | ACK | |SIP Request
| |(5060) ------------------> (14438) |
|11,904 | RTP (g711A) |RTP Num packets:1045 Duration:20.885s SSRC:0x90303008
| |(13964) <------------------ (41574) |
|11,916 | RTP (g711A) |RTP Num packets:399 Duration:7.959s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|20,021 | RTP (telephone-event) DTMF Five 5 |RTP Num packets:9 Duration:0.102s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|20,235 | RTP (g711A) |RTP Num packets:26 Duration:0.499s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|20,841 | RTP (telephone-event) DTMF Five 5 |RTP Num packets:9 Duration:0.103s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|21,055 | RTP (g711A) |RTP Num packets:25 Duration:0.479s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|21,722 | RTP (telephone-event) DTMF Two 2 |RTP Num packets:9 Duration:0.102s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|21,935 | RTP (g711A) |RTP Num packets:533 Duration:10.639s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |
|32,796 | BYE | |SIP Request
| |(5060) ------------------> (14438) |
|32,900 | 200 OK | |SIP Status
| |(5060) <------------------ (14438) |

2

You have one way audio, which is typically a firewall or NAT problem. However you could check the SDP in this one, to make sure the correct address is being used:

|11,696 | INVITE SDP ( g711A telephone-event) |SIP From: sip:Anonymous@anonymous.invalid To:sip:9010@172.16.244.12:14438
| |(5060) ------------------> (14438) |

3

Session Description Protocol

v=0
o=root 165909225 165909225 IN IP4 172.27.28.34
s=Asterisk PBX 1.6.2.16.1
c=IN IP4 172.27.28.34
t=0 0
m=audio 13964 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

4

Diagram

telephone ----> PSTN —E1—> PBX —E1—> ASTERISK -----> SIP PHONE

TX -------------------------no audio ---- only DTMF ------------> SIP PHONE
RX<---------------------------------audio ok ---------------------- SIP PHONE

asterisk = 172.27.28.34
sipphone = 172.16.244.12

5

Your original diagram shows audio and DTMF going in the same direction. Are you being confused by confidence tones?

Is there a valid path, free from firewall, etc., interference, from the SIP phone to 172.27.28.34 UDP port 13964, as your packet capture suggests the packets aren’t getting as far as the Asterisk machine?

6

exists rtp from the asterisk up to SIP phone and exist rtp from the SIP phone up to asterisk, but there is no audio. After 60 seconds the call end automatic form

telephone ---------> PSTN —E1—> PBX —E1—> ASTERISK --------------> SIP PHONE

telephone ---------------- no audio ---- only DTMF ------------> SIP PHONE
¨¨¨¨¨¨¨¨ <---------------------- audio ok -----------------------

ASTERISK ---------RTP-----------> SIP PHONE
(172.27.28.34) <-------RTP------------- (172.16.244.12)

7

Could you please correct the graph in your initial posting, so that it agrees with what you are now saying!

8

This link shows a call, the audio is visualized in the green pictures

imagengratis.org/images/updatediagram.jpg

9

That diagram is clearly incompatible with this line from your original trace:

[quote]|20,021 | RTP (telephone-event) DTMF Five 5 |RTP Num packets:9 Duration:0.102s SSRC:0x2FEB643D
| |(13964) ------------------> (41574) |[/quote]

Which clearly shows the DTMF flowing from Asterisk to the phone (and neither DTMF nor speech from the phone to Asterisk).

10

These link are of the call

Graph : imagengratis.org/?v=graphhg2mh.jpg

RTP player : imagengratis.org/?v=rtpplayer.jpg

SDP : imagengratis.org/?v=sdp.jpg

11

hi,

 From this link you can unload the captures   

 200.29.217.212/problem.rar
12

Looking more carefully, there is media going from the phone to Asterisk for the whole call and there is an alternation of media and DTMF going away from Asterisk. There is only one incoming arrow because of the way that wireshark displays RTP.

13

RAR appears to be a proprietary format, for which I don’t have an extractor.

However, the screenshots indicate that there is actual audio in both directions, i.e. there are audio RTP packets and they do not carry pure silence. The Asterisk to phone direction, however, only seems to be carrying constant noise (the trace is broadened, but narrow and constant width.

As this is a digital interface, I would assume that the noise originates outside the immediate system, and would therefore look for the problem either where the A/D conversion takes place or where there is a transcoding that involves the injection of comfort noise.

It is possible that the Answer signal hasn’t got through, so it might be worth getting a signalling protocol trace from the E1 side. That might also give a clue as to why it is clearing in 60 seconds.

Note that if this is a Digium E1 card you might be covered by Digium’s commercial support; this forum is for peer support of the open source products.

Incidentally, PNG image format will produce more accurate screenshots, and, in most cases, considerably smaller ones, than JPG.