Transfer after Answer in dialplan

Asterisk Asterisk Support
1

Hi! i have the same problem, but in my case the provider is my Asterisk, and the other two nodes are other Asterisks mine too. If the provider Dial to node1, and node1 does a Transfer to node2, it works. But if node1 made an Answer before transfer, dont. All my ALLOWs has REFER. The no-Answer working:

2019/07/25 13:32:17.675746 170.251.79.80:5060 -> 170.251.79.62:5060
INVITE sip:333@170.251.79.62;user=phone SIP/2.0
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK60f36712
Max-Forwards: 70
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c3f58b1
To: <sip:333@170.251.79.62;user=phone>
Contact: <sip:trunk@170.251.79.80:5060>
Call-ID: 1282301e32d88d88364b82be0ae5a7f3@170.251.79.80:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.27.0
Date: Thu, 25 Jul 2019 09:32:21 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Type: application/sdp
Content-Length: 278

v=0
o=root 1681457391 1681457391 IN IP4 170.251.79.80
s=Asterisk PBX 13.27.0
c=IN IP4 170.251.79.80
t=0 0
m=audio 13302 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


2019/07/25 13:32:17.679261 170.251.79.62:5060 -> 170.251.79.80:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK60f36712;received=170.251.79.80
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c3f58b1
To: <sip:333@170.251.79.62;user=phone>
Call-ID: 1282301e32d88d88364b82be0ae5a7f3@170.251.79.80:5060
CSeq: 102 INVITE
Server: Asterisk PBX 16.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:333@170.251.79.62:5060>
Content-Length: 0



2019/07/25 13:32:17.681418 170.251.79.62:5060 -> 170.251.79.80:5060
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK60f36712;received=170.251.79.80
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c3f58b1
To: <sip:333@170.251.79.62;user=phone>;tag=as7a9834e8
Call-ID: 1282301e32d88d88364b82be0ae5a7f3@170.251.79.80:5060
CSeq: 102 INVITE
Server: Asterisk PBX 16.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: Transfer <sip:333@170.251.79.71>
Content-Length: 0



2019/07/25 13:32:17.681688 170.251.79.80:5060 -> 170.251.79.62:5060
ACK sip:333@170.251.79.62;user=phone SIP/2.0
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK60f36712
Max-Forwards: 70
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c3f58b1
To: <sip:333@170.251.79.62;user=phone>;tag=as7a9834e8
Contact: <sip:trunk@170.251.79.80:5060>
Call-ID: 1282301e32d88d88364b82be0ae5a7f3@170.251.79.80:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 13.27.0
Content-Length: 0

And now the Answer before transfer case:

2019/07/25 13:33:32.192259 170.251.79.80:5060 -> 170.251.79.62:5060
INVITE sip:333@170.251.79.62;user=phone SIP/2.0
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK20610a07
Max-Forwards: 70
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>
Contact: <sip:trunk@170.251.79.80:5060>
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.27.0
Date: Thu, 25 Jul 2019 09:33:36 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Type: application/sdp
Content-Length: 278

v=0
o=root 1528082092 1528082092 IN IP4 170.251.79.80
s=Asterisk PBX 13.27.0
c=IN IP4 170.251.79.80
t=0 0
m=audio 19562 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


2019/07/25 13:33:32.198060 170.251.79.62:5060 -> 170.251.79.80:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK20610a07;received=170.251.79.80
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 INVITE
Server: Asterisk PBX 16.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:333@170.251.79.62:5060>
Content-Length: 0



2019/07/25 13:33:32.200100 170.251.79.62:5060 -> 170.251.79.80:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK20610a07;received=170.251.79.80
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 INVITE
Server: Asterisk PBX 16.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:333@170.251.79.62:5060>
Content-Type: application/sdp
Content-Length: 277

v=0
o=root 1846220969 1846220969 IN IP4 170.251.79.62
s=Asterisk PBX 16.4.0
c=IN IP4 170.251.79.62
t=0 0
m=audio 12202 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


2019/07/25 13:33:32.200586 170.251.79.80:5060 -> 170.251.79.62:5060
ACK sip:333@170.251.79.62:5060 SIP/2.0
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK3bb26487
Max-Forwards: 70
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
Contact: <sip:trunk@170.251.79.80:5060>
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 13.27.0
Content-Length: 0



2019/07/25 13:33:32.216796 170.251.79.62:5060 -> 170.251.79.80:5060
REFER sip:trunk@170.251.79.80:5060 SIP/2.0
Via: SIP/2.0/UDP 170.251.79.62:5060;branch=z9hG4bK48c0c1ce
Max-Forwards: 70
From: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
To: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
Contact: <sip:333@170.251.79.62:5060>
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 REFER
User-Agent: Asterisk PBX 16.4.0
Date: Thu, 25 Jul 2019 11:33:32 GMT
Refer-To: <sip:333@170.251.79.71>
Referred-By: <sip:333@170.251.79.62:5060>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0



2019/07/25 13:33:32.217272 170.251.79.80:5060 -> 170.251.79.62:5060
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 170.251.79.62:5060;branch=z9hG4bK48c0c1ce;received=170.251.79.62
From: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
To: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 102 REFER
Server: Asterisk PBX 13.27.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:trunk@170.251.79.80:5060>
Content-Length: 0



2019/07/25 13:33:32.217569 170.251.79.80:5060 -> 170.251.79.62:5060
NOTIFY sip:333@170.251.79.62:5060 SIP/2.0
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK280b379b
Max-Forwards: 70
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
Contact: <sip:trunk@170.251.79.80:5060>
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 103 NOTIFY
User-Agent: Asterisk PBX 13.27.0
Event: refer;id=102
Subscription-state: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 16

SIP/2.0 200 OK


2019/07/25 13:33:32.217666 170.251.79.62:5060 -> 170.251.79.80:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 170.251.79.80:5060;branch=z9hG4bK280b379b;received=170.251.79.80
From: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
To: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 103 NOTIFY
Server: Asterisk PBX 16.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:333@170.251.79.62:5060>
Content-Length: 0



2019/07/25 13:33:32.218418 170.251.79.62:5060 -> 170.251.79.80:5060
BYE sip:trunk@170.251.79.80:5060 SIP/2.0
Via: SIP/2.0/UDP 170.251.79.62:5060;branch=z9hG4bK0eb63fad
Max-Forwards: 70
From: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
To: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 103 BYE
User-Agent: Asterisk PBX 16.4.0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0



2019/07/25 13:33:32.218629 170.251.79.80:5060 -> 170.251.79.62:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 170.251.79.62:5060;branch=z9hG4bK0eb63fad;received=170.251.79.62
From: <sip:333@170.251.79.62;user=phone>;tag=as751870eb
To: "trunk" <sip:trunk@170.251.79.80>;tag=as6c034cb0
Call-ID: 7e0ae4cc2f8d7c7878e66223756e4f0a@170.251.79.80:5060
CSeq: 103 BYE
Server: Asterisk PBX 13.27.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

How can i fix it?

2

What doesn’t work? What happens? What is the actual console output on the side receiving the REFER?

3

The extension registered at provider, has trunk as name.
CLI at provider:

       > 0x7f6f90032610 -- Strict RTP learning after remote address set to: 127.0.0.1:5127
    -- Executing [333@delacalle:1] Answer("SIP/trunk-00000044", "")
       > 0x7f6f90032610 -- Strict RTP switching to RTP target address 127.0.0.1:5127 as source
    -- Executing [333@delacalle:1] noop("SIP/trunk-00000044", "saliendo por nodo 1")
    -- Executing [333@delacalle:1] Dial("SIP/trunk-00000044", "SIP/trunk-nodo1/333")
    -- Called SIP/trunk-nodo1/333
       > 0x7f6f4001a180 -- Strict RTP learning after remote address set to: 170.251.79.62:11512
    -- SIP/trunk-nodo1-00000045 answered SIP/trunk-00000044
    -- Channel SIP/trunk-nodo1-00000045 joined 'simple_bridge' basic-bridge <9fc2bcde-d4ea-43b8-9570-175532eab3de>
    -- Channel SIP/trunk-00000044 joined 'simple_bridge' basic-bridge <9fc2bcde-d4ea-43b8-9570-175532eab3de>
       > Bridge 9fc2bcde-d4ea-43b8-9570-175532eab3de: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'SIP/trunk-00000044' and 'SIP/trunk-nodo1-00000045' in stack
       > Locally RTP bridged 'SIP/trunk-00000044' and 'SIP/trunk-nodo1-00000045' in stack
    -- Channel SIP/trunk-nodo1-00000045 left 'native_rtp' basic-bridge <9fc2bcde-d4ea-43b8-9570-175532eab3de>
       > Bridge 9fc2bcde-d4ea-43b8-9570-175532eab3de: switching from native_rtp technology to simple_bridge
    -- Channel SIP/trunk-00000044 left 'simple_bridge' basic-bridge <9fc2bcde-d4ea-43b8-9570-175532eab3de>
    -- Executing [333@delacalle:1] Hangup("SIP/trunk-00000044", "")
  == Spawn extension (delacalle, 333, 1) exited non-zero on 'SIP/trunk-00000044'
    -- Executing [333@delacalle:1] Answer("SIP/trunk-00000044", "")
  == Spawn extension (delacalle, 333, 1) exited non-zero on 'SIP/trunk-00000044'

CLI at nodo1:

       > 0x7f5ca4033ba0 -- Strict RTP learning after remote address set to: 170.251.79.80:19800
    -- Executing [333@from_trunk_coco:1] Answer("SIP/trunk-coco-00000033", "")
       > 0x7f5ca4033ba0 -- Strict RTP switching to RTP target address 170.251.79.80:19800 as source
    -- Executing [333@from_trunk_coco:1] Transfer("SIP/trunk-coco-00000033", "SIP/333@170.251.79.71")
    -- Executing [333@from_trunk_coco:1] Hangup("SIP/trunk-coco-00000033", "")
  == Spawn extension (from_trunk_coco, 333, 1) exited non-zero on 'SIP/trunk-coco-00000033'

And nothing at nodo2 (170.251.79.71)

4

Do you have promiscuous redirects enabled. They only work for 302. If you want to take account of the domain for REFER, you have to do that explicitly,.

5

… how can i do it? I mean, where is that configuration?

6

As I recall, the domain is set in a channel variable. You would need to check it early in extension processing re-interpret the extension accordingly.

7

sorry i don’t understand what do you mean. My dialplans are really smalls, at provider:

extensions => _X.,1,Answer
same => n,Dial(SIP/trunk-nodo1/${EXTEN})
same => n,Hangup()

And at nodo1:

extensions => _X.,1,Transfer(SIP/${EXTEN}@170.251.79.62)

Or

extensions => _X.,1,Answer()
same => n,Transfer(SIP/${EXTEN}@170.251.79.62)
8

That will create a loop.

Node 1 will issue a transfer to the extension number, and node 0 will tandem connect to the same extension on node 1, which will issue a transfer…

Assuming 170.251.79.62 is a different machine, node 0 would need to compare the target domain with that, and, instead of passing the call forward to node 1, Dial ${EXTEN}@170.251.79.62.

I’d suggest that doing refers to non-local extensions is exceedingly rare.

9

ok, that’s not really my dialplan, at provider:

exten => _X.,1,Answer()
same => n,Set(nodo=${DB(nodo/outbound)})
same => n,ExecIf($[ "${DB(nodo/outbound)}" = "2" ]?Set(DB(nodo/outbound)=1):Set(DB(nodo/outbound)=1))
same => n,Dial(SIP/trunk-nodo${nodo}/${EXTEN})
same => n,Hangup()

The peer ‘trunk’ dials 333 at provider, the call is placed to nodo1 … transfer … and provider finaly placed it to nodo2.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.