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