Summary:	ASTERISK-08173: Hints no longer work in 1.4beta3
Reporter:	Anthony Rodgers (cunningpike)	Labels:
Date Opened:	2006-11-22 12:01:08.000-0600	Date Closed:	2011-06-07 14:08:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.c ( 1) chan_sip.c.rej ( 2) debug ( 3) patch_sip_11.txt ( 4) sip-debug
Description:	Hints do not appear to be working in 1.4beta3. We upgraded our 1.2 test server with working hints on Polycom phones and hints no longer work. 'sip debug' shows no NOTIFY messages being passed as calls progress, and the output of 'show hints' doesn't change from Idle to anything else. ****** ADDITIONAL INFORMATION ****** May be related to ASTERISK-7238 Polycom SIP version is 1.6.6 and the phones are configured correctly - our observation is that the output of 'sip hints' is not changing with call progress and no NOTIFY messages are being generated. 'Watchers' increments and decrements as phones activate and de-activate watched buddies, and creating an entry on the phone for a non-existant hint generates the expected WARNING in the CLI.
Comments:	By: Anthony Rodgers (cunningpike) 2006-11-22 12:41:55.000-0600 Added debug of call (core debug 9) By: Anthony Rodgers (cunningpike) 2006-11-22 12:56:39.000-0600 Added sip-debug of call also By: Anthony Rodgers (cunningpike) 2006-11-22 13:47:27.000-0600 Using type=peer and call-limit=1 in sip.conf restores working hints - although 'Busy' in 'show hints' shows as 4 (Invalid) in a 'core debug' and shows up as 'Offline' on the phone. By: Olle Johansson (oej) 2006-11-25 03:41:08.000-0600 You need a call limit to get detailed notification. otherwise you will only see registration status. By: Anthony Rodgers (cunningpike) 2006-11-27 21:23:15.000-0600 That may be the case now, but was not the case under 1.2. In 1.2, hints worked just fine without call-limit. In any case, using call-limit and type=peer in 1.4 still generates a status of 4-Invalid when the peer is on a call instead of the expected 'InUse' - this makes a Polycom phone display 'Offline' for a watched buddy that is on a call. By: Steve Murphy (murf) 2006-11-27 22:45:24.000-0600 CunningPike-- Good, then the fix for 7433 may just fix the busy call status problem, too. My branch for 7433 didn't require that call_limit be set to anything. But, you do have to set limitpeersonly=yes in the [general] section of the sip.conf file. OEJ will modify this branch to work to his requirements, which will require call_limit to be set; but until it's committed to 1.4 and trunk, you can see if it will fill your needs. We moved it to asterisk/team/group/bug7433; and I updated it against 1.4, so it should be pretty close to what's currently available. Please, see if this branch gives you better behavior. If not, please report the precise problem. By: Anthony Rodgers (cunningpike) 2006-11-28 16:39:46.000-0600 Hunk 6 was failing when I attempted to patch the chan_sip.c from 1.4beta3 - I have attached the original chan_sip.c, the patch and the .rej file in the hopes that someone can tell me what changes need to be made. Also, it sounds from the previous note that, even when oej takes the 7433 branch into 1.4, call-limit will still be required to make hints work. If so, why is this? It's very (pardon the pun) limiting to have to disable call waiting to get BLF to work properly. By: Steve Murphy (murf) 2006-11-29 12:11:42.000-0600 The rejected hunk was just to insert a comment in the code-- no importance. Ignore it and test. Many thanks! By: Steve Murphy (murf) 2006-11-29 12:17:33.000-0600 As to call limits, this particular patch won't have them, but as described, you do have to set one var in the [general] section to make things work. And nothing's set in concrete yet. oej points out that unless such devicestate is absolutely necessary, tracking it should be disabled, especially if you use realtime. He has a point. I think the major point of contention is just how to enable/disable the devicestate tracking. I'd tend to think that any method will be OK, as long as it's documented. More to come. See how this code works for you. By: Ronald Chan (loloski) 2006-11-29 12:38:14.000-0600 murf: I hope this bug issue will also lead it's way to fix 7433 :) since most call center here and everywhere really need a working devicestate. If you need a help in anyway here and 7433 just ask :) By: Anthony Rodgers (cunningpike) 2006-11-29 13:44:42.000-0600 OK - having chatted with oej, type=peer and call-limit=n where n>0 (we have it set to 200) restores working hints at least as well as we had them under 1.2, and preserves call waiting. Interestingly, we now get the proper codes, too...... no idea why that started working this time. Blame the operator :-) This is _without_ the 7433 patch (sorry murf!). Now the only problem is getting our Polycoms to register two different peers at the same time........ :-( Remind me why did this all change, again? It was working great in 1.2....... By: Anthony Rodgers (cunningpike) 2006-11-29 13:53:06.000-0600 Using insecure=peer gets around the multiple peer issue with Polycoms By: Anthony Rodgers (cunningpike) 2006-11-29 14:14:10.000-0600 But doesn't fix the wrong callerid being sent...... By: Steve Murphy (murf) 2006-11-29 14:25:36.000-0600 Excellent. Looks like we were wrong about this one being related to 7433, sort of! I don't mind a bit, it's always nice to have a fix without changing the code. I think the changes in the devicestate handling were made necessary by the demands of realtime; cutting devicestate tracking was done to lessen the weight of sip on realtime users. oej can tell you more. By: Steve Murphy (murf) 2006-11-29 14:27:14.000-0600 If a solution exists, then it's time to close this one out. If you have a problem with the callerid, it sounds like something that should belong in a different bug report. By: Anthony Rodgers (cunningpike) 2006-11-29 17:38:55.000-0600 OK - we're almost there, but there is one remaining scenario that doesn't work. If you have a Polycom phone with more than one registration, you have to create a peer and a user entry for each one (you can't use type=friend because hints no longer work; and you can't use only type=peer entries, because authentication is done on ipaddress:port and matches the last entry on sip.conf instead of the correct peer). In this case, hints will work only for incoming calls to the watched hint. Outgoing calls do not update the hint status (presumably because the outgoing call uses the user object, and the incoming call uses the peer object). By: Eric Futch (efutch) 2006-12-29 10:48:27.000-0600 Noticed the same problem still on 1.4.0. By: Olle Johansson (oej) 2006-12-31 04:43:10.000-0600 Cunningpike: have you tried with the new limitonpeers option *and* using type=friend for the polycom? By: Anthony Rodgers (cunningpike) 2007-01-02 17:39:07.000-0600 Beautiful! Just to recap, you need: limitonpeers=yes in the [general] section of sip.conf call-limit=n (where n can be anything > 0) for each friend entry in sip.conf And that's it! Great job, folks! By: Steve Murphy (murf) 2007-01-03 00:00:12.000-0600 I hope I have diagnosed the situation correctly; if not, feel free to reopen and clarify the issue. By: Steve Murphy (murf) 2007-01-03 00:01:35.000-0600 It appears that perhaps some documentation on the new features of chan_sip in 1.4, and their ramifications are perhaps in order? By: Serge Vecher (serge-v) 2007-01-03 08:46:31.000-0600 is it 'limitonpeers' or 'limitonpeer' as in sip.conf.sample? I agree that a small addition to UPGRADE.TXT wouldn't hurt.