[reSIProcate] [resiprocate/resiprocate] send/receive text message mechanism through MESSAGE message (#53)

[Scott Godin]

> @@ -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 <notifications at github.com>
wrote:

> In resip/recon/ConversationManager.hxx
> <https://github.com/resiprocate/resiprocate/pull/53#discussion_r74380474>:
>
> > @@ -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 or view it on GitHub:
https://github.com/resiprocate/resiprocate/pull/53/files/9e3b4ac1410cb4a880dfbe7a68727478b961d5c0#r74504225
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20160811/ce8cf333/attachment.htm>