[asterisk-bugs] [Asterisk 0014410]: One audio stream not working after transfer

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14410 
====================================================================== 
Reported By:                Drasha
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   14410
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.21.2 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-02-05 03:41 CST
Last Modified:              2009-05-19 14:36 CDT
====================================================================== 
Summary:                    One audio stream not working after transfer
Description: 
Copy of mail from asterisk-dev list:

Hello,
I have encountered problem with REFER handling when using Asterisk. I will
try
to give as much information as possible so this is going to be a bit
lengthy
mail...

In my setup I have:
3 VoIP phones with numbers 3063, 3082 and 7777
1 custom telephony application that I will refer to as OptimTalk from now
on.
(I keep this names so that they are the same as the names in SIP
messages)

Scenario:
1) OptimTalk creates a call to number 3063 (all calls go through
Asterisk)
2) OptimTalk creates a call to number 3082
3) OptimTalk internally bridges RTP streams from these calls so that
numbers
   3063 and 3082 can talk together
4) Number 3063 transfers the call to 7777
5) 3082 and 7777 should talk together while the streams still flow
through
   OptimTalk

Problem occurs in point 5) because number 7777 can hear 3082 but not vice
versa.

Details:
I have attached captured SIP messages as they were caught by tshark on
the
machine that Asterisk is running on. Each message is in separate file
labeled
NUMBER_FROM_TO_MESSAGE_TARGET.txt
Not all the SIP messages are here - only the relevant ones.

Ad 1) [files 01_... - 04_...]
Two INVITEs are sent, creating two calls
- between OptimTalk and Asterisk
(Call-Id:3d0c17a0-6bb5-122c-2780 at 192.168.32.55)
- between Asterisk and 3063
(Call-Id:201d66817a4b0265062a611560fbdf99 at vutbr.cz)

Ad 2) [files 05_... - 08_...]
Two INVITEs are sent, creating two calls
- between OptimTalk and Asterisk
(Call-Id:3f949740-6bb5-122c-2780 at 192.168.32.55)
- between Asterisk and 3082
(Call-Id:30b6b781732060ad7bad01646556630b at vutbr.cz)

Ad 4) [rest of files]
3063 creates call to 7777 - again two invites and two calls
- between 3063 and Asterisk
                       
(Call-Id:cf13916b9c856f11a0d52fa4848ff1c2 at 192.168.32.84)
- between Asterisk and 7777
(Call-Id:56e79bf513b8244b5cbda2e90cdded1a at vutbr.cz)

3063 sends reINVITE to 7777, changing SDP audio attribute from a=sendrecv
to
a=sendonly. Call with id cf13916b9c856f11a0d52fa4848ff1c2 at 192.168.32.84
is
updated.

3063 sends REFER to Asterisk. Call-Id in Refer-To header is
cf13916b9c856f11a0d52fa4848ff1c2%40192.168.32.84 (call between 3063 and
Asterisk
in point 4). To-tag and from-tag are tags of OptimTalk and 3063
respectively.
Asterisk responds with 202 ACCEPTED (msg. 16) and then sends NOTIFY (msg.
17)

Then there is BYE between Asterisk and 3063 - messages are not included.

********************************************************************************

To me it looks normal, but there must be some problem. I would be very
grateful
if you could help me tracking down this issue.

Btw. scenario without OptimTalk is working well, but as OptimTalk does
not
receive any SIP messages after the first two INVITEs and before the last
BYEs so
I think it is not a problem of its code.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-19 14:36 file           Status                   resolved => closed  
======================================================================