[asterisk-bugs] [JIRA] (ASTERISK-22063) Ringback tone is not heard by caller when the call is transferred using semi-attended transfer

Sun Jul 28 18:31:03 CDT 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207918#comment-207918 ] 

Christine Alejandro edited comment on ASTERISK-22063 at 7/28/13 6:29 PM:
-------------------------------------------------------------------------

1. The channel technology of the participants
SIP

2. How the various channels are bridged
bridge_simple

3. Channel driver configuration files, as well as a sample dialplan that reproduces the problem
see attached file

    -- Executing [2066 at MOBILE:1] Dial("SIP/7950-00092c75", "SIP/2066,30") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/2066
    -- SIP/2066-00092c76 is ringing
    -- SIP/2066-00092c76 answered SIP/7950-00092c75
    -- Remotely bridging SIP/7950-00092c75 and SIP/2066-00092c76
  == Using SIP RTP CoS mark 5
    -- Started music on hold, class 'default', on SIP/7950-00092c75
    -- SIP/3656-00092c78 answered SIP/4616-00092c77
  == Using SIP RTP CoS mark 5
    -- Executing [2026 at PUD:1] Dial("SIP/2066-00092c79", "SIP/2026,30") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/2026
    -- SIP/2026-00092c7a is ringing
    -- Stopped music on hold on SIP/7950-00092c75
    -- Executing [h at MOBILE:1] Congestion("SIP/2066-00092c79<ZOMBIE>", "5") in new stack
  == Spawn extension (MOBILE, h, 1) exited non-zero on 'SIP/2066-00092c79<ZOMBIE>'
  == Spawn extension (MOBILE, 2066, 1) exited non-zero on 'SIP/2066-00092c79<ZOMBIE>'
  == Spawn extension (PUD, 2026, 1) exited non-zero on 'SIP/7950-00092c75'
    -- Executing [h at PUD:1] Congestion("SIP/7950-00092c75", "5") in new stack
  == Spawn extension (PUD, h, 1) exited non-zero on 'SIP/7950-00092c75'

      was (Author: clalejandro):
    1. The channel technology of the participants
SIP

2. How the various channels are bridged
bridge_simple

3. Channel driver configuration files, as well as a sample dialplan that reproduces the problem

[general]
transport=udp
context=default
allowguest=no
allowoverlap=no
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
srvlookup=yes
rtptimeout=60
rtpholdtimeout=300
t38pt_udptl=no
callcounter=yes
[authentication]

[7950]
username=7950
type=friend
defaultip=192.168.5.10
host=dynamic
md5secret=
port=5060
context=PUD
callgroup=63
pickupgroup=63
context=MOBILE

[2066]
username=2066
type=friend
defaultip=192.168.5.25
host=dynamic
md5secret=
port=5060
context=PUD
callgroup=
pickupgroup=
context=PUD

[2026]
username=2026
type=friend
defaultip=192.168.5.19
host=dynamic
md5secret=
port=5078
context=PUD
callgroup=
pickupgroup=
context=MOBILE

  exten => _8[567]XX,1,Dial(SIP/${EXTEN},30)
  exten => _[2-7]XXX,1,Dial(SIP/${EXTEN},30)

    -- Executing [2066 at MOBILE:1] Dial("SIP/7950-00092c75", "SIP/2066,30") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/2066
    -- SIP/2066-00092c76 is ringing
    -- SIP/2066-00092c76 answered SIP/7950-00092c75
    -- Remotely bridging SIP/7950-00092c75 and SIP/2066-00092c76
  == Using SIP RTP CoS mark 5
    -- Started music on hold, class 'default', on SIP/7950-00092c75
    -- SIP/3656-00092c78 answered SIP/4616-00092c77
  == Using SIP RTP CoS mark 5
    -- Executing [2026 at PUD:1] Dial("SIP/2066-00092c79", "SIP/2026,30") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/2026
    -- SIP/2026-00092c7a is ringing
    -- Stopped music on hold on SIP/7950-00092c75
    -- Executing [h at MOBILE:1] Congestion("SIP/2066-00092c79<ZOMBIE>", "5") in new stack
  == Spawn extension (MOBILE, h, 1) exited non-zero on 'SIP/2066-00092c79<ZOMBIE>'
  == Spawn extension (MOBILE, 2066, 1) exited non-zero on 'SIP/2066-00092c79<ZOMBIE>'
  == Spawn extension (PUD, 2026, 1) exited non-zero on 'SIP/7950-00092c75'
    -- Executing [h at PUD:1] Congestion("SIP/7950-00092c75", "5") in new stack
  == Spawn extension (PUD, h, 1) exited non-zero on 'SIP/7950-00092c75'

> Ringback tone is not heard by caller when the call is transferred using semi-attended transfer
> ----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22063
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22063
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 11.3.0
>         Environment: Ubuntu
>            Reporter: Christine Alejandro
>            Assignee: Christine Alejandro
>            Severity: Minor
>         Attachments: config-file.txt
>
>
> Normal scenario: Caller A calls B. B will transfer A's call to C (semi-attended transfer). B will check first if C's phone is ringing before transferring the call. Caller A hears a ringback tone when B transferred the call to C.
> Scenario encountered: Caller A calls B. B will transfer A's call to C (semi-attended transfer). B will check first if C's phone is ringing before transferring the call. Caller A doesn't hear a ringback tone when B transferred the call to C.
> It is a hit or miss case. Sometimes caller A could hear a ringback tone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira