[#XECS-1390] ACD server inaccurately terminates subscription to the agent

sipXecs

ACD server inaccurately terminates subscription to the agent

Created: 2008-04-30 08:41 Updated: 2008-11-07 09:47

Component/s:

sipXtackLib, ACD

Affects Version/s:

3.10.1

Fix Version/s:

None

Original Estimate:

2 days

Remaining Estimate:

2 days

Time Spent:

Unknown

File Attachments:

acd_monitoring_agent_subscription_termination_sip_only.pcap (29 kb)

Environment:

sipx 3.10.1 (12233), LIP 6830 phone (1.2.38sp)

Issue Links:

Related

This issue related to:
	~~XECS-1265~~ BLF: sipxrls fails to send to rls lis...

Description

« Hide

When ACD terminates the subscription to the agent, whose presence it monitors,
ACD sends SUBSCRIBE with expires:0, the phone answers with 200ok, and the phone sends NOTIFY with "subscription-state: terminated". Sipx answers with "481: subscription does not exist".

Trace is attached.

As far as I understand this is inaccurate:

Rfc3265:
3.1.4.3. Unsubscribing

   Unsubscribing is handled in the same way as refreshing of a
   subscription, with the "Expires" header set to "0". Note that a
   successful unsubscription will also trigger a final NOTIFY message.

So, sipx should answer with 200ok to the final NOTIFY with "subscription-state: terminated".

Nikolay.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Nikolay Kondratyev - 2008-04-30 08:45

Steps to reproduce:
The easyest way to reproduce, i belive, is:
Create ACD with at least one agent with "monitor presence". Activate ACD server.
"Sign in" the agent (trough the web interface, for example). ACD starts monitoring the agent.
"Sign out" the agent. ACD will terminate the subscription as described above.

[ Permlink | « Hide ]

Scott Lawrence - 2008-04-30 08:58

This is probably actually a problem with the SubscriptoinMgr; assigning to Dale to check that out.

Priority reduced to Minor.

[ Permlink | « Hide ]

Dale R. Worley - 2008-04-30 11:04

An interesting case -- the RFC requires the notifier to send a final NOTIFY, but I'm not sure that the subscriber is required to return a 200 to the NOTIFY. In any case, the notifier is in the process of destroying the subscription, and the only result of receiving a 481 can be the destruction of the subscription, so I doubt there's any functional problem. But I suppose we really should clean this up, at least to avoid something that people will be distracted by when debugging problems.

[ Permlink | « Hide ]

Nikolay Kondratyev - 2008-05-04 01:10

Just my 2 cents in addition:
May be there is no functional problem indeed. But the "signalling procedure" is not completed. Also some phones or fxs gw's may get stuck with this. And also this "481" leads to unneeded signalling - resending of the final NOTIFY.

[ Permlink | « Hide ]

Dale R. Worley - 2008-06-20 12:40

I think we should go ahead with this fix, but I will note that in regard to:

"And also this "481" leads to unneeded signalling - resending of the final NOTIFY."

This resending is an error -- the notifier is *required* to delete the subscription upon receiving the 481 and *required* to not send any further NOTIFYs. See RFC 3265 section 3.2.2:

   If the NOTIFY request fails (as defined above) due to an error
   response, and the subscription was installed using a soft-state
   mechanism, the notifier MUST remove the corresponding subscription.