[asterisk-users] Diagnosing call problem
Matthew J. Roth
mroth at imminc.com
Wed Mar 20 14:09:13 CDT 2013
Mitch Claborn wrote:
> Where is a good place to find documentation on the various fields in the
> INVITE SIP message and the response? I'd like to dig into them and try
> to understand them more completely.
For the SIP headers:
http://en.wikipedia.org/wiki/Session_Initiation_Protocol
http://www.ietf.org/rfc/rfc3261.txt
For the SDP content:
http://en.wikipedia.org/wiki/Session_Description_Protocol
http://www.ietf.org/rfc/rfc4566.txt
Don't forget that SIP is a request-response protocol. The server sends an
INVITE with SDP describing the media session on its end (RTP IP and port, codec,
etc.) but that only gives you half of the picture. The client returns an OK
with SDP describing its side of the media session. You have to look at both to
determine if the call was negotiated properly.
To start, I'm going to strip down one of the SIP traces you sent so it's not
overwhelming:
INVITE from Asterisk server (172.16.0.245) to client (172.16.0.71)
c=IN IP4 172.16.0.245
m=audio 13428 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
This says that the Asterisk server's RTP for the call will be at 172.16.0.245
(from the c= line) port 13428 (from the m= line), the allowed codecs are u-law
(0 PCMU), a-law (8 PCMA), and DTMF (101 telephone-event) (from the m= and a=
lines), and Asterisk will both send and receive packets. Note that this is the
port (13428) that must be within the range defined in "rtp.conf". The port
returned in the client's OK is specific to the client and Asterisk has no
control over it. Speaking of the client's OK:
OK from client (172.16.0.71) to Asterisk server (172.16.0.245)
c=IN IP4 172.16.0.71
m=audio 39408 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
This says that the client's RTP for the call will be at 172.16.0.71 (from the c=
line) port 39408 (from the m= line), the allowed codec is u-law (0 PCMU) (from
the m= and a= lines), and the client will both send and receive packets. There
is also a stray a= line describing DTMF, but its payload type (101) isn't listed
on the m= line. I may be wrong, but that seems broken to me. I don't think it
would cause the audio issues you're describing, but it's something you could
ask SFLphone support about.
So the IPs and ports are agreed on (Asterisk = 172.16.0.245:13428, client =
172.16.0.71:39408), both endpoints share an allowed codec (u-law), and they're
both ready to send and receive packets. The good news is that the call should
work. The bad news is it doesn't. The RTCP information you posted bears this
out:
Fraction lost: 254 / 256
Cumulative number of packets lost: 37134
Extended highest sequence number received: 37331
Over 99% of the packets are lost, so the call is setup fine but something is
getting in the way of the RTP. Your first post said:
Occasionally an agent will get a call (or more often a series of
calls in a row) where neither party can hear the other,
or can only hear each other sporadically. A MixMonitor
recording of the call plays only the caller - none of the
agent's audio is heard in the recording.
This means that the agent's RTP never makes it to the Asterisk process. I
doubt it's even making it to the server, but you could prove it by running:
# tcpdump -s 0 -A host 172.16.0.71 and portrange 10000-65535
at the Linux command line during a bad call. If you only see packets going
to the client that takes your Asterisk configuration out of the equation.
Then you have to start tracing it back to the client. First rule out the
firewall on the Asterisk server, then the cable to the switch, then the
switch, then the cable to the client, then the client's firewall, then the
softphone on the client. Something on that path has to be stopping (or not
producing) the agent's RTP.
Don't forget the simple stuff either. It could be something like the agent
putting their microphone on mute.
Regards,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
More information about the asterisk-users
mailing list