[SOLVED] Problem with Avaya IP 500

Asterisk Asterisk Support
1

Greetings,
I have just upgraded an Asterisk 1.6.2-9 to Asterisk 1.8.13-1 (Debian distribution) and started to notice a problem with Avaya IP 500, configured as Asterisk’s peer and Avaya’s IP trunk : all the outbound calls (Avaya -> Asterisk) are refused since they are routed to the default context instead of the peer specific one.

This is the INVITE trace :

<INVITE sip:callednumber@x.x.x.x SIP/2.0
Via: SIP/2.0/UDP 10.1.1.179:5061;rport;branch=z9hG4bK36501385531d82ea01f6b96a100b85b3
From: "sipaccount" <sip:callerid@x.x.x.x>;tag=c9236b471d56b0a0
To: <sip:callednumber@x.x.x.x>
Call-ID: 7bd2d4844e2088e3e8d489a9b8b4f4b3@10.1.1.179
CSeq: 1888206299 INVITE
Contact: "sipaccount" <sip:callerid@10.1.1.179:5061;transport=udp>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
ontent-Type: application/sdp
Supported: timer
P-Asserted-Identity: "sipaccount" <sip:callerid@10.1.1.179:5061>
Content-Length: 223

v=0
o=UserA 2058485307 1461382690 IN IP4 10.1.1.179
s=Session SDP
c=IN IP4 10.1.1.179
t=0 0
m=audio 49156 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
--- (13 headers 10 lines) ---
Sending to y.y.y.y:5061 (NAT)
Using INVITE request as basis request - 7bd2d4844e2088e3e8d489a9b8b4f4b3@10.1.1.179
No matching peer for 'callerid' from 'y.y.y.y:5061'
Found RTP audio format 18
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10e (gsm|ulaw|alaw|g729), peer - audio=0x100 (g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.1.1.179:49156
Looking for callednumber in incoming-sip (domain x.x.x.x)

[Oct 23 14:33:10] NOTICE[11740]: chan_sip.c:22753 handle_request_invite: Call from '' (y.y.y.y:5061) to extension 'callednum' rejected because extension not found in context 'incoming-sip'.

incoming-sip is the default context set in sip.conf, while the peer should use external-default as default context.
x.x.x.x is the public Asterisk IP address while y.y.y.y is the Avaya IP address.

The peer configuration is :

[sipaccount]
accountcode=54042
callerid=calleridnumber
secret=xxxxxxxxxxxxxx
type=peer
host=dynamic
dtmf=rfc2833
context=external-default
nat=yes
qualify=yes

This problem seems to only happen when the peer is not registered to Asterisk. When the peer is registered the calls gets thru. Unfortunately the peer (Avaya) keeps to register and de-register continuosly (every 60 seconds) due to network topology and I can’t do anything about it since I have no way to access Avaya firewall.

As far as I can see the problem is that Asterisk 1.6 was not caring too much about Invite FROM while Asterisk 1.8 doesn’t likes the fact the Avaya uses the Asterisk’s IP address in the uri part of the Invite FROM, but I’m not sure.

Do you have any ideas on how can I solve this problem ?

I have already tried to change Avaya configuration to make it send From: “sipaccount” sip:callerid@y.y.y.y in the INVITE but I wasn’t able to do so.

Thanks a lot!

2

You probably should have allowguest=no, but you are still going to get calls from unregistered peers rejected, just earlier.

3

Thank you for your response!

Yes I had allowguest=no set in sip.conf but I removed it to try to understand where the problem was.

The strange thing is that with Asterisk 1.6 it was working fine and I have unregistered peers still making calls with Asterisk 1.8. It is only this specific peer that seems to have problems.

Do you think that changing the FROM invite to : From: “sipaccount” sip:callerid@remotepeerip could solve the problem or is it another way to make a temporary unregistered peer to make a call (registration caching or something similar ?)

Thanks!

4

How is Asterisk supposed to identify an unregistered peer?

5

I was thinking about the registration cache assuming that the peer is trying to call using the same IP address as in the realtime cache but it doesn’t works.

If I authenticate the peer based on his public IP address (it is natted thru a static pubblic IP) would it solve the problem even if the peer is not registered ?

6

If you know the contact address, there is no need to register. Registration is about associating an address of record with a contact address.

7

It fixed my problem indeed!

Thank you very much for your help