[Home]

Summary:ASTERISK-19919: Incorrect a=inactive when call changes from SIP_PAGE2_CALL_ONHOLD_INACTIVE to SIP_PAGE2_CALL_ONHOLD_ONEDIR
Reporter:Morten Tryfoss (mtryfoss)Labels:
Date Opened:2012-05-29 06:06:34Date Closed:2012-06-06 11:11:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.12.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) holdstates.diff
( 1) siptrace-19919.txt
Description:Asterisk replies with a=inactive when SIP_PAGE2_CALL_ONHOLD_INACTIVE has been set. This is not cleared when it receives a new re-INVITE with a=sendonly.

A simple fix is to clear all of those flags before setting them. Not sure if it's the best way to do it.
Comments:By: Morten Tryfoss (mtryfoss) 2012-05-29 06:07:16.726-0500

Patch uploaded.
By: David Woolley (davidw) 2012-05-30 05:26:47.064-0500

I'm not going to analyse this in detail as we did major rework in this area, but on a system frozen out at 1.6.1.0, so we are probably not going to have time to do the forward ports needed to submit it.

However, you should check the handling of late offer SDP.  In particular, in the versions on which we worked, there was a fairly deeply rooted invalid assumption that INVITE with SDP means cancel all holds, whereas it actually means "tell me what state you want before I'll tell you (the combination of what you want and) what I want.
By: Morten Tryfoss (mtryfoss) 2012-05-30 05:43:05.502-0500

I'm not that into coding on Asterisk, but I found this when connecting it with Lync 2010. It happens when doing a call park (transfer to parking lot). It then first re-invites with a=inactive and soon after with a=sendonly (to play musiconhold for the caller). A simple hold/unhold works correctly without the patch.

It works for me so I just thought it would be nice to submit a bug and this simple patch.
By: Rusty Newton (rnewton) 2012-06-03 21:16:06.341-0500

We'll need a SIP packet trace demonstrating the issue to make this easier to move forward. Please include all data from the beginning to the end of the call.
By: Morten Tryfoss (mtryfoss) 2012-06-04 02:04:11.761-0500

Please see attached sip trace. The call is first re-INVITEV with a=inactive and then with a=sendonly. After the last one Asterisk still sends 200 OK with a=inactive.