[Home]

Summary:ASTERISK-09999: [patch] Add Basic Support For RFC 4662 (Subscribe to lists)
Reporter:Gregory Hinton Nietsky (irroot)Labels:
Date Opened:2007-08-01 07:56:14Date Closed:2011-06-07 14:02:55
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 0000-Asterisk-RFC4662.patch
( 1) asterisk-1.4.8.rlmi
( 2) BLF4.cap
( 3) eventlist.txt
( 4) poly.txt
( 5) sip.rlmi
( 6) sip-20070808-1.4.9.rlmi
Description:Preamble to 4662

---
  This document presents an extension to the Session Initiation
  Protocol (SIP)-Specific Event Notification mechanism for subscribing
  to a homogeneous list of resources.  Instead of sending a SUBSCRIBE
  for each resource individually, the subscriber can subscribe to an
  entire list and then receive notifications when the state of any of
  the resources in the list changes.
---

the polycom 601 BLF uses this extension to populate and manage its BLF i cant see why not to support it in asterisk ??

please see the packet trace (supplied by polycom thx this is invaluable ...) a comparison (summary of progress so far) and a patch against 1.4.9 (obviously this is for 1.6 ...)

****** ADDITIONAL INFORMATION ******

the 601 can use polycoms standard "buddies" xpidf+xml apparently useing RLMI is prefered and obviously offers more features/interop ...

Comments:By: Gregory Hinton Nietsky (irroot) 2007-08-01 08:05:25

ok please ignore the changes to support snom directed pickup ...

the idea is now to sip_alloc a subscription for every line and add append the dialog-info to the message ...

is there a better way ...  ??

if a notify is required for a single line do not send a "fullstate" ...

is there any requirement for this ???

this is realy bare bones and not even close to functional some input as to wether this is heading on the right track will be appreciated.
By: Joshua C. Colp (jcolp) 2007-08-01 08:44:42

Your patch is also backwards... and you will have much better luck with discussions on the -dev mailing list.
By: Gregory Hinton Nietsky (irroot) 2007-08-01 08:59:22

yeah id love to ... not been reciving mail from dev for a while now says its bouncing ... let me fix it up ...
By: Gregory Hinton Nietsky (irroot) 2007-08-04 08:43:09

ok here is a cleaner more practical and apparently working version.

the sip debug (poly.txt) shows the story.
By: Gregory Hinton Nietsky (irroot) 2007-08-08 03:58:08

ok here it is im trying to get the loose ends iorned out please note this will require TCP support (ASTERISK-4778)
By: Olle Johansson (oej) 2007-11-05 03:40:56.000-0600

If this requires TCP support, it has to be put on hold for a while. TCP support patches are very experimental and won't be included soon.
By: Gregory Hinton Nietsky (irroot) 2008-01-19 03:19:19.000-0600

TCP is now been included so ill be dusting off a 601 and continuing to work on this in the near future time is a comodity i dont have at the momment unfortunately.
By: Olle Johansson (oej) 2008-07-06 08:18:09

Have you found any time to update this to svn trunk? I would happily look into adding it. Thanks.
By: Mark Michelson (mmichelson) 2008-08-25 17:21:47

I've been reading over the RFC and the latest patch submitted, and I have a few questions regarding phone behavior when making use of this functionality.

To preface this, I'm used to maintaining a buddy list on my phone. Either some sort of button with a lamp represents a subscribed buddy, or there is a directory of buddies I can access somehow. When implementing support for this RFC, it appears that the buddy list is not maintained locally but is maintained via some remote method.

How does the phone represent the information that is sent back to it with a NOTIFY? Does the phone populate its buttons and buddy list directory itself? Can you also use your phone to subscribe to buddies not in the list or are you restricted to just buddies in the remote list? Is it possible for a phone to subscribe to a list that the phone itself generated?
By: Raj Jain (rjain) 2008-09-02 02:13:32

putnopvut:

Yes, this RFC assumes that the RLS (Resource List Server) is aware of the composition of list URIs. How the list URI is populated in the server is out-of-band of SIP.

The behavior of the phone doesn't change much (it'll still contain local buddy list as before). It'll receive NOTIFYs like before (even though they can now be optimized to contain multipart MIME to deliver states of several buddies in one message) and process them like before.
By: Mark Michelson (mmichelson) 2008-12-04 11:23:53.000-0600

I am unassigning myself from this because the work load for me is such that I cannot find a reasonable time in the near future that I would be able to work on this.
By: David Vossel (dvossel) 2009-04-10 17:51:13

I've written a patch for this in trunk, but am having trouble testing it.

I have the following enabled within my polycom 650's phone config
<attendant
 attendant.uri="1234"
 attendant.reg="3"
/>

with this option set, I get rlmi SUBSCRIBE requests from the phone, When I send a NOTIFY (an example is given below), the phone responds with a 200ok, but nothing happens.  I'd expect the phone's expansion module to be populated with the resources within the RLMI list, but it doesn't happen.  Since I don't have a server that supports rlmi to test the Polycom with, I really don't know what the expected behavior is.  I've looked through the polycom admin guide but its rather vague about the whole thing...

So, has anyone gotten a rfc4662 capable Polycom phone to work with an rlmi capable server. if so, how was the phone configured and what were the results.


NOTIFY sip:5006@10.24.22.246 SIP/2.0
Via: SIP/2.0/UDP 10.24.10.231:5060;branch=z9hG4bK3d440288;rport
Max-Forwards: 70
From: <sip:1234@whatever>;tag=as3ecb08bc
To: "5006" <sip:5006@whatever>;tag=2EE85E33-7BBC79C4
Contact: <sip:1234@10.24.10.231>
Call-ID: 138c3240-c616fe71-effd8bc2@10.24.22.246
CSeq: 115 NOTIFY
User-Agent: Asterisk PBX SVN-dvossel-sip_resource_list_trunk-r187311M-/trunk
Subscription-State: active
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";start="<280322ac@whatever>";boundary="50UBfW7LSCVLtggUPe5z"
Event: dialog
Content-Length: 922

--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <280322ac@whatever>
Content-Type: application/rlmi+xml; charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:1234@whatever" version="0" fullState="true">
<resource uri="sip:custom3@whatever">
<name>custom3</name>
<instance id="099291ed" state="active" cid="7a551027@whatever"/>
</resource>
</list>

--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <7a551027@whatever>
Content-Type: application/dialog-info+xml

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:custom3@whatever">
<dialog id="custom3">
<state>terminated</state>
</dialog>
</dialog-info>


By: David Herselman (bbs2web) 2009-05-02 07:19:57

dvossel: Could you please provide a newer 1.6.0 patch? I've tried to ammend the current one to 1.6.0.5 but may misplaced one of the hunks. I'm unfortunately not a developer but have tried as best I could.

Uploaded as '0000-Asterisk-RFC4662.patch'
By: David Vossel (dvossel) 2009-05-04 09:08:50

I don't think I'll be able to provide something that can be patched perfectly into 1.6.0.  The current patch I'm working on is only for Trunk.  I've just gotten some feedback from a polycom rep as to why my patch isn't working as expected.  When I get the time, I'll test out the new changes and post the patch here for additional testing.
By: Leif Madsen (lmadsen) 2009-06-10 12:54:56

Status changed to reflect we're waiting on dvossel to find some time to move this issue forward. Thanks!
By: David Vossel (dvossel) 2009-07-10 11:14:37

Unfortunately this is not a feature we are going to implement at the moment.  If anyone is interested in developing it, your contribution is welcome.  Just make sure it is developed in trunk so it can be committed into the project.

I've spent sometime with this issue and have a few guidelines to help anyone interested in developing this.

Resource lists should be configurable in sip.conf as "type = resourcelist"

------sip.conf example-----
[list1]           ; resourcelist identifier
type=resourcelist ; declaring type resourcelist
context=local ; context in which resource list can be subscribed
monitor=1001 ; extensions/hints to monitor within list
monitor=1002
monitor=1003

--------How to represent an rlist in the code-------
Resourcelists should be built just like peers using astobj2 and an ao2_container to store them.  Each rlist should have an internal list of watchers, which are people who subscribe to them to get updates, as well as a list of resources to monitor.

struct sip_rlist_resource {
int stateid;
int laststate;

AST_DECLARE_STRING_FIELDS(
AST_STRING_FIELD(exten);       /*!< This is an extension to watch within rlist */
AST_STRING_FIELD(contentid);   /*!< Dialog Content ID */
);

AST_LIST_ENTRY(sip_rlist_resource) entry;
};

/* todohere add brief */
struct sip_rlist {
char name[80]; /*!< This is the extension to subscribe too for list */
AST_DECLARE_STRING_FIELDS (
AST_STRING_FIELD(context);
AST_STRING_FIELD(contentid);  /*!< Dialog Content ID */
);
int the_mark;
int num_watchers;
int startmonitor;
AST_LIST_HEAD_NOLOCK(, sip_pvt) watchers;
AST_LIST_HEAD_NOLOCK(, sip_rlist_resource) resources;
};

If anyone has any questions about this feel free to contact me by email [dvossel at digium dot com] or in #asterisk-dev where my name is The_Boy_Wonder.