RE: [reSIProcate] DUM -- enqueue/session modification thoughts -- less like blank verse

["Derek MacDonald" <Derek@xxxxxxxx>]

pasting from emacs->outlook did funny things, hopefully this looks better.

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





_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel