Re: [reSIProcate-users] [reSIProcate] Help With onOfferRequired

[Byron Campen <bcampen@xxxxxxxxxxxx>]

> On Jan 3, 2008 12:10 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
> >         Cross-posting because this brings up a design question:
> >
> >         I think you need to also call accept() at this point to  
> > get the
> > offer to actually go out.
> >
> >         To the devs, would it make sense to have a bool in  
> > InviteSession
> > along the lines of mReadyToAccept that the app-writer could set to
> > true if building an automaton UA, or set to false if building a UA
> > that needs to wait for user interaction first?
> I don't think so. Note that the answer could come in the provisional
> response, if the UAC and UAS support 100rel. I think the documentation
> should be clear that you still need to call provisional and/or answer
> to cause the signaling to go out. Even an automaton may want to signal
> a provisional response. e.g. to indicate that a call is queued.

I actually had the possibility of the offer going out in the  
provisional in mind here; whenever we have 100rel UAS support, this  
bool could determine whether provideOffer() sends the offer in a  
100rel, or a 200. Although this might be complicated.

Best regards,
Byron Campen

Attachment: smime.p7s
Description: S/MIME cryptographic signature