[asterisk-users] Diagnosing call problem

[Asghar Mohammad]

hi,
sflphone work fine installed and tested on debian with nat and without nat.
please check setting in preferences my sflphone use alsa device. you should
check with alsamixer maybe sometime mic get muted or you agent mute the mic.
also check out what advice Mitch.
NB. you can test with IAX also.

On Wed, Mar 20, 2013 at 8:09 PM, Matthew J. Roth <mroth at imminc.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130320/fa115392/attachment.htm>