<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/3741/">https://reviewboard.asterisk.org/r/3741/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I was checking this work against the full state test (with some local modifications to get it running)
pjsip.conf:
[pres_list]
type = resource_list
event = presence
list_item = alice
list_item = bob
full_state = yes
[sipp]
type=aor
max_contacts=1
contact=sip:sipp@127.0.0.1:5061
[sipp]
type = endpoint
context = default
aors=sipp
transport=local
[local]
type=transport
protocol=udp
bind=0.0.0.0:5060
And was running into the following problem:
The initial notify comes back OK. It contains full state and all the list items.
A second notify (after Alice's device state is changed to INUSE) fails to include full state and does not include bob in the list.
1st NOTIFY
NOTIFY sip:sipp@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bKPjc30600f0-7562-4a33-b72a-b045e3fdf02e
From: "sut" <sip:pres_list@127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
To: "sipp" <sip:sipp@127.0.0.1>;tag=12342SIPpTag001
Contact: <sip:127.0.0.1:5060>
Call-ID: 1-12342@127.0.0.1
CSeq: 29997 NOTIFY
Event: presence
Subscription-State: active;expires=3600
Allow-Events: message-summary, presence, dialog, refer
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";boundary=miqvi
Content-Length: 1824
--miqvi
Content-ID: <ynmfs@10.24.18.246>
Content-Type: application/rlmi+xml
Content-Length: 469
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:pres_list@10.24.18.246:5060" version="0" fullState="true">
<name>pres_list</name>
<resource uri="sip:alice@10.24.18.246:5060">
<name>alice</name>
<instance id="eilet" state="active" cid="zukoj@10.24.18.246" />
</resource>
<resource uri="sip:bob@10.24.18.246:5060">
<name>bob</name>
<instance id="coitg" state="active" cid="rxmdq@10.24.18.246" />
</resource>
</list>
--miqvi
Content-ID: <zukoj@10.24.18.246>
Content-Type: application/pidf+xml
Content-Length: 514
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="sip:alice@10.24.18.246:5060" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person">
<note>Ready</note>
<tuple id="alice">
<status>
<basic>open</basic>
</status>
<contact priority="1">"sipp" <sip:sipp@127.0.0.1></contact>
</tuple>
<pp:person>
<status />
</pp:person>
</presence>
--miqvi
Content-ID: <rxmdq@10.24.18.246>
Content-Type: application/pidf+xml
Content-Length: 510
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="sip:bob@10.24.18.246:5060" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person">
<note>Ready</note>
<tuple id="bob">
<status>
<basic>open</basic>
</status>
<contact priority="1">"sipp" <sip:sipp@127.0.0.1></contact>
</tuple>
<pp:person>
<status />
</pp:person>
</presence>
--miqvi--
Second NOTIFY
NOTIFY sip:127.0.0.1:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bKPj73fd5222-ae9d-4bb8-80a6-0852376c9cfd
From: "sut" <sip:pres_list@127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
To: "sipp" <sip:sipp@127.0.0.1>;tag=12342SIPpTag001
Contact: <sip:127.0.0.1:5060>
Call-ID: 1-12342@127.0.0.1
CSeq: 29998 NOTIFY
Event: presence
Subscription-State: active;expires=3599
Allow-Events: message-summary, presence, dialog, refer
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";boundary=fhojg
Content-Length: 1128
--fhojg
Content-ID: <fejvi@10.24.18.246>
Content-Type: application/rlmi+xml
Content-Length: 328
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:pres_list@10.24.18.246:5060" version="1" fullState="false">
<name>pres_list</name>
<resource uri="sip:alice@10.24.18.246:5060">
<name>alice</name>
<instance id="zeais" state="active" cid="dnkaa@10.24.18.246" />
</resource>
</list>
--fhojg
Content-ID: <dnkaa@10.24.18.246>
Content-Type: application/pidf+xml
Content-Length: 575
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="sip:alice@10.24.18.246:5060" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person">
<note>On the phone</note>
<tuple id="alice">
<status>
<basic>closed</basic>
</status>
<contact priority="1">"sipp" <sip:sipp@127.0.0.1></contact>
</tuple>
<pp:person>
<status>
<ep:activities>ep:busy</ep:activities>
</status>
</pp:person>
</presence>
--fhojg--
Also, I'm not sure if this is an issue that needs to be dealt with here or in the test suite, but after Asterisk starts shutting down, additional NOTIFY messages are sent which the currently written tests appear to anticipate as not happening. These occur as PBX is unloading, probably as a result of removing the hints:
Third NOTIFY
NOTIFY sip:127.0.0.1:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bKPjf11fa854-cbb4-4d3a-b817-59998b313da7
From: "sut" <sip:pres_list@127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
To: "sipp" <sip:sipp@127.0.0.1>;tag=12342SIPpTag001
Contact: <sip:127.0.0.1:5060>
Call-ID: 1-12342@127.0.0.1
CSeq: 29999 NOTIFY
Event: presence
Subscription-State: active;expires=3599
Allow-Events: message-summary, presence, dialog, refer
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";boundary=cwzac
Content-Length: 1071
--cwzac
Content-ID: <mmjra@10.24.18.246>
Content-Type: application/rlmi+xml
Content-Length: 332
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:pres_list@10.24.18.246:5060" version="2" fullState="false">
<name>pres_list</name>
<resource uri="sip:alice@10.24.18.246:5060">
<name>alice</name>
<instance id="mxocy" state="terminated" cid="hawse@10.24.18.246" />
</resource>
</list>
--cwzac
Content-ID: <hawse@10.24.18.246>
Content-Type: application/pidf+xml
Content-Length: 514
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="sip:alice@10.24.18.246:5060" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person">
<note>Ready</note>
<tuple id="alice">
<status>
<basic>open</basic>
</status>
<contact priority="1">"sipp" <sip:sipp@127.0.0.1></contact>
</tuple>
<pp:person>
<status />
</pp:person>
</presence>
--cwzac--
Fourth NOTIFY:
NOTIFY sip:127.0.0.1:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bKPj4f6279be-4406-4693-b5a4-7c83aaffce70
From: "sut" <sip:pres_list@127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
To: "sipp" <sip:sipp@127.0.0.1>;tag=12342SIPpTag001
Contact: <sip:127.0.0.1:5060>
Call-ID: 1-12342@127.0.0.1
CSeq: 30000 NOTIFY
Event: presence
Subscription-State: active;expires=3599
Allow-Events: message-summary, presence, dialog, refer
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";boundary=fllxf
Content-Length: 1063
--fllxf
Content-ID: <cjjvu@10.24.18.246>
Content-Type: application/rlmi+xml
Content-Length: 328
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:pres_list@10.24.18.246:5060" version="3" fullState="false">
<name>pres_list</name>
<resource uri="sip:bob@10.24.18.246:5060">
<name>bob</name>
<instance id="ahkhd" state="terminated" cid="rgtys@10.24.18.246" />
</resource>
</list>
--fllxf
Content-ID: <rgtys@10.24.18.246>
Content-Type: application/pidf+xml
Content-Length: 510
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="sip:bob@10.24.18.246:5060" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person">
<note>Ready</note>
<tuple id="bob">
<status>
<basic>open</basic>
</status>
<contact priority="1">"sipp" <sip:sipp@127.0.0.1></contact>
</tuple>
<pp:person>
<status />
</pp:person>
</presence>
--fllxf--</pre>
<br />
<p>- Jonathan Rose</p>
<br />
<p>On July 10th, 2014, 4:59 p.m. CDT, Mark Michelson wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated July 10, 2014, 4:59 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-23867">ASTERISK-23867</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This represents the final piece of resource list subscription server support in Asterisk.
The lion's share of this changeset adds support for generating multipart bodies for resource list subscriptions. While testing, I also came across some other bugs, which are fixed here, too:
* shutdown_subscriptions - Was attempting to call a handler's subscription_shutdown() on list subscriptions. This only should be done for leaf subscriptions. Also, there was a refleak for list subscriptions since they did not release references to their children.
* subscription_get_generator_from_rdata - This would not function correctly if multiple Accept headers were present on an incoming SUBSCRIBE.
Though I say this is the final piece, what I really mean is that it's the final piece necessary to give Asterisk basic support for RLS. There are some avenues worth exploring still:
* Dynamic lists: Currently, if a subscriber subscribes to a list, the content of that list is determined at subscription time and cannot change. If the resources on a configured list change, then the subscriber must end the current subscription and create a new subscription to the list in order to have the altered list elements appear properly. It is doable, though not necessarily easy, to modify the contents of a list subscription during the lifetime of the subscription dialog.
* Ad-hoc lists: Lists currently must be configured on the server side. RFC 5367 supports the idea of the subscriber specifying a list of resources to subscribe to. Adding support for this would be nifty, though I am unsure what clients support this.
* Methods of limiting body size: Currently, when sending full state of a resource list, Asterisk also sends instances of all resources. For lists of generous size, this can mean exceeding the default maximum packet length PJSIP allows. Asterisk could be modified to send just an RLMI body when communicating full state and then sending series of NOTIFYs with partial state in order to communicate the states of all resources in the list.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Though I currently do not have testsuite tests I can point to as passing, I have manually performed the test cases covered by /r/3673 and through visual inspection, I can say that they work as intended. In addition to those tests, I also tested subscribing to lists of lists and ensured that the generated body looked correct in that case. I also tested batched notifications to ensure that the notification was batched, that multiple state changes would be reflected in a single batched notification, and that operations that should cancel a batch did so properly.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/team/mmichelson/rls-notify/res/res_pjsip_pubsub.c <span style="color: grey">(418321)</span></li>
<li>/team/mmichelson/rls-notify/include/asterisk/res_pjsip_pubsub.h <span style="color: grey">(418321)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/3741/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>