Re: [asterisk-users] Diagnosing call problem
Mitch Claborn wrote: I get to go home on Saturday! The Digium phone deployment is simple enough to manage remotely. Glad to hear it. If the problem comes back on the hardphones, just post the debug information to this thread and I'll take a look at it. 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
Re: [asterisk-users] Diagnosing call problem
Mitch Claborn wrote: Interestingly, using Bria we sometimes see similar, though not exactly the same, symptoms. That would make me wonder about the TCP stack on the client machine, or similar. With a softphone, you're dependent on the entire software stack up to the softphone and at the mercy of every other process. They're often a cheaper solution, but the trade-off comes in the form of reliability and stability. We are close to ditching the soft phones entirely for this call center and going to the Digium D40. I put one of those in service this morning and the calls are noticeably clearer and there have been no reported problems. The hardphone eliminates a lot of variables, so it's a very good idea to at least use them in your test environment. Using them in production may be more expensive at first, but if they're easier to manage then they may be more economical in the long run. Good luck and I hope you get to go home this weekend. 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
Re: [asterisk-users] Diagnosing call problem
I've installed 7 Digium D40's over the last 24 hours. They work flawlessly - no dropped calls, no 1-way audio, sound quality is noticeably better. If these work out through Monday (our busiest day) then we'll order a dozen more for the rest of the agents. The one downside to this approach is that the agent has to have one headset for the phone and another for their computer (which they need occasionally). I get to go home on Saturday! The Digium phone deployment is simple enough to manage remotely. Mitch On 03/22/2013 01:13 PM, Matthew J. Roth wrote: Mitch Claborn wrote: Interestingly, using Bria we sometimes see similar, though not exactly the same, symptoms. That would make me wonder about the TCP stack on the client machine, or similar. With a softphone, you're dependent on the entire software stack up to the softphone and at the mercy of every other process. They're often a cheaper solution, but the trade-off comes in the form of reliability and stability. We are close to ditching the soft phones entirely for this call center and going to the Digium D40. I put one of those in service this morning and the calls are noticeably clearer and there have been no reported problems. The hardphone eliminates a lot of variables, so it's a very good idea to at least use them in your test environment. Using them in production may be more expensive at first, but if they're easier to manage then they may be more economical in the long run. Good luck and I hope you get to go home this weekend. 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
Mitch Claborn wrote: Thank you for that most excellent post. I had guessed at most of the SDP fields and meaning. No problem. I actually like looking at SIP traces for some reason. 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. That's a reasonable conclusion. Just make sure that you get some traces of good calls to verify that your tests are valid. 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. It's always a good idea to rule out PEBKAC before spending a lot of time diagnosing a problem. 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. It really seems like it may be a problem with the softphone. I'm sure the developers of SFLphone will appreciate your feedback, because not sending RTP is a pretty serious bug. I'll keep an eye on this thread and help out if I can. 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
Re: [asterisk-users] Diagnosing call problem
I did open a ticket with SFL support and sent them the packet trace. Interestingly, using Bria we sometimes see similar, though not exactly the same, symptoms. That would make me wonder about the TCP stack on the client machine, or similar. Bria on Ubuntu is not terribly stable. Bria on the Mac works very well, but that's a pretty expensive solution. We are close to ditching the soft phones entirely for this call center and going to the Digium D40. I put one of those in service this morning and the calls are noticeably clearer and there have been no reported problems. Mitch On 03/21/2013 09:48 AM, Matthew J. Roth wrote: Mitch Claborn wrote: Thank you for that most excellent post. I had guessed at most of the SDP fields and meaning. No problem. I actually like looking at SIP traces for some reason. 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. That's a reasonable conclusion. Just make sure that you get some traces of good calls to verify that your tests are valid. 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. It's always a good idea to rule out PEBKAC before spending a lot of time diagnosing a problem. 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. It really seems like it may be a problem with the softphone. I'm sure the developers of SFLphone will appreciate your feedback, because not sending RTP is a pretty serious bug. I'll keep an eye on this thread and help out if I can. 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
hi Bharat, why you are giving same answer as mine over and over ? please read posts carefully. On Wed, Mar 20, 2013 at 6:48 AM, Bharat Lalcheta bharatlalch...@gmail.comwrote: Did u changed rtp.conf ? port is showing 39408. Asterisk definetly drop rtp packet for this port if not updated in rtp.conf Regards, Bharat Lalcheta -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
That change did not fix the problem. Below is another trace from a failed call this morning. 172.16.0.71 is the client, 172.16.0.245 is the Asterisk server. All the RTP packets after the SIP are from server to client. Any further ideas are appreciated. (If I don't get this fixed this week, I won't get to go home on Friday!) --- No. TimeSourceDestination Protocol Length Info 4528 12:14:07.219165 172.16.0.245 172.16.0.71 SIP/SDP 910Request: INVITE sip:KWakmn@172.16.0.71:5060, with session description Frame 4528: 910 bytes on wire (7280 bits), 910 bytes captured (7280 bits) Ethernet II, Src: 90:b1:1c:0d:c4:35 (90:b1:1c:0d:c4:35), Dst: Dell_e7:fc:b0 (00:25:64:e7:fc:b0) Internet Protocol Version 4, Src: 172.16.0.245 (172.16.0.245), Dst: 172.16.0.71 (172.16.0.71) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: INVITE sip:KWakmn@172.16.0.71:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 172.16.0.245:5060;branch=z9hG4bK7e5fc96a Max-Forwards: 70 From: sip:4062345243@172.16.0.245;tag=as5a63ac9a To: sip:KWakmn@172.16.0.71:5060 Contact: sip:4062345243@172.16.0.245:5060 Call-ID: 50b7a1e27bbb9f6043dfccff16d7be88@172.16.0.245:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.1.0 Date: Wed, 20 Mar 2013 17:14:07 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer X-mm-call: http://www.mcmurrayhatchery.com Content-Type: application/sdp Content-Length: 257 Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): root 582679053 582679053 IN IP4 172.16.0.245 Session Name (s): Asterisk PBX 11.1.0 Connection Information (c): IN IP4 172.16.0.245 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 28340 RTP/AVP 0 8 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): ptime:20 Media Attribute (a): sendrecv -- No. TimeSourceDestination Protocol Length Info 1 12:14:07.251118 172.16.0.71 172.16.0.245 SIP 542Status: 180 Ringing Frame 1: 542 bytes on wire (4336 bits), 542 bytes captured (4336 bits) Ethernet II, Src: Dell_e7:fc:b0 (00:25:64:e7:fc:b0), Dst: 90:b1:1c:0d:c4:35 (90:b1:1c:0d:c4:35) Internet Protocol Version 4, Src: 172.16.0.71 (172.16.0.71), Dst: 172.16.0.245 (172.16.0.245) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 180 Ringing Message Header Via: SIP/2.0/UDP 172.16.0.245:5060;received=172.16.0.245;branch=z9hG4bK7e5fc96a Call-ID: 50b7a1e27bbb9f6043dfccff16d7be88@172.16.0.245:5060 From: sip:4062345243@172.16.0.245;tag=as5a63ac9a To: sip:KWakmn@172.16.0.71;tag=923b9add-5ef2-4f6f-a3f5-4627109e079c CSeq: 102 INVITE Contact: sip:KWakmn@172.16.0.71:5060 Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Content-Length: 0 -- No. TimeSourceDestination Protocol Length Info 5 12:14:18.055112 172.16.0.71 172.16.0.245 SIP/SDP 834Status: 200 OK, with session description Frame 5: 834 bytes on wire (6672 bits), 834 bytes captured (6672 bits) Ethernet II, Src: Dell_e7:fc:b0 (00:25:64:e7:fc:b0), Dst: 90:b1:1c:0d:c4:35 (90:b1:1c:0d:c4:35) Internet Protocol Version 4, Src: 172.16.0.71 (172.16.0.71), Dst: 172.16.0.245 (172.16.0.245) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 172.16.0.245:5060;received=172.16.0.245;branch=z9hG4bK7e5fc96a Call-ID: 50b7a1e27bbb9f6043dfccff16d7be88@172.16.0.245:5060 From: sip:4062345243@172.16.0.245;tag=as5a63ac9a To: sip:KWakmn@172.16.0.71;tag=923b9add-5ef2-4f6f-a3f5-4627109e079c CSeq: 102 INVITE Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Contact: sip:KWakmn@172.16.0.71:5060 Supported: replaces, 100rel Content-Type: application/sdp Content-Length: 234 Message Body Session Description Protocol Session Description Protocol
Re: [asterisk-users] Diagnosing call problem
On Wed, Mar 20, 2013 at 7:11 PM, Asghar Mohammad asghar...@gmail.comwrote: hi, problem seem to client end i am going to install SFLPhone i will let you know when finish, have you check firewall on clients pc? -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
There is no firewall on the client. I've compared the SIP messages between a successful call and a failed call, and I can see no difference except for things like port numbers and call IDs. It only fails occasionally, not on every call. Mitch On 03/20/2013 01:16 PM, Asghar Mohammad wrote: On Wed, Mar 20, 2013 at 7:11 PM, Asghar Mohammad asghar...@gmail.com mailto:asghar...@gmail.com wrote: hi, problem seem to client end i am going to install SFLPhone i will let you know when finish, have you check firewall on clients pc? -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
client phone not sending rtp at all there is nothing to do with sip invites. some firewall blocking rtp packets or softphone is missconfigured. On Wed, Mar 20, 2013 at 7:25 PM, Mitch Claborn mitch...@claborn.net wrote: There is no firewall on the client. I've compared the SIP messages between a successful call and a failed call, and I can see no difference except for things like port numbers and call IDs. It only fails occasionally, not on every call. Mitch On 03/20/2013 01:16 PM, Asghar Mohammad wrote: On Wed, Mar 20, 2013 at 7:11 PM, Asghar Mohammad asghar...@gmail.com mailto:asghar...@gmail.com wrote: hi, problem seem to client end i am going to install SFLPhone i will let you know when finish, have you check firewall on clients pc? -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
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 1-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
Re: [asterisk-users] Diagnosing call problem
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 mr...@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 1-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 --
Re: [asterisk-users] Diagnosing call problem
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 1-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 --
Re: [asterisk-users] Diagnosing call problem
hi satish, try to debug rtp on that ip and look rtp flow you can also test directmedia=no i encounter this as well i server is on public ip and clients connect via vpn , vpn server is also same asterisk server calls come in via public ip and go to call center via vpn i solved this by directmedia=no canreinvite=no On Tue, Mar 19, 2013 at 5:51 AM, Satish Barot satish4aster...@gmail.comwrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.netwrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users Silly guess, If there is no then NAT did you check that your headphones work properly every time you start the softphone? This has happened to me in past. --Satish Barot Ahmedabad, India. -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
I don't believe the headsets are at fault. An agent will have a number of calls that work just fine, then with no apparent change by the agent, a few calls in a row will not work. In some cases, the problem seems to correct itself. In other cases, restarting the agent's computer seems to fix the problem. Mitch On 03/18/2013 11:51 PM, Satish Barot wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- _ -- 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 http://lists.digium.com/mailman/listinfo/asterisk-users Silly guess, If there is no then NAT did you check that your headphones work properly every time you start the softphone? This has happened to me in past. --Satish Barot Ahmedabad, India. -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
Thanks for the suggestions. 1) directmedia was taking the default of yes. I set to no. Will watch and see. 2) NAT is turned off (nat=no). I've never done any RTP debugging. Is that rtp set debug on ip 1.2.3.4? How would I interpret the output? 3) mixmonitor recordings are stored on a local disk (RAID array, very fast) 4) This would have to be a last resort option, as there is a business requirement to record the agent calls Mitch On 03/19/2013 12:01 AM, Bharat Lalcheta wrote: 1) Check directmedia option in sip. If enabled set it to no 2) Check NAT option and RTP debug in live scenario for any particular agent 3) if not solved yet, Where are your storing your mixmonitor recording? On any storage ? If yes, try to record on local harddisk. 4) Remove mixmonitor and test again Hope you find can find problem 99% in above scenario. Regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 10:21 AM, Satish Barot satish4aster...@gmail.com mailto:satish4aster...@gmail.com wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- _ -- 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 http://lists.digium.com/mailman/listinfo/asterisk-users Silly guess, If there is no then NAT did you check that your headphones work properly every time you start the softphone? This has happened to me in past. --Satish Barot Ahmedabad, India. -- _ -- 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 -- Bharat Lalcheta -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
hi, rtp set debug ip 1.2.3.4 On Tue, Mar 19, 2013 at 2:09 PM, Mitch Claborn mitch...@claborn.net wrote: Thanks for the suggestions. 1) directmedia was taking the default of yes. I set to no. Will watch and see. 2) NAT is turned off (nat=no). I've never done any RTP debugging. Is that rtp set debug on ip 1.2.3.4? How would I interpret the output? 3) mixmonitor recordings are stored on a local disk (RAID array, very fast) 4) This would have to be a last resort option, as there is a business requirement to record the agent calls Mitch On 03/19/2013 12:01 AM, Bharat Lalcheta wrote: 1) Check directmedia option in sip. If enabled set it to no 2) Check NAT option and RTP debug in live scenario for any particular agent 3) if not solved yet, Where are your storing your mixmonitor recording? On any storage ? If yes, try to record on local harddisk. 4) Remove mixmonitor and test again Hope you find can find problem 99% in above scenario. Regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 10:21 AM, Satish Barot satish4aster...@gmail.com mailto:satish4asterisk@gmail.**comsatish4aster...@gmail.com wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- __**__** _ -- 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-__**usershttp://lists.digium.com/__mailman/listinfo/asterisk-__users http://lists.digium.com/**mailman/listinfo/asterisk-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users Silly guess, If there is no then NAT did you check that your headphones work properly every time you start the softphone? This has happened to me in past. --Satish Barot Ahmedabad, India. -- __**__** _ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- Bharat Lalcheta -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
witch softphone you are using? on client pc installed some kind of virtualpc like vmware or virtualbox? client pc have more then one network interfaces? you can capture sip invites from soft phone by enabling debug on client ip sip set debug ip ip of softphon upload sip trace then somebody can halp you, should provide more information's. On Tue, Mar 19, 2013 at 5:39 PM, Mitch Claborn mitch...@claborn.net wrote: rtp debug on the calls that do not work correctly shows packets from server to client only, none from client to server. I do have nat=no directmedia=no in sip.conf. Are there other settings that might apply? This last instance that I looked at, the problem persisted even after restarting the client softphone program. It was fixed after rebooting the client computer. Any ideas on a next step for debugging? I was thinking I would start a wireshark trace to see if the rtp packets are actually leaving the client computer. Mitch On 03/19/2013 08:28 AM, Bharat Lalcheta wrote: rtp set debug ip 1.2.3.4 where 1.2.3.4 is ip of your particular agent. Say your x agent is not getting voice, rtp debu his ip. You got rtp packet from and to for that ip. If you find rtp packet from your agent to your server ip and rtp packet from your server to agent ip, then no need to check anything in asterisk. Its related to your agent pc problem If you find any single side rtp, then its problem related to nat or direct media etc. if mix monitor is on storage than only you can face problem and thats also very rare. In that case you get voice in break, but it will be from both side not in single side. So, this is not your problem at all. Hope you will get something in rtp debug. R u using any trunk then also check rtp debug between your server and trunk regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 6:39 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: Thanks for the suggestions. 1) directmedia was taking the default of yes. I set to no. Will watch and see. 2) NAT is turned off (nat=no). I've never done any RTP debugging. Is that rtp set debug on ip 1.2.3.4? How would I interpret the output? 3) mixmonitor recordings are stored on a local disk (RAID array, very fast) 4) This would have to be a last resort option, as there is a business requirement to record the agent calls Mitch On 03/19/2013 12:01 AM, Bharat Lalcheta wrote: 1) Check directmedia option in sip. If enabled set it to no 2) Check NAT option and RTP debug in live scenario for any particular agent 3) if not solved yet, Where are your storing your mixmonitor recording? On any storage ? If yes, try to record on local harddisk. 4) Remove mixmonitor and test again Hope you find can find problem 99% in above scenario. Regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 10:21 AM, Satish Barot satish4aster...@gmail.com mailto:satish4asterisk@gmail.**comsatish4aster...@gmail.com mailto:satish4asterisk@gmail.**__com mailto:satish4asterisk@gmail.**com satish4aster...@gmail.com wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net** wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- __**__** _ -- 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 http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Diagnosing call problem
Firewall can cause problem on client side. Check antivirus or firewall on agent pc Please provide your network setup for getting better idea of problem On Mar 19, 2013 10:10 PM, Mitch Claborn mitch...@claborn.net wrote: rtp debug on the calls that do not work correctly shows packets from server to client only, none from client to server. I do have nat=no directmedia=no in sip.conf. Are there other settings that might apply? This last instance that I looked at, the problem persisted even after restarting the client softphone program. It was fixed after rebooting the client computer. Any ideas on a next step for debugging? I was thinking I would start a wireshark trace to see if the rtp packets are actually leaving the client computer. Mitch On 03/19/2013 08:28 AM, Bharat Lalcheta wrote: rtp set debug ip 1.2.3.4 where 1.2.3.4 is ip of your particular agent. Say your x agent is not getting voice, rtp debu his ip. You got rtp packet from and to for that ip. If you find rtp packet from your agent to your server ip and rtp packet from your server to agent ip, then no need to check anything in asterisk. Its related to your agent pc problem If you find any single side rtp, then its problem related to nat or direct media etc. if mix monitor is on storage than only you can face problem and thats also very rare. In that case you get voice in break, but it will be from both side not in single side. So, this is not your problem at all. Hope you will get something in rtp debug. R u using any trunk then also check rtp debug between your server and trunk regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 6:39 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: Thanks for the suggestions. 1) directmedia was taking the default of yes. I set to no. Will watch and see. 2) NAT is turned off (nat=no). I've never done any RTP debugging. Is that rtp set debug on ip 1.2.3.4? How would I interpret the output? 3) mixmonitor recordings are stored on a local disk (RAID array, very fast) 4) This would have to be a last resort option, as there is a business requirement to record the agent calls Mitch On 03/19/2013 12:01 AM, Bharat Lalcheta wrote: 1) Check directmedia option in sip. If enabled set it to no 2) Check NAT option and RTP debug in live scenario for any particular agent 3) if not solved yet, Where are your storing your mixmonitor recording? On any storage ? If yes, try to record on local harddisk. 4) Remove mixmonitor and test again Hope you find can find problem 99% in above scenario. Regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 10:21 AM, Satish Barot satish4aster...@gmail.com mailto:satish4asterisk@gmail.**comsatish4aster...@gmail.com mailto:satish4asterisk@gmail.**__com mailto:satish4asterisk@gmail.**com satish4aster...@gmail.com wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net** wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- __**__** _ -- 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 http://lists.digium.com/mailman/listinfo/asterisk-users http://lists.digium.com/__**mailman/listinfo/asterisk-__**usershttp://lists.digium.com/__mailman/listinfo/asterisk-__users
Re: [asterisk-users] Diagnosing call problem
We have Ubuntu 12.04 clients, using either SFLPhone or Bria 3. There is no NAT involved in the network at all (it is disabled in sip.conf). Here are the SIP messages capture via wireshark on the client during one problem call. Following these SIP messages, the wireshark trace shows only RTP packets from server (172.16.0.245) to client (172.16.0.71) except for an occasional RTCP packet from client to server (sample below). Any help is appreciated. The uses are really beating me up to get this fixed. INVITE sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=z9hG4bK19e2246d Max-Forwards: 70 From: sip:2392230612@172.16.0.245;tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060 Contact: sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.1.0 Date: Tue, 19 Mar 2013 20:47:26 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer X-mm-call: http://www.mcmurrayhatchery.com Content-Type: application/sdp Content-Length: 257 v=0 o=root 682517197 682517197 IN IP4 172.16.0.245 s=Asterisk PBX 11.1.0 c=IN IP4 172.16.0.245 t=0 0 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=fmtp:101 0-16 a=ptime:20 a=sendrecv --- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.16.0.245:5060;received=172.16.0.245;branch=z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245;tag=as4b489afc To: sip:KWakmn@172.16.0.71;tag=7543f39a-7ca0-434b-8281-e6dc2adc4aa3 CSeq: 102 INVITE Contact: sip:KWakmn@172.16.0.71:5060 Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Content-Length: 0 - SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.0.245:5060;received=172.16.0.245;branch=z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245;tag=as4b489afc To: sip:KWakmn@172.16.0.71;tag=7543f39a-7ca0-434b-8281-e6dc2adc4aa3 CSeq: 102 INVITE Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Contact: sip:KWakmn@172.16.0.71:5060 Supported: replaces, 100rel Content-Type: application/sdp Content-Length: 234 v=0 o=asset071 3572714846 1 IN IP4 172.16.0.71 s=sflphone c=IN IP4 172.16.0.71 t=0 0 m=audio 39408 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:39409 IN IP4 172.16.0.71 --- ACK sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=z9hG4bK289d6da2 Max-Forwards: 70 From: sip:2392230612@172.16.0.245;tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060;tag=7543f39a-7ca0-434b-8281-e6dc2adc4aa3 Contact: sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 ACK User-Agent: Asterisk PBX 11.1.0 Content-Length: 0 SAMPLE RTCP packet from client to server No. TimeSourceDestination Protocol Length Info 240 15:47:39.965483 172.16.0.71 172.16.0.245 RTCP 102Receiver Report Source description Frame 240: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) Ethernet II, Src: Dell_e7:fc:b0 (00:25:64:e7:fc:b0), Dst: 90:b1:1c:0d:c4:35 (90:b1:1c:0d:c4:35) Internet Protocol Version 4, Src: 172.16.0.71 (172.16.0.71), Dst: 172.16.0.245 (172.16.0.245) User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) Real-time Transport Control Protocol (Receiver Report) [Stream setup by SDP (frame 36)] [Setup frame: 36] [Setup Method: SDP] 10.. = Version: RFC 1889 Version (2) ..0. = Padding: False ...0 0001 = Reception report count: 1 Packet type: Receiver Report (201) Length: 7 (32 bytes) Sender SSRC: 0x841ef2ea (2216620778) Source 1 Identifier: 0x28bcc3a6 (683459494) SSRC contents Fraction lost: 254 / 256 Cumulative number of packets lost: 37134 Extended highest sequence number received: 37331 Sequence number cycles count: 0 Highest sequence number received: 37331 Interarrival jitter: 160008128 Last SR timestamp: 0 (0x) Delay since last SR timestamp: 0 (0 milliseconds) Real-time Transport Control Protocol (Source description) [Stream setup by SDP (frame 36)] [Setup frame: 36] [Setup Method: SDP] 10.. = Version: RFC 1889 Version (2) ..0. = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 6 (28 bytes) Chunk 1, SSRC/CSRC 0x841EF2EA
Re: [asterisk-users] Diagnosing call problem
hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:54 PM, Asghar Mohammad asghar...@gmail.comwrote: hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:22 PM, Mitch Claborn mitch...@claborn.netwrote: We have Ubuntu 12.04 clients, using either SFLPhone or Bria 3. There is no NAT involved in the network at all (it is disabled in sip.conf). Here are the SIP messages capture via wireshark on the client during one problem call. Following these SIP messages, the wireshark trace shows only RTP packets from server (172.16.0.245) to client (172.16.0.71) except for an occasional RTCP packet from client to server (sample below). Any help is appreciated. The uses are really beating me up to get this fixed. INVITE sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=**z9hG4bK19e2246d Max-Forwards: 70 From: sip:2392230612@172.16.0.245;**tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060 Contact: sip:2392230612@172.16.0.245:**5060http://sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6**e8@172.16.0.245:5060http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.1.0 Date: Tue, 19 Mar 2013 20:47:26 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer X-mm-call: http://www.mcmurrayhatchery.**comhttp://www.mcmurrayhatchery.com Content-Type: application/sdp Content-Length: 257 v=0 o=root 682517197 682517197 IN IP4 172.16.0.245 s=Asterisk PBX 11.1.0 c=IN IP4 172.16.0.245 t=0 0 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=fmtp:101 0-16 a=ptime:20 a=sendrecv --**- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.16.0.245:5060;received=**172.16.0.245;branch=** z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6**e8@172.16.0.245:5060http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245;**tag=as4b489afc To: sip:KWakmn@172.16.0.71;tag=**7543f39a-7ca0-434b-8281-**e6dc2adc4aa3 CSeq: 102 INVITE Contact: sip:KWakmn@172.16.0.71:5060 Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Content-Length: 0 --**--- SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.0.245:5060;received=**172.16.0.245;branch=** z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6**e8@172.16.0.245:5060http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245;**tag=as4b489afc To: sip:KWakmn@172.16.0.71;tag=**7543f39a-7ca0-434b-8281-**e6dc2adc4aa3 CSeq: 102 INVITE Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Contact: sip:KWakmn@172.16.0.71:5060 Supported: replaces, 100rel Content-Type: application/sdp Content-Length: 234 v=0 o=asset071 3572714846 1 IN IP4 172.16.0.71 s=sflphone c=IN IP4 172.16.0.71 t=0 0 m=audio 39408 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:39409 IN IP4 172.16.0.71 --**- ACK sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=**z9hG4bK289d6da2 Max-Forwards: 70 From: sip:2392230612@172.16.0.245;**tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060;**tag=7543f39a-7ca0-434b-8281-** e6dc2adc4aa3 Contact: sip:2392230612@172.16.0.245:**5060http://sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6**e8@172.16.0.245:5060http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 ACK User-Agent: Asterisk PBX 11.1.0 Content-Length: 0 --**-- SAMPLE RTCP packet from client to server No. TimeSourceDestination Protocol Length Info 240 15:47:39.965483 172.16.0.71 172.16.0.245 RTCP 102 Receiver Report Source description Frame 240: 102
Re: [asterisk-users] Diagnosing call problem
This was the client sending from port 39409 to server port 13429, which is in the range. From what I read, the rtpstart and rtpend define the range that is available for use on the server, so I'm not sure this will apply. But, I've set my range to 5000 - 4. I'll find out tomorrow if it makes any difference. 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. Mitch On 03/19/2013 05:02 PM, Asghar Mohammad wrote: hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:54 PM, Asghar Mohammad asghar...@gmail.com mailto:asghar...@gmail.com wrote: hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:22 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: We have Ubuntu 12.04 clients, using either SFLPhone or Bria 3. There is no NAT involved in the network at all (it is disabled in sip.conf). Here are the SIP messages capture via wireshark on the client during one problem call. Following these SIP messages, the wireshark trace shows only RTP packets from server (172.16.0.245) to client (172.16.0.71) except for an occasional RTCP packet from client to server (sample below). Any help is appreciated. The uses are really beating me up to get this fixed. INVITE sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=__z9hG4bK19e2246d Max-Forwards: 70 From: sip:2392230612@172.16.0.245 mailto:sip%3A2392230612@172.16.0.245;__tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.71:5060 Contact: sip:2392230612@172.16.0.245:__5060 http://sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6__e8@172.16.0.245:5060 http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.1.0 Date: Tue, 19 Mar 2013 20:47:26 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer X-mm-call: http://www.mcmurrayhatchery.__com http://www.mcmurrayhatchery.com Content-Type: application/sdp Content-Length: 257 v=0 o=root 682517197 682517197 IN IP4 172.16.0.245 s=Asterisk PBX 11.1.0 c=IN IP4 172.16.0.245 t=0 0 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=fmtp:101 0-16 a=ptime:20 a=sendrecv --__- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.16.0.245:5060;received=__172.16.0.245;branch=__z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6__e8@172.16.0.245:5060 http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245 mailto:sip%3A2392230612@172.16.0.245;__tag=as4b489afc To: sip:KWakmn@172.16.0.71 mailto:sip%3AKWakmn@172.16.0.71;tag=__7543f39a-7ca0-434b-8281-__e6dc2adc4aa3 CSeq: 102 INVITE Contact: sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.71:5060 Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE, INVITE, ACK, BYE, CANCEL Content-Length: 0 --__--- SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.0.245:5060;received=__172.16.0.245;branch=__z9hG4bK19e2246d Call-ID: 52106f231b41169c7eabd3b43d0fc6__e8@172.16.0.245:5060 http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 From: sip:2392230612@172.16.0.245 mailto:sip%3A2392230612@172.16.0.245;__tag=as4b489afc To: sip:KWakmn@172.16.0.71
Re: [asterisk-users] Diagnosing call problem
The network is all on a single LAN segment - there is no NAT involved anywhere. Agents do not have firewall or active anti-virus. See other posts for a SIP trace. Mitch On 03/19/2013 12:45 PM, Bharat Lalcheta wrote: Firewall can cause problem on client side. Check antivirus or firewall on agent pc Please provide your network setup for getting better idea of problem On Mar 19, 2013 10:10 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: rtp debug on the calls that do not work correctly shows packets from server to client only, none from client to server. I do have nat=no directmedia=no in sip.conf. Are there other settings that might apply? This last instance that I looked at, the problem persisted even after restarting the client softphone program. It was fixed after rebooting the client computer. Any ideas on a next step for debugging? I was thinking I would start a wireshark trace to see if the rtp packets are actually leaving the client computer. Mitch On 03/19/2013 08:28 AM, Bharat Lalcheta wrote: rtp set debug ip 1.2.3.4 where 1.2.3.4 is ip of your particular agent. Say your x agent is not getting voice, rtp debu his ip. You got rtp packet from and to for that ip. If you find rtp packet from your agent to your server ip and rtp packet from your server to agent ip, then no need to check anything in asterisk. Its related to your agent pc problem If you find any single side rtp, then its problem related to nat or direct media etc. if mix monitor is on storage than only you can face problem and thats also very rare. In that case you get voice in break, but it will be from both side not in single side. So, this is not your problem at all. Hope you will get something in rtp debug. R u using any trunk then also check rtp debug between your server and trunk regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 6:39 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net wrote: Thanks for the suggestions. 1) directmedia was taking the default of yes. I set to no. Will watch and see. 2) NAT is turned off (nat=no). I've never done any RTP debugging. Is that rtp set debug on ip 1.2.3.4? How would I interpret the output? 3) mixmonitor recordings are stored on a local disk (RAID array, very fast) 4) This would have to be a last resort option, as there is a business requirement to record the agent calls Mitch On 03/19/2013 12:01 AM, Bharat Lalcheta wrote: 1) Check directmedia option in sip. If enabled set it to no 2) Check NAT option and RTP debug in live scenario for any particular agent 3) if not solved yet, Where are your storing your mixmonitor recording? On any storage ? If yes, try to record on local harddisk. 4) Remove mixmonitor and test again Hope you find can find problem 99% in above scenario. Regards, Bharat Lalcheta On Tue, Mar 19, 2013 at 10:21 AM, Satish Barot satish4aster...@gmail.com mailto:satish4aster...@gmail.com mailto:satish4asterisk@gmail.__com mailto:satish4aster...@gmail.com mailto:satish4asterisk@gmail. mailto:satish4asterisk@gmail.com mailto:satish4asterisk@gmail.__com mailto:satish4aster...@gmail.com wrote: On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net__ wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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
Re: [asterisk-users] Diagnosing call problem
Good point. I changed to 1 - 4. Mitch On 03/19/2013 06:17 PM, Asghar Mohammad wrote: i had this problem with a gateway witch was configured from 1000 to 3000 and some time he was using ports above 2000 and result was one way voice rtp port range is where asterisk expect audio, you should not use ports below 1 because they are in use of other services like 5060 for sip. On Tue, Mar 19, 2013 at 11:57 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net wrote: This was the client sending from port 39409 to server port 13429, which is in the range. From what I read, the rtpstart and rtpend define the range that is available for use on the server, so I'm not sure this will apply. But, I've set my range to 5000 - 4. I'll find out tomorrow if it makes any difference. 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. Mitch On 03/19/2013 05:02 PM, Asghar Mohammad wrote: hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:54 PM, Asghar Mohammad asghar...@gmail.com mailto:asghar...@gmail.com mailto:asghar...@gmail.com mailto:asghar...@gmail.com wrote: hi, User Datagram Protocol, Src Port: 39409 (39409), Dst Port: 13429 (13429) copy from asterisk 11 rtp.conf rtpstart=1 rtpend=2 have you changed port range? if no then your client sending rtp to a port higher then configured in rtp port range and asterisk ignore that port. try to change rtpend=3 or if there is option in softphone restrict it to use same range as in rtp.conf. let me know if this solve you problem. On Tue, Mar 19, 2013 at 10:22 PM, Mitch Claborn mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net mailto:mitch...@claborn.net wrote: We have Ubuntu 12.04 clients, using either SFLPhone or Bria 3. There is no NAT involved in the network at all (it is disabled in sip.conf). Here are the SIP messages capture via wireshark on the client during one problem call. Following these SIP messages, the wireshark trace shows only RTP packets from server (172.16.0.245) to client (172.16.0.71) except for an occasional RTCP packet from client to server (sample below). Any help is appreciated. The uses are really beating me up to get this fixed. INVITE sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.__71:5060 http://sip:KWakmn@172.16.0.71:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.245:5060;branch=z9hG4bK19e2246d Max-Forwards: 70 From: sip:2392230612@172.16.0.245 mailto:sip%3A2392230612@172.16.0.245 mailto:sip%3A2392230612@172.__16.0.245 mailto:sip%253A2392230612@172.16.0.245;__tag=as4b489afc To: sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.71:5060 http://sip:KWakmn@172.16.0.__71:5060 http://sip:KWakmn@172.16.0.71:5060 Contact: sip:2392230612 tel:2392230612@172.16.0.245:__5060 http://sip:2392230612@172.16.__0.245:5060 http://sip:2392230612@172.16.0.245:5060 Call-ID: 52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 http://52106f231b41169c7eabd3b43d0fc6__e8@172.16.0.245:5060 http://__52106f231b41169c7eabd3b43d0fc6__e8@172.16.0.245:5060 http://52106f231b41169c7eabd3b43d0fc6e8@172.16.0.245:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.1.0 Date: Tue, 19 Mar 2013 20:47:26 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer X-mm-call: http://www.mcmurrayhatchery.com http://www.mcmurrayhatchery.__com
Re: [asterisk-users] Diagnosing call problem
Did u changed rtp.conf ? port is showing 39408. Asterisk definetly drop rtp packet for this port if not updated in rtp.conf Regards, Bharat Lalcheta -- _ -- 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
[asterisk-users] Diagnosing call problem
Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
Is the callcenter sitting behind nat? Sent from my iPhone On 18 mrt. 2013, at 19:31, Mitch Claborn mitch...@claborn.net wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
Agents and Asterisk server are in the same network, behind the same firewall, so there is no NAT between agents and the server. The outside calls come in on a T1 fed into the asterisk computer. Mitch On 03/18/2013 01:44 PM, Gertjan Baarda wrote: Is the callcenter sitting behind nat? Sent from my iPhone On 18 mrt. 2013, at 19:31, Mitch Claborn mitch...@claborn.net wrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- _ -- 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 -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Diagnosing call problem
On Tue, Mar 19, 2013 at 12:00 AM, Mitch Claborn mitch...@claborn.netwrote: Asterisk 11.1.0 Various soft-phone SIP clients call center with 10-12 agents online at once using asterisk queue 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. Looking for ideas on how to begin to diagnose this or clues about what might be wrong. Is there a console command that will show details of a specific call in progress that might have some clues? -- Mitch -- __**__**_ -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users Silly guess, If there is no then NAT did you check that your headphones work properly every time you start the softphone? This has happened to me in past. --Satish Barot Ahmedabad, India. -- _ -- 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
