Olivier, In principle, Registration/Presence and Call-Processing are separate logical functions but for cost or other reasons one could combine them in one software implementation or one physical box. For most parts, Asterisk is the Registrar in a SIP network and therefore maintains the location table. So, whatever entity runs the RFC 3680 notifier function will need access to Asterisk's location table. This is not the real issue though (the access to this table can be easily granted through the API). The answer to whether RFC 3680 should be built inside Asterisk or outside of it really depends on the kind of scalability one is looking for.
The scalability here refers to the number of subscriptions per each AoR (notification fan-out). Basically, you don't want to overload Asterisk with excessive number of subscriptions to the extent that they can negatively impact call/media processing. If you compare this with presence, the PUBLISH method allowed the presentity to inform only one entity (the presence server) of its state changes. The presence server was the one that did the drudgery of maintaining individual subscriptions and notifying the watchers. The presence model assumes that there are multiple watchers subscribing to the state of *a* presentity. RFC 3680 is a bit different than this, however. If you are looking to do free-seating using RFC 3680, I'd imagine that you will need only one subscription for each AoR in Asterisk (so you don't really have a 1:n fan-out issue). In that case, it is probably okay if the RFC 3680 'notifier' function was embedded within Asterisk itself. The current RFC 3265 support in Asterisk code should make the job of supporting RFC 3680 a bit easier. Raj ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Wednesday, August 22, 2007 8:27 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] rfc3680, reginfo+xml Thanks for replying, Raj. Do you think such feature should, ideally, be implemented in Asterisk should it be implemented in a dedicated software (presence ?) ? It seems to me it should, though I'm not aware of many devices using this feature, beside SIP hardphones. Would it be difficult to extend current code to comply with this RFC, when rfc3265 mechanism is already in place ? _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users