[reSIProcate] DUM -- enqueue/session modification thoughts

["Derek MacDonald" <Derek@xxxxxxxx>]

Fellow DUM people,

The long awaited enqueue discussion.

As some of you may remember, there was a plan to replace send with enqueue.
We
also once had a sendAnswerInAnyMessage() which would return the appropriate
SipMessage used to send an answer.  Enqueue also allowed PRACK/UPDATE to
work
well.

Another motivation for enqueue is when an INVITE transaction is complete but
the
ack has not been recieved. If the user requests another re-invite, it should
be
queued up until the ACK is received.  InviteSession::end can also result in
delayed behaviour.

The basic method to replace send would be:

//returns true if message will be sent immediately, just informational
virtual bool enqueue(SipMessage& msg);

//returns true if message will be sent immediately, otherwise does
nothing.(does
//not enqeue) This would be useful as a user may not wish to give if they
are in
//ACK limbo.
virtual bool sendImmediately(SipMessage& msg)

sendAnswerInAnyMessage() would be replaced by

//returns true if a message can be generated to transmit the SDP.
virtual bool enqueueSdp()

I think this method should only return true and enqueue a message if the SDP
can
be transmitted without affecting state of call establishment.  ie, this
would
not generate a 200 to the initial invite.  The only chance a user has to
adorn
the messages generated by enququeSdp is in onReadyToSend().

Example:

A sends INVITE (no offer) to B
B 200's and provides an offer
A ACKs with an answer
B gets onNewSession
B calls setOffer
B calls accept(), then enqueue with the sipmessage returned by accept as a
parameter
when B calls enqueue, it sends the 200 with the offer
A gets onConnected and onOffer
A calls setAnswer
A calls enqueueSdp() - no params

Note that enqueueSdp deprecates ackConnection and acceptOffer.

** Session Modification **

Session modification can be broken up into those that require user approval,
and
those that don't.

>From RFC 3311, section 5.1

   Although UPDATE can be used on confirmed
   dialogs, it is RECOMMENDED that a re-INVITE be used instead.  This is
   because an UPDATE needs to be answered immediately, ruling out the
   possibility of user approval.  Such approval will frequently be
   needed, and is possible with a re-INVITE.

So although we were planning on merging re-invite into modifySession, it may
be
a different method.

modifySession
modifySessionUserApproved ... or reInvite, with appropriate callbacks in
InviteSessionHandler.

Questions:

Should onDialogModified always be called for any session modification.
What are the 'appropriate callbacks' in InviteSessionHandler

--Derek