[reSIProcate] [reSIProcate-users] Help With onOfferRequired

[Byron Campen]

> <removed resip-users>
>
> On Jan 3, 2008 12:27 PM, Byron Campen <bcampen at estacado.net> wrote:
>>
>>
>>> On Jan 3, 2008 12:10 PM, Byron Campen <bcampen at estacado.net> 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.

	I could live with better documentation. Was just a thought.

Best regards,
Byron Campen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080103/e38d1478/attachment.bin>