Closed GoogleCodeExporter closed 9 years ago
More information:
This happens when I call another extension in my same LAN.
If I make call to PSTN audio works both ways, but I hear distorted (ie.
robotized) echo at my end. This does not happen with other SIP clients.
Original comment by mau...@gmail.com
on 9 Dec 2010 at 8:48
Even more info:
Echo cancellation turned off at CSipSimple end. Problem persists with echo
cancellation enabled. If I enable speakerphone audio goes horribly choppy.
Finally CSipSimple dies (as reported in previous issue).
Original comment by mau...@gmail.com
on 9 Dec 2010 at 8:53
Can you try with solution described in issue 449 ?
Maybe linked to psp is also problematic on this device ( symptoms sounds
identical).
If you can also try a reboot of the phone.
Original comment by r3gis...@gmail.com
on 9 Dec 2010 at 9:05
Don't think it's related to issue 449 because from the same LAN I connect to an
Asterisk box in the Internet and it works ok. It's funny it works OK doing NAT
traversal and fails with this Grandstream PBX at the same LAN.
Issues with Grandstream PBX are divided in two:
1) No incoming audio when calling another SIP client connected to same PBX.
Outgoing audio received OK by the other client.
2) Audio in/out when calling through the PSTN trunk, but I hear robotized echo
and choppy sound
I would usually suspect from the IPPBX appliance with these symptoms, but the
problem is it works ok with other SIP clients other than CSipSimple.
Original comment by mau...@gmail.com
on 9 Dec 2010 at 11:43
Ok I think you point it out when you said :
"it works OK doing NAT traversal and fails with this Grandstream PBX at the
same LAN."
It's cause pjsip sip stack consider one unique "public" IP. As consequence if
your SIP server is outside your network or if you activate STUN, pjsip will try
to ensure your public IP is the one seen by your sip server. Not the one in
your LAN.
If your granstream is configured to not use your SIP server as proxy you'll
fall in this problem.
In fact you have several possible configurations with pjsip that may works in
all cases.
If your sip server is accessible from LAN. Use DNS to resolve LAN IP of your
SIP server when you are in LAN and public IP when you are in public network. As
consequence the given "public IP" of your SIP client will always be correct.
Also disable STUN (or use it on a STUN server that is on your LAN too). If you
can't configure your DNS properly you can also disable the rewrite contact
feature of CSipSimple (see FAQ).
If your sip server is on the public area, your should ensure that your(s)
access point allow loop back, cause obviously, (unless you call using direct
IP), packets will try to go out using external interface (visible by the sip
server) and re-enter your network. If your network does not allow that, same
problem ...
So in your case I guess only a problem with configuration. NAT / networks
problems are really complex, you have to be clear with what you are trying to
do (how data packets should go through the network) and how you configure SIP
clients.
Getting some logs from csipsimple may helps (see HowToCollectLogs) to know what
is the public IP announced by CSipSimple and understand where Grandstream send
its media packets (if your ippbx does not media gateway - which would be a good
idea to solve all problems).
Original comment by r3gis...@gmail.com
on 5 Mar 2011 at 1:17
Forgot to say, I merge with issue 345, cause if you have 2 sip accounts, you
may have this problem cause pjsip only have one public IP. (so even without
STUN pjsip will try to resolve its public IP once).
Original comment by r3gis...@gmail.com
on 5 Mar 2011 at 1:18
Original issue reported on code.google.com by
mau...@gmail.com
on 9 Dec 2010 at 8:31