----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3741/#review12835 -----------------------------------------------------------
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:[email protected]: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:[email protected]:5061 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bKPjc30600f0-7562-4a33-b72a-b045e3fdf02e From: "sut" <sip:[email protected]>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc To: "sipp" <sip:[email protected]>;tag=12342SIPpTag001 Contact: <sip:127.0.0.1:5060> Call-ID: [email protected] 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: <[email protected]> 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:[email protected]:5060" version="0" fullState="true"> <name>pres_list</name> <resource uri="sip:[email protected]:5060"> <name>alice</name> <instance id="eilet" state="active" cid="[email protected]" /> </resource> <resource uri="sip:[email protected]:5060"> <name>bob</name> <instance id="coitg" state="active" cid="[email protected]" /> </resource> </list> --miqvi Content-ID: <[email protected]> Content-Type: application/pidf+xml Content-Length: 514 <?xml version="1.0" encoding="UTF-8"?> <presence entity="sip:[email protected]: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:[email protected]></contact> </tuple> <pp:person> <status /> </pp:person> </presence> --miqvi Content-ID: <[email protected]> Content-Type: application/pidf+xml Content-Length: 510 <?xml version="1.0" encoding="UTF-8"?> <presence entity="sip:[email protected]: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:[email protected]></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:[email protected]>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc To: "sipp" <sip:[email protected]>;tag=12342SIPpTag001 Contact: <sip:127.0.0.1:5060> Call-ID: [email protected] 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: <[email protected]> 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:[email protected]:5060" version="1" fullState="false"> <name>pres_list</name> <resource uri="sip:[email protected]:5060"> <name>alice</name> <instance id="zeais" state="active" cid="[email protected]" /> </resource> </list> --fhojg Content-ID: <[email protected]> Content-Type: application/pidf+xml Content-Length: 575 <?xml version="1.0" encoding="UTF-8"?> <presence entity="sip:[email protected]: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:[email protected]></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:[email protected]>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc To: "sipp" <sip:[email protected]>;tag=12342SIPpTag001 Contact: <sip:127.0.0.1:5060> Call-ID: [email protected] 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: <[email protected]> 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:[email protected]:5060" version="2" fullState="false"> <name>pres_list</name> <resource uri="sip:[email protected]:5060"> <name>alice</name> <instance id="mxocy" state="terminated" cid="[email protected]" /> </resource> </list> --cwzac Content-ID: <[email protected]> Content-Type: application/pidf+xml Content-Length: 514 <?xml version="1.0" encoding="UTF-8"?> <presence entity="sip:[email protected]: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:[email protected]></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:[email protected]>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc To: "sipp" <sip:[email protected]>;tag=12342SIPpTag001 Contact: <sip:127.0.0.1:5060> Call-ID: [email protected] 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: <[email protected]> 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:[email protected]:5060" version="3" fullState="false"> <name>pres_list</name> <resource uri="sip:[email protected]:5060"> <name>bob</name> <instance id="ahkhd" state="terminated" cid="[email protected]" /> </resource> </list> --fllxf Content-ID: <[email protected]> Content-Type: application/pidf+xml Content-Length: 510 <?xml version="1.0" encoding="UTF-8"?> <presence entity="sip:[email protected]: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:[email protected]></contact> </tuple> <pp:person> <status /> </pp:person> </presence> --fllxf-- - Jonathan Rose On July 10, 2014, 4:59 p.m., Mark Michelson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3741/ > ----------------------------------------------------------- > > (Updated July 10, 2014, 4:59 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23867 > https://issues.asterisk.org/jira/browse/ASTERISK-23867 > > > Repository: Asterisk > > > Description > ------- > > 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. > > > Diffs > ----- > > /team/mmichelson/rls-notify/res/res_pjsip_pubsub.c 418321 > /team/mmichelson/rls-notify/include/asterisk/res_pjsip_pubsub.h 418321 > > Diff: https://reviewboard.asterisk.org/r/3741/diff/ > > > Testing > ------- > > 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. > > > Thanks, > > Mark Michelson > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
