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