403 Fobidden Problem while making Trunk Incoming call

Dear all,

I am having two PBX connected together say PBXA and PBXB. PBXA i am having users 10001,10002,10003 and trunk called 20003 which is registered to PBX_B. PBX_B also having sme users 10001,10002,10003 .

PBX_A ==> 10001,10002 ,10003

PBX_B ==> 10001,10002,10003

Now when i am calling PBX_B to PBX_A using trunk 20003 by 10001 user it is giving me 403 forbidden error in PBX_A . And in asterisk console am getting the error like this.

If i am making any other user in PBXB which is not in PBXA i am able to make calls and it is working fine.

“chan_sip.c line:11375 func: check_auth username mismatch, have <10001>, digest has <20003>”

Peer Configuration
[20003]
type=friend
username=20003
authuser=20003
secret=20003
context=PBXB_INCOMING
nat=yes
host=PBXB_IP
insecure=invite
qualify=yes
dtmfmode=rfc2833
fromuser=20003
fromdomain=PBXB_IP
dtmfmode=AUTO
disallow=all
allow=ALAW
allow=ULAW

Thanks in Advance

Andrew

Make a SIP Trunk between the Asterisk boxes static (no registration and authentication, just define a SIP Peer on each side and put in static IP addresses for the host parameter in sip.conf)

Can any one confirm whether this issue with asterisk or any configuration problem .

Thanks And Regards

Andrew

Almost certainly a configuration problem. Whilst definitely confirming it would require the configuration from the other side, there is no point in doing so, as the advice already given is the easiest, simply use static addresses without any authentication beyond the address match.

If you are going to authenticate this way, both sides must use the same user and password, as there is no provision for separate incoming and outgoing ones.

Actually, the insecure=invite makes a nonsense of authentication in a static address environment.

I have exactly the same problem, but I have static IPs - sip.conf’s from:

a) server A:

[serverB]
host=SERVER_B_IP_ADDRESS
context=incomming
nat=yes
canreinvite=no
dtmfmode=rfc2833
insecure=port,invite
disallow=all
allow=alaw
type=peer
sendrpid=yes

b) server B:
[serverA]
host=SERVER_A_IP_ADDRESS
context=incomming
nat=yes
canreinvite=no
dtmfmode=rfc2833
insecure=port,invite
disallow=all
allow=alaw
type=peer
sendrpid=yes

and whan I try to make call from user 1000 from server A to server B, when on the server B there is also user 1000 with different password I have 403 Forbidden. Any ideas?

That’s because 1000 needs to be defined as a peer. There is rarely any need to use anything other than peer, with SIP.

Also, hardly anyone needs insecure=port. insecure=invite is only meaningful when registering with dynamic addresses. canreinvite is deprecated and you should use directmedia now. nat=yes is rarely needed, and should not be needed at all if the other part is Asterisk, unless you have a badly broken NAT router; it is a workaround for broken NAT implementations. Although there may have been changes as a result of connected line update, I don’t believe sendrpid is useful unless the other side has trustrpid.

Problem is most complicated - f.e. Server A is box of my customer and Server B is my server. I dont know his user list and passwords - I only want to make interconnection between boxes.

If you can’t get him to correctly use peer, the alternative is to set fromuser, to something he would never use for an extension, and sendrpid and get him to set trustrpid. On your side, you can correctly set your local sip peers to be type=peer. You should really also follow the security advice and use the MAC address as the peer name, which makes them globally unique and completely avoids the problem.

The preferred method of doing Asteris to Asterisk trunks is acutally IAX, but I have no experience of it, and some of the same issues may apply.

Setting fromuser is not a solution, becouse it changes callerid. In my config type=peer is set, so I dont understand what should I correct?

That’s why you have to send caller ID by an alternative method, e.g. Remote Party ID, in the suggested configuration.

fromuser is a work round for a remote side that has been configured for use with an extension, rather than a trunk, so the real solution is to configure the remote side correctly.

Correction, that’s the normal use of fromuser. In this case, it is a workround for the misuse of type=friend in the remote system. User matches take precedence over peer matches.