Dialling Problem in Sip Trunk Between 2 Asterisk Server



i am facing problem dialing problem on sip trunk between two asterisk server. sip trunk are up and running perfectly. problem arises when the calling sip peer exist on the destination machine. i.e if 200 on machine A calls 300 on machine B and machine B also have the peer 200 configured then it failed the authentication

on origination machine i see the following error.

-- Executing [82@TAC-Check:1] Dial("SIP/9000-00001c3d", "SIP/pcc-gcc/82") in new stack
-- Called pcc-gcc/82

[Oct 7 15:43:18] WARNING[16461]: chan_sip.c:13681 handle_response_invite: Received response: “Forbidden” from ‘“9000” sip:9000@;tag=as0bd9cd19’
– SIP/pcc-gcc-00001c3e is circuit-busy

on destination machine

[Oct 7 15:43:18] WARNING[16593]: chan_sip.c:9469 check_auth: username mismatch, have <9000>, digest has
[Oct 7 15:43:18] NOTICE[16593]: chan_sip.c:15694 handle_request_invite: Failed to authenticate user “9000” sip:9000@;tag=as0bd9cd19

please help me out in this problem. my both machine has same sip peer configured and are identical.


This sounds like problem with SIP “Users” not SIP “Peers”.

If you can’t actually use peers (rather than friend or user), you may be able to use sendrpid/trustrpid to continue to send valid CLID, and then use fromuser to ensure that you don’t clash with any SIP users on the destination machine.


I’ve got a similar problem.
But when the same user exists in both sides, the call falls in the wrong context (the one associated to the user instead of ‘incomming’)
I’ve fixed it with fromuser, so now the caller-id will be the name of the trunk, the problem is that now the caller-id will be the name of the trunk, xP.

Using what david55 suggested make it work as it should. ¿What are the side effects of trustrpid=yes ?


The reason you might not want to use it is because you don’t trust the operator of the upstream system. A similar case applies with trying to force CLID on outgoing “trunks”. Most responsible service providers won’t allow it because it can be used to misrepresent the origin of the call. However, as I understand your case, you do trust this source.


Thanks a lot.