[Home]

Summary:ASTERISK-15803: On omitting the T flag from Dial() the caller can still make a blind transfer
Reporter:Zoltan Kovacs (kovzol)Labels:
Date Opened:2010-03-13 11:18:06.000-0600Date Closed:2010-03-31 12:54:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I use allowtransfer=yes in sip.conf. I think if I omit the T flag from Dial() in a dialplan extension, no blind transfer should be made by the caller. But the caller can still make a blind transfer if he presses the TRANSFER key.

A partial workaround is if I set allowtransfer=no in sip.conf, but this will disable the blind transfer initiated by the caller side as well (which is not what I would like to).
Comments:By: Leif Madsen (lmadsen) 2010-03-15 11:09:28

When you say he presses the "TRANSFER" key, I guess you're saying they are doing a transfer from the phone itself? I think the Tt flags only affect features.conf (DTMF) transfers, and not SIP transfers themselves.
By: Leif Madsen (lmadsen) 2010-03-15 11:12:52

Per IRC:

<file> T and t enable DTMF based transfers, they do not act as a policy enforcement on transfers initiated by other methods


So if that is your purpose in using the 'T' or 't' flags, then that is not the expected behaviour.
By: Zoltan Kovacs (kovzol) 2010-03-15 11:34:14

From the documentation I was unable to learn what is the expected behaviour. But anyhow, the following situation is present:

If someone installs Asterisk, allowtransfer=yes is the default. Now if someone calls an IVR or a fax number (which are usually always up and can answer the call) and as the IVR or the fax machine answers the call, and now the caller presses TRANSFER (DTMF) on his phone, he can make a call in the name of the callee, having the possibility to generate calls with duration of thousands of minutes within a few hours. I AM NOT SURE IF I CAN UNDERSTAND CLEARLY IF THIS IS A BUG IN ASTERISK. If yes, this is an extremely dangerous problem in general and all Asterisk users should be warned who use Asterisk in a cost sensible environment.
By: Zoltan Kovacs (kovzol) 2010-03-15 11:38:01

I also refer to this post:
http://forum.asterisk2billing.org/viewtopic.php?f=22&t=6977&start=0
By: Leif Madsen (lmadsen) 2010-03-15 14:42:50

Well I'll set this to Acknowledged for now so someone else can review this who knows this part of Asterisk better than I.
By: David Woolley (davidw) 2010-03-16 06:48:51

I think this is a feature request.

We would want the ability to do SIP transfers to be enable-able, even if DTMF transfers were not enabled, as the latter force retention of the RTP stream, and one reason for disabling them is to allow re-invites out.

Also "the caller presses TRANSFER (DTMF)", doesn't seem to make sense - if you use the actual phone TRANSFER button, the digits will not be sent as DTMF, even if the phone generates DTMF as confidence tones.  They will actually be sent in a SIP URL in a REFER message.

Formally, REFER needs to be accepted by the original other party, so adding a feature to reject REFER would not conflict with the SIP specification.  Note that this can be a preconfigured consultation with the user.

Note that, attended transfers will still get as far as the enquiry, as this is indistinguishable from a normal outgoing call, and that the phone may direct the REFER to either end, at its discretion.
By: Elazar Broad (ebroad) 2010-03-19 00:14:39

I did a simple test by calling my fax line from an outside line(cell phone), with only t(not T) being passed to Dial() when routing from my trunk to the inside extension and I was unable to transfer via the key combination in features.conf.

Edit: Could not transfer using the DTMF key combination without t or T being passed, and even with allowtransfer set to yes on the trunk itself.

Edit: SVN trunk, checkout within the past 72 hours

One more thing, what do you have promiscredir set to?


By: Zoltan Kovacs (kovzol) 2010-03-19 02:53:46

Here is my sip.conf (which causes problems):

[general]
allowtransfer=yes
context=default
allowguest=yes
bindport=5060
srvlookup=no
domain=this.is.my.service.com
realm=this.is.my.service.com
autodomain=yes
pedantic=yes
t38pt_udptl=no
disallow=all
allow=alaw
allow=ulaw
allow=gsm
language=en
useragent=MyUserAgentString
dtmfmode=auto
amaflags=billing
qualify=yes
canreinvite=no
defaultexpiry=600
maxexpiry=3660
rtptimeout=180
rtpholdtimeout=600
tos_sip=cs3
tos_audio=ef
externip=my.external.ip

[12345678] ;sample client config
type=friend
secret=hissecret
username=12345678
host=dynamic
disallow=all
allow=alaw
allow=ulaw
allow=gsm
call-limit=1
nat=yes
callerid=12345678

I guess promiscredir is set to "no" by default, so this is what my system assumes.
By: Elazar Broad (ebroad) 2010-03-19 10:26:03

That would be correct. Could you please clarify, the phone that is initiating the transfer, is it sending the key sequence specified in features.conf on YOUR system when the PHONE's transfer button is pressed, or is it performing a transfer via sip REFER?
By: Zoltan Kovacs (kovzol) 2010-03-29 06:26:35

I switched logging on in an Ekiga client and created a detailed log (using "ekiga -d 1000 2> ekiga.log") with both allowtransfer=no and allowtransfer=yes (on the server side).

I am logged in as 06212000005 and calling 0614450100. Now I double-click on my mobile number 06706226977 in Ekiga. In the first case transfer does not work, but in the second case it works (my mobile phone is ringing and I can answer the call and talk to 0614450100).

Here are my logs:
http://particio.com/ekiga-allowtransferno.log
http://particio.com/ekiga-allowtransferyes.log

However I'm not an expert in SIP protocol, the appropriate part seems to be the following:

------------------8X allowtransfer=no X8---------------------------
REFER sip:0614450100@82.150.61.51 SIP/2.0
Route: <sip:sip.ephone.hu:5060;lr>
Referred-By: <sip:06212000005@sip.ephone.hu>
CSeq: 4 REFER
Via: SIP/2.0/UDP 84.3.27.255:5100;branch=z9hG4bK10f71d2f-9139-df11-854f-0014851806e3;rport
User-Agent: Ekiga/3.2.5
From: "Kovács Zoltán" <sip:06212000005@sip.ephone.hu>;tag=d29bfa2c-9139-df11-854f-0014851806e3
Call-ID: 7ea9fa2c-9139-df11-854f-0014851806e3@nagy
To: <sip:0614450100@sip.ephone.hu>;tag=as29309888
Contact: <sip:kovzol@84.3.27.255:5100>
Proxy-Authorization: Digest username="06212000005", realm="sip.ephone.hu", nonce="7529d025", uri="sip:0614450100@82.150.61.51", algorithm=MD5, response="53afdbffd0b749f65308339a73590437"
Refer-To: <sip:06706226977@sip.ephone.hu>
Content-Length: 0
Max-Forwards: 70


2010/03/29 13:09:16.795   0:26.671                              OpalUDP Setting interface to 192.168.2.10%eth0
2010/03/29 13:09:16.795   0:26.671       Housekeeper:0xb73ffb70 PTLib   MONITOR:timers=7
2010/03/29 13:09:16.795   0:26.671                              SIP     Transaction timers set: retry=0.500, completion=6.000
2010/03/29 13:09:16.887   0:26.763      Opal Liste...0xb73beb70 OpalUDP Binding to interface: 84.3.27.255:5100
2010/03/29 13:09:16.887   0:26.763      Opal Liste...0xb73beb70 SIP     Waiting for PDU on udp$82.150.61.51:5060<if=udp$84.3.27.255:5100>
2010/03/29 13:09:16.888   0:26.764      Opal Liste...0xb73beb70 SIP     PDU received: rem=udp$82.150.61.51:5060,local=udp$84.3.27.255:5100,if=192.168.2.10%eth0
SIP/2.0 603 Declined (policy)
CSeq: 4 REFER
Via: SIP/2.0/UDP 84.3.27.255:5100;branch=z9hG4bK10f71d2f-9139-df11-854f-0014851806e3;received=84.3.27.255;rport=5100
User-Agent: Ephone2_Ast14
From: "Kovács Zoltán" <sip:06212000005@sip.ephone.hu>;tag=d29bfa2c-9139-df11-854f-0014851806e3
Call-ID: 7ea9fa2c-9139-df11-854f-0014851806e3@nagy
Supported: replaces
To: <sip:0614450100@sip.ephone.hu>;tag=as29309888
Contact: <sip:0614450100@82.150.61.51>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Content-Length: 0
------------------8X allowtransfer=no X8---------------------------

and

------------------8X allowtransfer=yes X8--------------------------
REFER sip:0614450100@82.150.61.51 SIP/2.0
Route: <sip:sip.ephone.hu:5060;lr>
Referred-By: <sip:06212000005@sip.ephone.hu>
CSeq: 4 REFER
Via: SIP/2.0/UDP 84.3.27.255:5100;branch=z9hG4bK88a6c4d8-9139-df11-9dc3-0014851806e3;rport
User-Agent: Ekiga/3.2.5
From: "Kovács Zoltán" <sip:06212000005@sip.ephone.hu>;tag=205e40d6-9139-df11-9dc3-0014851806e3
Call-ID: de6d40d6-9139-df11-9dc3-0014851806e3@nagy
To: <sip:0614450100@sip.ephone.hu>;tag=as2663a8c7
Contact: <sip:kovzol@84.3.27.255:5100>
Proxy-Authorization: Digest username="06212000005", realm="sip.ephone.hu", nonce="13bee3aa", uri="sip:0614450100@82.150.61.51", algorithm=MD5, response="13febababc644a91018d4e3a5b55df38"
Refer-To: <sip:06706226977@sip.ephone.hu>
Content-Length: 0
Max-Forwards: 70


2010/03/29 13:14:01.422   0:10.695                              OpalUDP Setting interface to 192.168.2.10%eth0
2010/03/29 13:14:01.423   0:10.695                              SIP     Transaction timers set: retry=0.500, completion=6.000
2010/03/29 13:14:01.425   0:10.697       Housekeeper:0xb7460b70 PTLib   MONITOR:timers=7
2010/03/29 13:14:01.634   0:10.906       Media Patch:0xb6440b70 RTP     Jitter buffer target realigned to current jitter buffer
2010/03/29 13:14:01.654   0:10.926       Media Patch:0xb6440b70 RTP     Jitter buffer target realigned to current jitter buffer
2010/03/29 13:14:01.698   0:10.970      Opal Liste...0xb72ffb70 OpalUDP Binding to interface: 84.3.27.255:5100
2010/03/29 13:14:01.698   0:10.970      Opal Liste...0xb72ffb70 SIP     Waiting for PDU on udp$82.150.61.51:5060<if=udp$84.3.27.255:5100>
2010/03/29 13:14:01.699   0:10.971      Opal Liste...0xb72ffb70 SIP     PDU received: rem=udp$82.150.61.51:5060,local=udp$84.3.27.255:5100,if=192.168.2.10%eth0
SIP/2.0 202 Accepted
CSeq: 4 REFER
Via: SIP/2.0/UDP 84.3.27.255:5100;branch=z9hG4bK88a6c4d8-9139-df11-9dc3-0014851806e3;received=84.3.27.255;rport=5100
User-Agent: Ephone2_Ast14
From: "Kovács Zoltán" <sip:06212000005@sip.ephone.hu>;tag=205e40d6-9139-df11-9dc3-0014851806e3
Call-ID: de6d40d6-9139-df11-9dc3-0014851806e3@nagy
Supported: replaces
To: <sip:0614450100@sip.ephone.hu>;tag=as2663a8c7
Contact: <sip:0614450100@82.150.61.51>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Content-Length: 0
------------------8X allowtransfer=yes X8--------------------------

Thank you in advance dealing with this issue.
By: Leif Madsen (lmadsen) 2010-03-31 12:32:29

That's working exactly as I would imagine it would.

If you want to disable the allowtransfer=yes globally, then you can enable allowtransfer=yes per user/peer in sip.conf. At least that's what the documentation says to me.
By: Digium Subversion (svnbot) 2010-03-31 12:42:59

Repository: asterisk
Revision: 255503

U   branches/1.4/apps/app_dial.c
U   branches/1.4/configs/sip.conf.sample

------------------------------------------------------------------------
r255503 | lmadsen | 2010-03-31 12:42:58 -0500 (Wed, 31 Mar 2010) | 5 lines

Add documentation clarifying when 't' and 'T' can be used.

(closes issue ASTERISK-15803)
Reported by: kovzol
Tested by: lmadsen, kovzol, davidw, ebroad
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=255503
By: Digium Subversion (svnbot) 2010-03-31 12:48:09

Repository: asterisk
Revision: 255504

_U  trunk/
U   trunk/apps/app_dial.c
U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r255504 | lmadsen | 2010-03-31 12:48:09 -0500 (Wed, 31 Mar 2010) | 5 lines

Add documentation clarifying when 't' and 'T' can be used.

(closes issue ASTERISK-15803)
Reported by: kovzol
Tested by: lmadsen, kovzol, davidw, ebroad
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=255504
By: Digium Subversion (svnbot) 2010-03-31 12:49:08

Repository: asterisk
Revision: 255505

U   branches/1.6.2/apps/app_dial.c
U   branches/1.6.2/configs/sip.conf.sample

------------------------------------------------------------------------
r255505 | lmadsen | 2010-03-31 12:49:08 -0500 (Wed, 31 Mar 2010) | 13 lines

Merged revisions 255504 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r255504 | lmadsen | 2010-03-31 12:48:09 -0500 (Wed, 31 Mar 2010) | 5 lines
 
 Add documentation clarifying when 't' and 'T' can be used.
 
 (closes issue ASTERISK-15803)
 Reported by: kovzol
 Tested by: lmadsen, kovzol, davidw, ebroad
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=255505
By: Digium Subversion (svnbot) 2010-03-31 12:51:40

Repository: asterisk
Revision: 255506

U   branches/1.6.1/apps/app_dial.c
U   branches/1.6.1/configs/sip.conf.sample

------------------------------------------------------------------------
r255506 | lmadsen | 2010-03-31 12:51:40 -0500 (Wed, 31 Mar 2010) | 13 lines

Merged revisions 255504 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r255504 | lmadsen | 2010-03-31 12:48:09 -0500 (Wed, 31 Mar 2010) | 5 lines
 
 Add documentation clarifying when 't' and 'T' can be used.
 
 (closes issue ASTERISK-15803)
 Reported by: kovzol
 Tested by: lmadsen, kovzol, davidw, ebroad
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=255506
By: Digium Subversion (svnbot) 2010-03-31 12:54:14

Repository: asterisk
Revision: 255507

U   branches/1.6.0/apps/app_dial.c
U   branches/1.6.0/configs/sip.conf.sample

------------------------------------------------------------------------
r255507 | lmadsen | 2010-03-31 12:54:13 -0500 (Wed, 31 Mar 2010) | 13 lines

Merged revisions 255504 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r255504 | lmadsen | 2010-03-31 12:48:09 -0500 (Wed, 31 Mar 2010) | 5 lines
 
 Add documentation clarifying when 't' and 'T' can be used.
 
 (closes issue ASTERISK-15803)
 Reported by: kovzol
 Tested by: lmadsen, kovzol, davidw, ebroad
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=255507