[reSIProcate] dum changes to Invite Sessions

[Jason Fischl]

Scott Godin wrote:
> Hi Jason,
> 
> I was just going through the .dot files you checked in.  A couple of points:
> 1.  They should probably be in the dum/doc dir. : )

I'll move em once.

> 2.  dum-uac-state.dot, dum-clientinvite-state.dot, dum-uas-state.dot are all
> pretty much exactly the same.  In fact dum-clientinvite-state.dot and
> dum-uas-state.dot are identical. 

I'll post when they are all ready - still not finished yet. The diagrams 
are pretty nasty.

> 
> Notes about proposal:
> 1.  I agree that the current offer/answer state machine and it's
> disjoint-ness from the signaling, could use an overhaul.  It is currently
> the source of most of the logic in my application - since I must track state
> in order to know how to respond correctly in the current onOffer callback.
> 

This will get much easier.

> 2.  I suspect adorning messages on onReadyToSend may cause a bit of a
> headache for some people porting to this new logic.  The app may now have to
> track state so that the onReadyToSend callback knows how to adorn messages
> correctly.  Note:  My main use of adorning is to add a Warnings header to
> error responses and to add contact headers to redirect responses (ie. 302) -
> I guess we could just add an override to the reject/redirect calls so that
> you pass in a warning/contact header, to make this easier.  
> 

Derek and I had a phone call to discuss this issue. We will provide 
alternate interfaces for:

// These 3 are as proposed earlier
void provisional(int code);
virtual void reject(int code);
virtual void accept(int code=200);

// Additional interfaces that allow the app to adorn messages and then 
// send them. It is recommended
SipMessage& provisionalAdorn(int code);
virtual SipMessage& rejectAdorn(int code);
virtual SipMessage& acceptAdorn(int code=200);
virtual void send(const SipMessage& msg);

Usage would look like this for the adorn versions:
ServerInviteSessionHandle handle;
SipMessage& rejection = handle->rejectAdorn(482);
rejection.header(h_Warnings).push_back(warning);
handle->send(rejection);

Most applications would just do:
ServerInviteSessionHandle handle;
handle->reject(482); // would send synchronously


Derek also proposed that we add the following interfaces to 
ServerInviteSession:

void ServerInviteSession::redirect(resip::NameAddrs contacts);
void ServerInviteSession::provideEarlyMedia(const SdpContents* early);


> Thanks!
> 
> Scott
> 
> 
> -----Original Message-----
> From: Jason Fischl [mailto:jason at purplecomm.com] 
> Sent: Wednesday, November 17, 2004 4:36 AM
> To: resiprocate
> Subject: [reSIProcate] dum changes to Invite Sessions
> 
> Rohan, Ken and I spent about 6 hours working on the InviteSession state 
> machines. The goals were the following:
> 
> - get PRACK and UPDATE working
> - improve the API for invite sessions
> - properly define the behavior for UAC and UAS in all cases
> 
> I will be checking in some state diagrams in sip/resiprocate/doc that 
> summarize the findings from the design session. We will be coding a new 
> version of the InviteSessions as well.
> 
> Some conclusions that we made:
> 
> - offer/answer state machine should not be separate from signaling
> - need to handle PRACK and UPDATE in the same state machine
> - separate state machine for UAC and UAS
> - one mechanism for adorning sip messages
>    (use InviteSessionHandler::onReadyToSend only)
> - send methods go away
> - provideOffer/provideAnswer will potentially result in signaling, may
>    also just queue a response to be sent later.
> 
> Proposed changes to api:
> 
> class ClientInviteSession
> {
>    public:
>      void end();
> 
>      virtual void provideOffer(const SdpContents* offer);
>      virtual void provideAnswer(const SdpContents* answer);
> };
> 
> class ServerInviteSession
> {
>    public:
>      void reject(int code);
>      void accept(int code=200);
>      void provisional(int code);
>      void end();
> 
>      virtual void provideOffer(const SdpContents* offer);
>      virtual void provideAnswer(const SdpContents* answer);
> };
> 
> class InviteSession
> {
>    public:
>      // rejects current INVITE or reINVITE. May assert if accept
>      // doesn't make sense in this state.
>      virtual void reject(int code);
> 
>      // accept the current INVITE or reINVITE. May assert if accept
>      // doesn't make sense in this state.
>      virtual void accept(int code=200);
> 
>      // if 100rel is supported or depending on the state, these may
>      // result in signaling immediately. Otherwise, queue for when
>      // necessary. May assert if no offer/answer is permissible in this
>      // state.
>      virtual void provideOffer(const SdpContents* offer);
>      virtual void provideAnswer(const SdpContents* answer);
> 
>      // request a target refresh.
>      void targetRefresh(const NameAddr& localUri);
> 
>      void sendInfo(std::auto_ptr<Contents> body);
>      void sendRefer(const NameAddr& referTo);
>      void sendRefer(const NameAddr& referTo,InviteSessionHandle replace);
> };
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel