Trouble with: call to external, forwarded to internal

hello. i have a problem.
i can work around it, but i would lose functionnality and i dont want to.

i have a avaya cs1000, and multiple asterisk.

the avaya has 6XXX and 3XXX (in general).
the asterisk has the 2XXX numbers (again, in general)

if i take a 2xxx, call 6xxx, wich in turn has a forward call back to a 2xxx number, it fails.
if i have a 6xxx call that forward calls to a 2xxx voicemail:
calls from 6xxx and 3xxx work, 2xxx calls fail.

fail message is
Using INVITE request as basis request - ad3812a8-1e0310ac-13c4-55013-549b9f-2c423a6f-549b9f
Found peer ‘2997’ for ‘2997’ from 172.16.3.153:5060
[2016-01-08 14:51:04] WARNING[23070]: chan_sip.c:15354 check_auth: username mismatch, have <2997>, digest has <MO_ST-ANNE>
[2016-01-08 14:51:04] NOTICE[23070]: chan_sip.c:23900 handle_request_invite: Failed to authenticate device “hugo tab” <sip:2997;phone-context=UnknownUnknown@cssh.qc.ca686b28-1e0310ac-13c4-55013-549b9f-3535ff85-549b9f

outbound route is set as internal, since it points to internal numbers and i need to keep internal CID.

it was as is before the trouble too and working fine.

now, the work around is to treat it as an external route, losing the 2997. when it comes back as an external number, asterisk dont see it as an internal peer and its good. but its not really an usable option…

trunk is a sip trunk:
[nortel]
disallow=all
type=peer
qualify=yes
port=5060
nat=no
host=172.16.3.153
context=from-trunk-sip-nortel
canreinvinte=no
allow=ulaw
allow=alaw
allow=gsm

i’m sure it was working before an upgrade, so it must be something in the configs.
its a production server (call it PS) that has been updraded to the same version as another one (call it BS). PS was an old asterisk/freepbx, has been upgraded to same version as BS, PS was backup’d and restored to BS, in effect transfering all the configs from one to the other.
system has been running for a while. old PS was up 4 years, new BS was up 2 months.

here is the sip set debug which contain all the usable info:

<— SIP read from UDP:172.16.3.153:5060 —>
INVITE sip:2993;phone-context=cdp.udp@cssh.qc.ca;user=phone SIP/2.0
Record-Route: sip:7917e1d2@172.16.3.153;transport=udp;lr
Record-Route: sip:172.16.3.152:15060;lr;sap=752120364*1*016asm-callprocessing.sar-1744629844~1452282664473~590664232~1
Record-Route: sip:7917e1d2@172.16.3.153;transport=tcp;lr
From: “hugo tab” sip:2997;phone-context=UnknownUnknown@cssh.qc.ca;user=phone;tag=ad686b28-1e0310ac-13c4-55013-549b9f-3535ff85-549b9f
To: sip:2993;phone-context=cdp.udp@cssh.qc.ca;user=phone
Call-ID: ad3812a8-1e0310ac-13c4-55013-549b9f-2c423a6f-549b9f
CSeq: 2 INVITE
Via: SIP/2.0/UDP 172.16.3.153;rport;branch=z9hG4bKAC100398FFFFFFFFC9C0854B0944636-AP;ft=172.16.3.153~13c4
Via: SIP/2.0/UDP 172.16.3.152:15070;branch=z9hG4bKAC100398FFFFFFFFC9C0854B0944636
Via: SIP/2.0/UDP 172.16.3.152:15070;branch=z9hG4bKAC100398FFFFFFFFC9C0854B1944634
Via: SIP/2.0/UDP 172.16.3.152:15070;branch=z9hG4bKAC100398FFFFFFFFC9C0854B1944633
Via: SIP/2.0/TCP 172.16.3.153;branch=z9hG4bK-549ba0-4a7fe906-19d6de68-AP;ft=648
Via: SIP/2.0/TCP 172.16.3.30:5060;branch=z9hG4bK-549ba0-4a7fe906-19d6de68
Supported: x-nortel-sipvc, replaces
User-Agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17 AVAYA-SM-6.1.7.0.617012
P-Asserted-Identity: “hugo tab” sip:2997;phone-context=UnknownUnknown@cssh.qc.ca;user=phone
Privacy: none
History-Info: sip:6213;phone-context=cdp.udp@cssh.qc.ca;user=phone?reason=sip%3Bcause%3D302%3Btext%3D"Moved%20Temporarily";index=1,sip:2993;phone-context=cdp.udhone;index=2
Alert-Info: cid:external@cssh.qc.ca
Contact: sip:2997;phone-context=UnknownUnknown@cssh.qc.ca:5060;maddr=172.16.3.30;transport=tcp;user=phone
Authorization: Digest username=“MO_ST-ANNE”,realm=“asterisk”,nonce=“74e0c343”,uri="sip:2993;phone-context=cdp.udp@cssh.qc.ca;user=phone",response="ae95d6b54afec9375bb1ithm=MD5
Allow: INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,OPTIONS,INFO,SUBSCRIBE
Content-Type: multipart/mixed;boundary=unique-boundary-1
Content-Length: 781
Route: sip:10.24.11.217;lr;phase=terminating
P-Location: SM;origlocname=“CSSH”;termlocname="CSSH"
Max-Forwards: 66

the History tag show why its coming back. 6213, moved temporarily (call forwarded) to 2993, but the message is kind of all distorted…

i use the legacy_useroption_parsing = yes, because the avaya add ";phone-context=cdp.udp@cssh.qc.ca;user=phone" to the number, where before i used a little patch in my context:
;exten => _X.,1,Set(GROUP()=OUT_1)

;exten => _X.,2,Goto(from-trunk,${EXTEN:0:-22},1)

to remove the message.

anyone has an idea how to resolve this? i can work on it on the weekends, but the week days, between 6 and 18 its pretty busy…

i really need help here. thanks a lot!

hugo

You’ve configured to authenticate the caller but they haven’t authenticated themselves the way you wanted them to do. This looks more like an Avaya issue than an Asterisk one, but normally one wouldn’t authenticate such trunks anyway.

ok thanks.
only problem is, on the earlier production server i didnt have this problem and the configs got restored from it.

maybe its a glitch from the restore but…

i dont have the slightest idea how to start looking for that.

trunk config is the same, no auth whatsoever.
anonymous inbound call allowed, sip guest allowed too.
avaya trunk config didnt change in almost 6 years of happy trunking…

do you have any idea where to start, because i ran out a couple of days ago. it’s why i posted here…

thanks a lot for your time.

You are probably use type=friend when you should be using type=peer. There are very few cases when type=friend makes sense.

With type=friend, a caller ID match will take precedence over an IP match on the trunk.

trunk is defined as:

type=peer
qualify=yes
port=5060
nat=no
host=172.16.3.153
disallow=all
context=from-trunk-sip-nortel
canreinvinte=no
allow=ulaw&alaw&gsm

and always has been. thats why it makes absolutly no sense to me.

This happens when you define the “extensions” as type=friend. If the incoming call on the trunk has a caller ID matching the sip.conf name for an “extension”, Asterisk thinks the call is coming from that extension and requests authentication on that basis.

“Extension” refers to SIP devices that are simple ones, like phones, not to the Asterisk concept of an extension.

ok.
so what do you suggest i set the extensions to?
they are as friend, always has been.

i got peer and user…

trying user get me wrong password at registration. (using only one extension for testing since i have 200+ on that server)

can i tell asterisk to treat them another way?
i’m lost here because previous version 1.8.something didnt act like this, or if it did, it didnt impact the way its working.
work around for now is to treat the avaya trunk as an extenal trunk, not as an intra-company route. the 3 others pure asterisk trunk dont have the problem…

here is my current version.
Asterisk 10.12.2 built by root @ Asterisk-Deb64-FR on a x86_64 running Linux on 2015-01-21 00:23:28 UTC

peer is what you should normally set everything to.

tried setting ext. 2997 to peer.
it’s working.

should have read this earlier:

; SIP entities have a ‘type’ which determines their roles within Asterisk.
; * For entities with ‘type=peer’:
; Peers handle both inbound and outbound calls and are matched by ip/port, so for
; The case of incoming calls from the peer, the IP address must match in order for
; The invitation to work. This means calls made from either direction won’t work if
; The peer is unregistered while host=dynamic or if the host is otherise not set to
; the correct IP of the sender.
; * For entities with ‘type=user’:
; Asterisk users handle inbound calls only (meaning they call Asterisk, Asterisk can’t
; call them) and are matched by their authorization information (authname and secret).
; Asterisk doesn’t rely on their IP and will accept calls regardless of the host setting
; as long as the incoming SIP invite authorizes successfully.
; * For entities with ‘type=friend’:
; Asterisk will create the entity as both a friend and a peer. Asterisk will accept
; calls from friends like it would for users, requiring only that the authorization
; matches rather than the IP address. Since it is also a peer, a friend entity can
; be called as long as its IP is known to Asterisk. In the case of host=dynamic,
; this means it is necessary for the entity to register before Asterisk can call it.

a really big thank you to david55.