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
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
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
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
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
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
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
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?
--
_
--
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:
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
29 matches
Mail list logo
