reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] dum changes to Invite Sessions

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@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