Incoming call assigned to incorrect sip trunk

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#1
Using Elastix 1.6-12.

I have 2 accounts with CIK, 111111 and 222222.

When call coiming in from 111111, it always assigns it to peer 222222. This is normally not a problem, but if I initate a sip REFER, then the incorrect username/password is sent to CIK and the transfer will fail.

The following is a log of the sip conversation:

[Nov 23 19:22:41] VERBOSE[3303] logger.c:
<--- SIP read from 64.34.25.118:5060 --->
************ call coming from account 111111 *****************
INVITE sip:111111@cmtor1.ciktel.com:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 64.34.25.118:5060;rport;branch=z9hG4bK70b932e3f30d25e64b803e9b27bba989
From: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
To: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 1 INVITE
Contact: <sip:64.34.25.118:5060>
Remote-Party-ID: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060>;party=calling;screen=yes;Privacy=off
max-forwards: 70
Allow: ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE
Content-Type: application/sdp
Content-Length: 292

v=0
o=Clarent 191953 191954 IN IP4 64.34.25.121
s=Clarent CallManager
c=IN IP4 64.34.25.121
t=0 0
m=audio 40288 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=yes
a=silenceSupp:eek:n - - - -
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<------------->
[Nov 23 19:22:41] VERBOSE[3303] logger.c: --- (12 headers 13 lines) ---
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Sending to 64.34.25.118 : 5060 (no NAT)
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Using INVITE request as basis request - 1912422009-838E237D32022311711@64.34.25.118
************ Problem here -> created under peer 222222 instead of 111111 ************
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found peer '222222'
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found RTP audio format 18
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found RTP audio format 0
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found RTP audio format 101
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Peer audio RTP is at port 64.34.25.121:40288
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found audio description format G729 for ID 18
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found audio description format PCMU for ID 0
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Found audio description format telephone-event for ID 101
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Capabilities: us - 0x100 (g729), peer - audio=0x104 (ulaw|g729)/video=0x0 (nothing), combined - 0x100 (g729)
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Peer audio RTP is at port 64.34.25.121:40288
[Nov 23 19:22:41] VERBOSE[3303] logger.c: Looking for 111111 in from-trunk (domain cmtor1.ciktel.com)
[Nov 23 19:22:41] VERBOSE[3303] logger.c: list_route: hop: <sip:64.34.25.118:5060>
[Nov 23 19:22:41] VERBOSE[3303] logger.c:
<--- Transmitting (NAT) to 64.34.25.118:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 64.34.25.118:5060;branch=z9hG4bK70b932e3f30d25e64b803e9b27bba989;received=64.34.25.118;rport=5060
From: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
To: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:111111@192.168.2.191>
Content-Length: 0


<------------>
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [111111@from-trunk:1] NoOp("SIP/222222-b7300468", "Catch-All DID Match - Found 111111 - You probably want a DID for this.") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [111111@from-trunk:2] Goto("SIP/222222-b7300468", "ext-did|s|1") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Goto (ext-did,s,1)
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:1] Set("SIP/222222-b7300468", "__FROM_DID=s") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:2] Gosub("SIP/222222-b7300468", "app-blacklist-check|s|1") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@app-blacklist-check:1] LookupBlacklist("SIP/222222-b7300468", "") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@app-blacklist-check:2] GotoIf("SIP/222222-b7300468", "0?blacklisted") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@app-blacklist-check:3] Return("SIP/222222-b7300468", "") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:3] ExecIf("SIP/222222-b7300468", "0 |Set|CALLERID(name)=416xxxxxx") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:4] Set("SIP/222222-b7300468", "__CALLINGPRES_SV=allowed_not_screened") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:5] SetCallerPres("SIP/222222-b7300468", "allowed_not_screened") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [s@ext-did:6] Goto("SIP/222222-b7300468", "from-pstn|44|1") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Goto (from-pstn,44,1)
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [44@from-pstn:1] Answer("SIP/222222-b7300468", "") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: Audio is at 192.168.2.191 port 11632
[Nov 23 19:22:41] VERBOSE[4616] logger.c: Adding codec 0x100 (g729) to SDP
[Nov 23 19:22:41] VERBOSE[4616] logger.c: Adding non-codec 0x1 (telephone-event) to SDP
[Nov 23 19:22:41] VERBOSE[4616] logger.c:
<--- Reliably Transmitting (NAT) to 64.34.25.118:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.34.25.118:5060;branch=z9hG4bK70b932e3f30d25e64b803e9b27bba989;received=64.34.25.118;rport=5060
From: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
To: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>;tag=as575a0ad1
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:111111@192.168.2.191>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 3192 3192 IN IP4 192.168.2.191
s=session
c=IN IP4 192.168.2.191
t=0 0
m=audio 11632 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv

<------------>
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [44@from-pstn:2] NoOp("SIP/222222-b7300468", "answered") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [44@from-pstn:3] Playback("SIP/222222-b7300468", "transfer") in new stack
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- <SIP/222222-b7300468> Playing 'transfer' (language 'en')
[Nov 23 19:22:41] VERBOSE[3303] logger.c:
<--- SIP read from 64.34.25.118:5060 --->
ACK sip:111111@192.168.2.191 SIP/2.0
Via: SIP/2.0/UDP 64.34.25.118:5060;rport;branch=z9hG4bK0ae637382a264d3898dcc8fc7c20ca1c
From: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
To: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>;tag=as575a0ad1
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 1 ACK
Contact: <sip:64.34.25.118:5060>
Remote-Party-ID: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060>;party=calling;screen=yes;Privacy=off
max-forwards: 70
Allow: ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE


<------------->
[Nov 23 19:22:41] VERBOSE[3303] logger.c: --- (10 headers 0 lines) ---
[Nov 23 19:22:43] VERBOSE[4616] logger.c: -- Executing [44@from-pstn:4] Transfer("SIP/222222-b7300468", "416yyyyyy") in new stack
[Nov 23 19:22:43] DEBUG[4616] chan_sip.c: SIP transfer of 1912422009-838E237D32022311711@64.34.25.118 to 416yyyyyy
[Nov 23 19:22:43] DEBUG[4616] chan_sip.c: Strict routing enforced for session 1912422009-838E237D32022311711@64.34.25.118
[Nov 23 19:22:43] VERBOSE[4616] logger.c: set_destination: Parsing <sip:64.34.25.118:5060> for address/port to send to
[Nov 23 19:22:43] VERBOSE[4616] logger.c: set_destination: set destination to 64.34.25.118, port 5060
[Nov 23 19:22:43] VERBOSE[4616] logger.c: Reliably Transmitting (NAT) to 64.34.25.118:5060:
REFER sip:64.34.25.118:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.191:5060;branch=z9hG4bK454f1339;rport
From: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>;tag=as575a0ad1
To: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
Contact: <sip:111111@192.168.2.191>
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 102 REFER
User-Agent: Asterisk PBX
Max-Forwards: 70
Refer-To: <sip:4168043390@64.34.25.118:5060;user=phone>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Referred-By: <sip:111111@192.168.2.191>


---
[Nov 23 19:22:43] VERBOSE[4616] logger.c: -- Executing [44@from-pstn:5] Wait("SIP/222222-b7300468", "1") in new stack
[Nov 23 19:22:43] VERBOSE[3303] logger.c:
<--- SIP read from 64.34.25.118:5060 --->
SIP/2.0 401 UNAUTHORIZED
Via: SIP/2.0/UDP 192.168.2.191:5060;branch=z9hG4bK454f1339;rport
From: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>;tag=as575a0ad1
To: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 102 REFER
WWW-Authenticate: Digest realm="64.34.25.118", nonce="2E66804A1F3A0037859637EAE80D155D", opaque="20A33F946B13F22165F7D08AB773B001", algorithm=md5
User-Agent: Asterisk PBX
Content-Length: 0


<------------->
[Nov 23 19:22:43] VERBOSE[3303] logger.c: --- (9 headers 0 lines) ---
[Nov 23 19:22:43] VERBOSE[3303] logger.c: SIP Response message for INCOMING dialog REFER arrived
[Nov 23 19:22:43] DEBUG[3303] chan_sip.c: Strict routing enforced for session 1912422009-838E237D32022311711@64.34.25.118
[Nov 23 19:22:43] VERBOSE[3303] logger.c: set_destination: Parsing <sip:64.34.25.118:5060> for address/port to send to
[Nov 23 19:22:43] VERBOSE[3303] logger.c: set_destination: set destination to 64.34.25.118, port 5060
[Nov 23 19:22:43] VERBOSE[3303] logger.c: Reliably Transmitting (NAT) to 64.34.25.118:5060:
REFER sip:64.34.25.118:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.191:5060;branch=z9hG4bK6599ae81;rport
From: "111111@cmtor1.ciktel.com" <sip:111111@cmtor1.ciktel.com:5060>;tag=as575a0ad1
To: "Andy Lam (ITJUM" <sip:416xxxxxx@64.34.25.118:5060;user=phone>;tag=GR52RWG346-34
Contact: <sip:111111@192.168.2.191>
Call-ID: 1912422009-838E237D32022311711@64.34.25.118
CSeq: 103 REFER
User-Agent: Asterisk PBX
Max-Forwards: 70
************ Incorrect username/password is sent **************
Authorization: Digest username="222222", realm="64.34.25.118", algorithm=MD5, uri="cmtor1.ciktel.com", nonce="2E66804A1F3A0037859637EAE80D155D", response="c6fbd155c8a92bd82a636fbf9f7bdbd9", opaque="20A33F946B13F22165F7D08AB773B001"
Date: Tue, 24 Nov 2009 00:22:43 GMT
Refer-To: <sip:4168043390@64.34.25.118:5060;user=phone>
Referred-By: <<sip:111111@192.168.2.191>>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Standard trunk setup:

trunk Name:
1111111

Peer Details:
username=111111
type=friend
secret=xxxx
qualify=yes
nat=yes
insecure=very
host=CMTor1.ciktel.com
fromuser=111111
fromdomain=CMTor1.ciktel.com
disallow=all
context=from-trunk
canreinvite=no
allow=g729

Register String:
111111:xxxx@CMTor1.ciktel.com

Another section for 222222.

Is this a bug in asterisk or do I have some errors in my setting?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#2
[snip]
[Nov 23 19:22:41] VERBOSE[4616] logger.c: -- Executing [111111@from-trunk:1] NoOp("SIP/222222-b7300468", "Catch-All DID Match - Found 111111 - You probably want a DID for this." in new stack

Don't confuse trunks with routes, they are not the same thing. (ref: "E.W.T." )

How is your inbound route set (if at all) for 2222222 ?. 111111 seems to be your catchall route, so the calls go there in the absence of a more specific route match.
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#3
Re:Incoming call assigned to incorrect sip channel

I should have said channel instead of trunk. I guess for this case channel and trunk are interchangable since only one channel per trunk.

Just one catch-all route going to a "custom destination"

[from-pstn]
exten => 44,1,Answer
exten => 44,n,NoOp(answered)
exten => 44,n,Playback(transfer)
exten => 44,n,Transfer(416yyyyyyy)
exten => 44,n,Wait(1)
exten => 44,n,Hangup

exten => h,1,Hangup

It won't matter whether I have just one or separate inbound routes as they will go to the same "custom destination".

The incoming INVITE is from sip trunk 111111 (channel 111111), I do not understand why Peer 222222 is found. It should associate the channal to 111111, not 222222. It will work if I disable sip trunk 222222.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
You might try rewriting your context to use Transfer(SIP/<trunk1>/416yyyyyyy) where <trunk1> is the name of the trunk that is the one that carried your inbound call, and of course add one for <trunk2>, Then the inbound routing can be used to differentiate which part of your context the call lands on. (assuming your trunks will carry more than one concurrent call.)

[edit]
sorry I tried that it won't accept the trunk bit just the technology, but you could maybe mangle your dial plan in trunk and routes to force the choice of one trunk,

transfer(SIP/111416yyyyyyy) for calls on inbound 111111
transfer(SIP/222416yyyyyyy) for calls on inbound 222222


trunk dial rules
trunk1 rule 111|416yyyyyy
trunk2 rule 222|416yyyyyy

and probably add

111416yyyyyy
222416yyyyyy

to your outbound route which I assume includes trunk1 and trunk2
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#5
thanks for the suggestion. I will try that. Actually, I may be able to strip the correct channel from the extension variable.

But do you think there is something wrong somewhere ?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#6
I edited, basically transfer is quite braindead and just blindly sends the REFER without any concern it will dial out by the next available trunk as defined in your outbounds and if it is SIP to SIP use REFER, so to make it symmetrical I think you need to kludge/mangle it to fool it into using the same trunk that it came in on, and possibly not answer the call if you only have one channel per trunk and you just want to send a REFER back, of course the announcement then becomes spurious.

I might be wrong though I often am :)
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#7
Shouldn't transfer just send the REFER to the incoming channel? It should not use a new channel. It should not do a dial, which will use a new channel.

The difference between what I want to do (transfer/refer) is to do the transfer at the provider level, freeing up the incoming channel/trunk for the next call.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#8
It probably should but transfer is technology agnostic and quite broken for SIP

http://www.voip-info.org/wiki/view/Aste ... d+Transfer

and specifically within

Olle in Jan 2006: Transfer() is currently the only way to issue an outbound SIP REFER in the dial plan.
The transfer() application sends a REFER, then totally ignores what is happening with the transfer. It does need a total rewrite for all VoIP channels and should propably be considered a bad hack (read more).


That you have stated you only have one channel per trunk, leads me to question if you set number of channels to 1 in your trunks, in which case transfer will never use that channel even if it could, hence my suggestion to not provide answer. and see if the REFER goes right back out.
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#9
I did set max. channel to 1. I removed it, still the same.

I think the problem is the wrong channel was associated with the incoming route (trunk) when the channel is established, as it works if only one channel is active. And I can see the correct channel is used.
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#10
I removed trunk 111111 completely, but asterisk still accepts call from that account/trunk and it maps to account 222222. This leads me to think my registration has problem.

of course I did a reload and sip show peers only show 222222.

oh, just realize that I have call hunting on these lines.
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#11
Finally figure out what's going on. All trunks (accounts) are registered to local port 5060. This is where the provider communicates with my server. And asterisk got confused. Binding trunks to unique port should fix the problem.

Is there a way to bind a trunk to a sepcific local port? I have added port=5061 to peer details and it does not seem to wotk?

Can asterisk listen to multiple ports and what's the syntax in sip.conf?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#12
as you said, just add

port=5061

in your trunk sections,

The harder thing is to get the provider to change the signaling port some will, some won't.

good luck
 

itjumper

Joined
Jul 22, 2008
Messages
81
Likes
0
Points
0
#13
I have tried port 5061 and it did not work. But it works with an ATA like spa2102 with the 2nd line @ 5061. What's the difference?

How can I mimic an ata with asterisk?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#14
Your simple ATA has one ip address so to use two connections you have to use two different udp signaling ports to handle each one.

SIP signaling must be on the same port at both ends for each connection, or the session must be mediated by a decent proxy (not unfortunately Asterisk), or the connections will be co-mingled, the vendor should use different signaling ports on each trunk if they ONLY offer one channel per trunk to so differentiate (can you get a more usable number from them?) or you will have to kiss your provider goodbye if you want to use asterisk. (I note that they offer DID's in a few cities in Western Canada, their next market is apparently Shanghai)

I re-read you post, Do you have port=5061 in your user section of the trunk (that part which makes outbound calls) as well, if it works for your ATA it should work for Asterisk?
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,886
Members
17,563
Latest member
dineshr
Top