RE: [reSIProcate] DUM state & design

["Derek MacDonald" <Derek@xxxxxxxx>]

So, it looks like Cullen agrees about Publications being that type of usage,
as he has already written a fair bit of ClientPublication.

One question; ClientPublication has the CSEQ being incremented on refresh,
but the example flow in publish-04(section 15) has a different call-id for
each publish being sent.


-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Derek
MacDonald
Sent: Monday, June 28, 2004 1:03 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] DUM state & design


So, the basic InviteSession API's are fairly cooked and implemented,
although Enqueue/etc could change things.  The AuthManager needs some work,
but 401/407's are being handled in the basic invite/register cases.

I'm going to start hacking PUBLISH/SUBSCRIBE/NOTIFY and the design there
doesn't look particuarily cooked. I've changed the headers to more closely
reflect other API's, but opinions are welcome.

David and I were talking about it, and we think Publish is another type of
usage(def. not a sip dialog, but it has a lifespan) that looks similar to
Registration, w/out the Call-ID being re-used. It seems incorrect that a
Dialog can only have one ServerSubscription but many ClientSubscriptions, so
I'm going to change that barring a compelling reason.

On another topic, I'm adding navigation methods to the AppDialog userdata
that will allow a user to retrieve an invite or sbscription usage.  This
will do for now, but it seems likely that handlers and userdata will be
merged.

--Derek


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel