[asterisk-users] Diagnosing call problem

Wed Mar 20 17:20:11 CDT 2013

Thank you for that most excellent post.  I had guessed at most of the 
SDP fields and meaning.

I have wireshark traces from the client and the RTP packets are not in 
the trace, which I think means that the client software is simply not 
producing them.  I have opened a ticket with SFL phone support and will 
post here if I find anything.

I did test the "muted microphone" theory.  SFLphone continues to send 
RTP packets even when the mic is muted, so that doesn't seem to be the 
cause.

I've also compared the call initiation SIP and SDP packets between a 
call that fails and one that works correctly.  I can discern no 
difference other than things like port numbers and call IDs.

Tomorrow I'll be trying one of my agents on Bria instead of SFL - maybe 
that will make a difference.

Mitch

On 03/20/2013 02:09 PM, Matthew J. Roth wrote:
> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                 http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-users
>