Summary:	ASTERISK-14493: Getting one way audio after blind transfer from a SIP trunk call.
Reporter:	olivier1010 (olivier1010)	Labels:
Date Opened:	2009-07-20 05:03:28	Date Closed:	2011-06-07 14:00:28
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Quite often when calling with a SIP trunk to outside, we loose outgoing audio. But we can still hear audio from called party. We are using G711 alaw for the outgoing SIP trunk. This appeared with a recent asterisk update to version 1.4.25.1 This is an Elastix 1.5.2 distribution, and the machine is a pentium 4 monocore. This does not occur with internal calls. ****** ADDITIONAL INFORMATION ****** We are using the devicestate function, but this seems to occur as well without this module.
Comments:	By: Alec Davis (alecdavis) 2009-07-20 16:11:54 Is this in a purely SIP environment, or are ISDN primary rates involved? More detail would help? By: olivier1010 (olivier1010) 2009-07-20 19:37:45 This is in pure SIP environnement. We have an ISDN gateway connected to this server but through an Ethernet SIP trunk. Anyway, the calls where we are experiencing problems do not go through this gateway. It seems that there is more chance to have one way audio if the calling party stay more than about 30 seconds in music on hold state. If the transfer is done fastly, there is less chance to get one way audio. It is difficult to track down this problem as we do not see specific error reporting in the logs. I will try to investigate more, but i think that it was important at first to alert the developpers about this. If it is really an asterisk problem, other reports should follow. By: olivier1010 (olivier1010) 2009-07-21 14:48:47 After some deep investigations, we have found that we have adding a new SIP trunk to the system a few days ago who needed a different defaultexpirey value of 1800. (for a provider that is refusing lower than this value). Because of this new defaultexpirey, other SIP trunks were loosing registration. According to the documentation, it is not possible to specify a different defaultexpirey for each user / peer. We solved the problem using static SIP trunks. We need to wait a few days to be sure that the problem is solved. A defaultexpirey by user / peer should be implemented to avoid those problems. By: Jeff Phelps (blargman) 2009-07-24 12:24:29 olivier1010: can I see your sip.conf?? I'm curious to see how you have your trunks setup... before and after you figured out what was causing your issue... By: olivier1010 (olivier1010) 2009-08-07 13:20:34 I confirm that my defaultexpirey=1800 is the reason of my problem. I have trunks that need defaultexpirey=1800 and other trunks defaultexpirey=120. I tried to put defaultexpirey in each trunk but this does not work. Only the general setting does work. Is it possible to specify the defaultexpirey value for each trunks ? By: Leif Madsen (lmadsen) 2009-09-17 15:41:07 Closing this issue as it appears to be a configuration/interop issue with a specific provider. I don't believe it is possible to set different defaultexpiry's for individual peers.