Re: [reSIProcate] [resiprocate/resiprocate] send/receive text message mechanism through MESSAGE message (#53)
In resip/recon/ConversationManager.hxx:
> @@ -483,6 +486,18 @@ public:
> virtual void onDtmfEvent(ParticipantHandle partHandle, int dtmf, int duration, bool up) = 0;
>
> ///////////////////////////////////////////////////////////////////////
> + // Pager Message Handlers /////////////////////////////////////////////
> + ///////////////////////////////////////////////////////////////////////
> +
> + virtual void onMessageArrived(resip::ServerPagerMessageHandle handle, const resip::SipMessage& message) = 0;
> + // Called when a MESSAGE has been successfully sent
> + virtual void onSuccess(resip::ClientPagerMessageHandle handle, const resip::SipMessage& status) = 0;
> + // Application could re-page the failed contents or just ingore it.
> + virtual void onFailure(resip::ClientPagerMessageHandle handle, const resip::SipMessage& status, std::auto_ptr<resip::Contents> contents) = 0;
> +
> + const char* sendMessage(const resip::NameAddr& destination, const resip::Data& msg, const resip::Mime& mimeType);
Off the top of my head, I think having out-of-dialog IM's and audio/video
in a single conversation is valuable. I like this better than having two
different conversation classes. We could use the From and/or To headers to
correlate out-of-dialog IMs with existing audio or video calls. Using your
desktop client example, it would be ideal if there was only one
conversation for all media types.
This doesn't seem like something that could be done in a few weeks
time-frame though.
I don't think the current implementation is ideal - but I also don't think
the it prevents us from doing it differently in the future (unless you care
about upgrade support).
Scott
…
On Thu, Aug 11, 2016 at 3:55 AM, Daniel Pocock ***@***.***> wrote:
In resip/recon/ConversationManager.hxx
<
#53 (comment)>:
> @@ -483,6 +486,18 @@ public:
> virtual void onDtmfEvent(ParticipantHandle partHandle, int dtmf, int duration, bool up) = 0;
>
> ///////////////////////////////////////////////////////////////////////
> + // Pager Message Handlers /////////////////////////////////////////////
> + ///////////////////////////////////////////////////////////////////////
> +
> + virtual void onMessageArrived(resip::ServerPagerMessageHandle handle, const resip::SipMessage& message) = 0;
> + // Called when a MESSAGE has been successfully sent
> + virtual void onSuccess(resip::ClientPagerMessageHandle handle, const resip::SipMessage& status) = 0;
> + // Application could re-page the failed contents or just ingore it.
> + virtual void onFailure(resip::ClientPagerMessageHandle handle, const resip::SipMessage& status, std::auto_ptr<resip::Contents> contents) = 0;
> +
> + const char* sendMessage(const resip::NameAddr& destination, const resip::Data& msg, const resip::Mime& mimeType);
@sgodin <
https://github.com/sgodin> do you mean the existing Conversation
object though, or should some other Conversation object be used for chat?
E.g. we could have an abstract Conversation and then subclasses
ChatConversation and MediaConversation
The distinction between the two may be the existence of a SIP dialog.
Given that conversations can change (e.g. they start on chat, then do some
webcam call, then fall back to chat for a while), maybe it is better not to
have such a class hierarchy though.
When recon is used on the desktop (which is the aim here), the user may
have a chat conversation with one peer and a combined chat/webcam session
with another peer concurrently, but those would be 2 or 3 different
Conversation instances.
If you are not happy for this to go into the API, what would you feel is a
reasonable bare-minimum implementation of this that we could accept in
recon for now? I can also spend some time helping on the API side over the
next few days while Mateus finishes the telepathy component.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/resiprocate/resiprocate/pull/53/files/9e3b4ac1410cb4a880dfbe7a68727478b961d5c0#r74380474>,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ACtNUXTfYpARP3I2JsZkskknuacqAgAnks5qetVegaJpZM4JYkAY>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.