< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


<removed resip-users>

On Jan 3, 2008 12:27 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
>
>
> > 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.

I really don't think this is such a good idea. The author of an
automaton needs to understand that they have to optionally call
provisional and then accept or reject. provideOffer or provideAnswer
needs to be called before accept. In my opinion, layering another api
on top of the existing one with different semantics will confuse
developers. I don't think there is enough to gain here to justify the
api addition.

Perhaps we just need to address this with better documentation.