I would like to see the Localnet parameter, it cant possible be a sensitive thing to mask.
10.0.0.0/255.0.0.0
192.168.0.0/255.255.0.0
172.31.1.0/255.255.255.0
172.25.130.12/255.255.255.252
172.17.10.2/255.255.255.255
About this screens above.
Looks like i mislead myself and you all.
My filter was wrong so its shows RTP traffic in one case and don’t show in another(where call was good).
I will try to get “silence call” with both enable rtp and sip debug for specific peer and all traffic on interface.
Thats what i have.
Whireshark
Asterisk( trying to get info from logs, as was adviced above)
Settings for full log file is:
full = verbose,notice,warning,error,debugBoth rtp and sip debug was on for specific peer.
Should i try add new log file with only debug or its possible to get all related call id packets from full log?
The call that is visible was cancelled in the early media phase. You wouldn’t normally expect the caller to hear the callee until the session was up.
Please provide logs as plain text, not images.
This is the problem the caller hears nothing in this case not even signals that call is in progress, just silence.
I understand that caller in this case just cancel the call and no session was established.
And if you listen to the RTP stream in Wireshark, is there actually… audio in it and not just silence?
Don’t you have to call Progress() for early media to go through?
No, early media will automatically go through when Dial() is called if the channel is not answered and you dial only a single party.
If I’m not mistake, for some reason in this calls RTP stream goes only one way from caller to server.(I mean there no RTP packets with signals going back that call is processing)
In this RTP stream(I listen it with Wireshark tools) I hear some noise from caller side and how he hang up handset at the end.
What i did to filter this RTP stream is:
1.I found SIP INVITE with calle number.
2. Filter by callID
3. Then apply filter from Telephony/Voip Calls(Prepare filter).
If I understand it right its timestamp filter. So that how it looks:
Filter -
frame.number in {220987,220988,220989,220990,220991,221001,221002,221794,221795,221796,221797} or rtp.setup-frame in {220987,220988,220989,220990,220991,221001,221002,221794,221795,221796,221797}
Packets -
silence.txt (103.0 KB)
Number was called i delete from text file.
So best solution for me just switch to pjsip and hope its relosves?
You haven’t convinced me that anything is wrong.
I don’t know how to convince you,but problem is real.
I try describe problem one more time.
Caller make a call, but he hear nothing not even ringing signals just silence.
As users says sometimes call proced and caller connect to callee, but most time they just cancel call because they confused not hearing ringing signals.
In this call i catch with tcpdump
220991 6135.950892 172.31.1.254 172.31.1.121 SIP 520 Status: 100 Trying |
221001 6137.995545 172.31.1.254 172.31.1.121 SIP 536 Status: 180 Ringing |
221002 6137.996014 172.31.1.254 172.31.1.121 SIP/SDP 841 Status: 183 Session Progress |
221003 6138.120322 172.31.1.121 172.31.1.254 RTP 294 PT=ITU-T G.711 PCMU, SSRC=0x530E948C, Seq=15895, Time=96365960
221004 6138.150363 172.31.1.121 172.31.1.254 RTP 294 PT=ITU-T G.711 PCMU, SSRC=0x530E948C, Seq=15896, Time=96366120
221005 6138.180327 172.31.1.121 172.31.1.254 RTP 294 PT=ITU-T G.711 PCMU, SSRC=0x530E948C, Seq=15897, Time=96366360
straightaway after session Progress starts one way RTP stream with sound from caller side
That’s what will happen if the caller’s side doesn’t support early media, often the case for chargeable networks, or the callee’s side sends 183, but doesn’t back it up with media.
If the caller doesn’t support early media, and the callee users 183, rather than 180, the only options are either to answer the call prematurely, or to force the sending of ringing, early, with early media disabled (r option on Dial).
If you are only getting inbound media, from the caller, that suggests the callee is sending 183, but not providing early media. If they were sending early media, you should see an RTP stream, from them, even if Asterisk is failing to forward it.
(There was, at one time, advice that one needs to call Progress for early media to pass, towards the caller, although a recent reply ( #29 ) from Joshua contradicts that, and I was always a bit confused about it. However, if that were the problem, you would still see the media arriving from the callee.)
Unfortunately, you are only providing summary information about the protocol, whereas we really need to see the full SDP exchange on both sides. It might be that the callee is sending 183, without SDP, which generally indicates an intention not to send early media, and makes early media impossible, if you are also sending a private media address to them.
By nothing being wrong, I mean that the system may be behaving as intended, given the inputs.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.