RE: [reSIProcate] dum changes to Invite Sessions

[Scott Godin <slgodin@xxxxxxxxxxxx>]

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. : )
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. 

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.

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.  

Thanks!

Scott


-----Original Message-----
From: Jason Fischl [mailto:jason@xxxxxxxxxxxxxx] 
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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel