Summary:	ASTERISK-25268: Neither a src change or marker after (attended) transfer
Reporter:	dtryba (dtryba)	Labels:
Date Opened:	2015-07-20 11:45:54	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Channels/chan_sip/Transfers
Versions:	11.13.1 13.18.4	Frequency of Occurrence	Frequent
Related Issues:	is related to ASTERISK-23142 Large timestamp skew in RTP stream during blind transfer
Environment:	Debian/jessie	Attachments:	( 0) channel.c.diff ( 1) extensions.conf ( 2) patched.pcapng.gz ( 3) sip.conf ( 4) timestamp.pcapng.gz ( 5) transfer.log ( 6) unpatched.pcapng.gz
Description:	On completing an attended transfer the original caller doesn't hear the transferee. Up until completion every party had a bidirectional audio. This is an almost duplicate of ASTERISK-15790 except here the problem is on the A leg instead of the C leg. The cause is exactly the same: a huge jump in the timestamp (going backwards) without either a change of srccid or marker in rtp. This behavior is similar to ASTERISK-23142, which occasionally happens without using the asterisk transfer feature (using SIP UA functions instead). The Vodafone Ericsson upstream refuses to forward RTP to the endpoints (apparently with reason). Frequently happens with Asterisk 11.13.1~dfsg-2, the changes to channel.c are minimal (and non related) in the latest 11 LTS compared to 11.13.
Comments:	By: Asterisk Team (asteriskteam) 2015-07-20 11:45:55.537-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: dtryba (dtryba) 2015-07-20 11:49:58.031-0500 ssrc 0x63b3f3bf (towards A) if fine until packet 6102 there the timestamp goes backwards. By: Rusty Newton (rnewton) 2015-07-22 19:20:42.995-0500 Can you provide an example of the dialplan and sip.conf configuration you use to reproduce the issue? By: dtryba (dtryba) 2015-07-23 07:06:22.457-0500 The requested configs and a debug log of the call/transfer. Lots of magic is happening in AGI scripts, the results are stored in variables used in extensions. There are no SIP users, incoming calls are handled with AGI to determine authorization of the source, calls to other PBXs are made with the SIP/username[:password[:md5secret[:authname[:transport]]]]@host[:port] scheme. By: dtryba (dtryba) 2015-07-23 07:16:10.771-0500 I have been fooling around with channel.c to see if I could set a marker on the A leg. Looking at set_format I'm really wondering why there is no marker being set (ast_indicate(chan, AST_CONTROL_SRCUPDATE)) if there is a need to change the format? Adding the marker here results in the A leg being marked, I haven't been able to push this build to the production platform to see if this solved my problem. If the use of the marker is interpreted as http://www.cs.columbia.edu/~hgs/rtp/faq.html#marker mentions, it should solve the problem. By: Rusty Newton (rnewton) 2015-07-24 12:50:58.866-0500 Are you able to reproduce the issue with a simple manual attended transfer (looks like you are using a feature code transfer?) without involving AGI and other complexity? The more simple we can make this the easier. By: Rusty Newton (rnewton) 2015-07-24 16:48:51.375-0500 This does seem related to ASTERISK-23142. I'm going to link the two. By: Rusty Newton (rnewton) 2015-07-24 16:51:21.111-0500 Do you want to attach your patch in case someone else comes along with the issue that can test it out? By: dtryba (dtryba) 2015-07-27 06:26:37.898-0500 I tested my patch but it has no effect. The Ericcson needs a change of SSRC to pass the RTP with timestamps in the past. During testing the C to B RTP leg goes back in time with a marker, this isn't played back to B, after transfer is complete C to A gets a new SSRC and there is a full audio path both ways. I'll have to splice in a test setup for easier debugging/patches. By: dtryba (dtryba) 2015-07-28 07:41:40.005-0500 A diff againt asterisk 11-current (11.18.0). The indicate in set_format is needed for a change of SSRC to the A leg (from C) after completion of transfer. The indicate in ast_do_masquerade is needed to change SSRC to B (from C) during the attended transfer. Tested with a patched Debian/jessie build (1:11.13.1~dfsg-2). None of the test calls fail with the patch where unpatched fails (ts going backwards) In the latest git checkout of Asterisk channel.c is quite different. Will try to test current and patch if needed. By: dtryba (dtryba) 2015-07-28 08:36:31.785-0500 Simplified sip/extensions.conf By: dtryba (dtryba) 2015-07-28 09:16:21.720-0500 patched.pcapng.gz with patch applied. Packet 3309 has a new SSRC compared to previous packer 3297, seq_id is +1 and time went backwards. The audio is send to the transfering handset. unpatched is wihtout patch. Packet 3419 has a mark put SSRC is unchanged. Audio isn't send to transferring handset. When completing the transfer C to A SSRC is reset and C leg is send to A. Both cases have problems in the C->B leg, unlike the initial report where the problem exists on C to A leg!