Summary:	ASTERISK-04792: sip reload breaks dtmf via rfc2833
Reporter:	Joe Antkowiak (antkojm1)	Labels:
Date Opened:	2005-08-07 20:28:58	Date Closed:	2011-06-07 14:10:30
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Whenever we do a sip reload, rfc2833 from our cisco sip gateways breaks.  requires asterisk restart.  sip debug shows dtmf still being sent to * from the gateways.  let me know if you want a copy of the debug, or whatever else you need.
Comments:	By: Russell Bryant (russell) 2005-08-07 20:31:16 sip.conf, please By: Joe Antkowiak (antkojm1) 2005-08-07 20:38:56 [general] context=default allowguest=no realm=jsci.net bindport=5060 bindaddr=72.1.157.37 srvlookup=no tos=184       disallow=all allow=g726 allow=speex allow=ilbc allow=gsm allow=ulaw language=en relaxdtmf=no rtptimeout=300 rtpholdtimeout=500 progressinband=always dtmfmode=rfc2833 regcontext=sipregistrations nat=yes         rtcachefriends=yes rtnoupdate=yes rtautoclear=yes [bwi1-cgw1] type=peer host=72.1.157.34 disallow=all allow=ulaw insecure=very permit=72.1.157.34/255.255.255.255 auth=none dtmfmode=rfc2833 qualify=yes canreinvite=no context=didswitching nat=no [bwi1-cgw2] type=peer host=72.1.157.35 disallow=all allow=ulaw insecure=very permit=72.1.157.35/255.255.255.255 auth=none dtmfmode=rfc2833 qualify=yes canreinvite=no context=didswitching nat=no By: Mark Spencer (markster) 2005-08-07 20:57:18 Does it break only for new calls or even for calls that are active at the time of reload? By: Joe Antkowiak (antkojm1) 2005-08-07 22:11:27 only new calls.  I also just figured out that in addition to the reload, there has to be a config change to the peer affected for it to happen.  a simple reload doesn't seem to reproduce it. By: Mark Spencer (markster) 2005-08-07 22:20:14 Okay, do you want to be more specific about what change is required to the peer definition to cause this issue then? By: Joe Antkowiak (antkojm1) 2005-08-08 00:06:30 auth, host, context, and codec changes so far break it.  insecure and permit/deny don't seem to. By: Mark Spencer (markster) 2005-08-08 02:36:12 Can you provide an example before/after config that breaks one? By: Joe Antkowiak (antkojm1) 2005-08-09 12:25:13 before: [bwi1-cgw2] type=peer host=72.1.157.35 disallow=all allow=ulaw insecure=very permit=72.1.157.35/255.255.255.255 auth=none dtmfmode=rfc2833 qualify=yes canreinvite=no context=switching nat=no after: [bwi1-cgw2] type=peer host=72.1.157.35 disallow=all allow=ulaw insecure=very permit=72.1.157.35/255.255.255.255 auth=none dtmfmode=rfc2833 qualify=yes canreinvite=no context=didswitching nat=no By: Mark Spencer (markster) 2005-08-09 12:42:06 So to clarify, you're saying that by changing the context within a peer (and making no other changes whatsoever, not moving the peer to a different place within the config file or anything) you're able to make rfc2833 fail to receive properly on a reload? By: Joe Antkowiak (antkojm1) 2005-08-11 12:53:08 Yes, that is correct. By: Olle Johansson (oej) 2005-08-11 13:16:10 Please do a "sip show peer" on one peer before and after By: Michael Jerris (mikej) 2005-08-18 07:11:57 unfortunately, we can not continue troublshooting this bug without your assistance.  I am going to suspend this bug for now, please re-open when you are able to provide the requested information.