[asterisk-dev] [Code Review] 3741: RLS: Add body generation + some bug fixes

Jonathan Rose reviewboard at asterisk.org
Wed Jul 23 11:20:34 CDT 2014


-----------------------------------------------------------
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:sipp at 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 at 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 at 127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
 To: "sipp" <sip:sipp at 127.0.0.1>;tag=12342SIPpTag001
 Contact: <sip:127.0.0.1:5060>
 Call-ID: 1-12342 at 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 at 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 at 10.24.18.246:5060" version="0" fullState="true">
  <name>pres_list</name>
  <resource uri="sip:alice at 10.24.18.246:5060">
   <name>alice</name>
   <instance id="eilet" state="active" cid="zukoj at 10.24.18.246" />
  </resource>
  <resource uri="sip:bob at 10.24.18.246:5060">
   <name>bob</name>
   <instance id="coitg" state="active" cid="rxmdq at 10.24.18.246" />
  </resource>
 </list>
 
 --miqvi
 Content-ID: <zukoj at 10.24.18.246>
 Content-Type: application/pidf+xml
 Content-Length:   514
 
 <?xml version="1.0" encoding="UTF-8"?>
 <presence entity="sip:alice at 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 at 127.0.0.1></contact>
  </tuple>
  <pp:person>
   <status />
  </pp:person>
 </presence>
 
 --miqvi
 Content-ID: <rxmdq at 10.24.18.246>
 Content-Type: application/pidf+xml
 Content-Length:   510
 
 <?xml version="1.0" encoding="UTF-8"?>
 <presence entity="sip:bob at 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 at 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 at 127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
 To: "sipp" <sip:sipp at 127.0.0.1>;tag=12342SIPpTag001
 Contact: <sip:127.0.0.1:5060>
 Call-ID: 1-12342 at 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 at 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 at 10.24.18.246:5060" version="1" fullState="false">
  <name>pres_list</name>
  <resource uri="sip:alice at 10.24.18.246:5060">
   <name>alice</name>
   <instance id="zeais" state="active" cid="dnkaa at 10.24.18.246" />
  </resource>
 </list>
 
 --fhojg
 Content-ID: <dnkaa at 10.24.18.246>
 Content-Type: application/pidf+xml
 Content-Length:   575
 
 <?xml version="1.0" encoding="UTF-8"?>
 <presence entity="sip:alice at 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 at 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 at 127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
 To: "sipp" <sip:sipp at 127.0.0.1>;tag=12342SIPpTag001
 Contact: <sip:127.0.0.1:5060>
 Call-ID: 1-12342 at 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 at 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 at 10.24.18.246:5060" version="2" fullState="false">
  <name>pres_list</name>
  <resource uri="sip:alice at 10.24.18.246:5060">
   <name>alice</name>
   <instance id="mxocy" state="terminated" cid="hawse at 10.24.18.246" />
  </resource>
 </list>
 
 --cwzac
 Content-ID: <hawse at 10.24.18.246>
 Content-Type: application/pidf+xml
 Content-Length:   514
 
 <?xml version="1.0" encoding="UTF-8"?>
 <presence entity="sip:alice at 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 at 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 at 127.0.0.1>;tag=def89f05-5c08-4ed0-bbb5-f6a2585201cc
 To: "sipp" <sip:sipp at 127.0.0.1>;tag=12342SIPpTag001
 Contact: <sip:127.0.0.1:5060>
 Call-ID: 1-12342 at 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 at 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 at 10.24.18.246:5060" version="3" fullState="false">
  <name>pres_list</name>
  <resource uri="sip:bob at 10.24.18.246:5060">
   <name>bob</name>
   <instance id="ahkhd" state="terminated" cid="rgtys at 10.24.18.246" />
  </resource>
 </list>
 
 --fllxf
 Content-ID: <rgtys at 10.24.18.246>
 Content-Type: application/pidf+xml
 Content-Length:   510
 
 <?xml version="1.0" encoding="UTF-8"?>
 <presence entity="sip:bob at 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 at 127.0.0.1></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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140723/25e50403/attachment-0001.html>


More information about the asterisk-dev mailing list