FW: [reSIProcate] dum changes to Invite Sessions

["Derek MacDonald" <derek@xxxxxxxx>]

I think we should keep the ability to adorn responses; void returns make
sense for provisional/end/provideAnswer/provideOffer but accept & reject
should still return a sip message.

--Derek

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> Sent: Wednesday, November 17, 2004 6:43 AM
> To: 'Jason Fischl'
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] dum changes to Invite Sessions
> 
> 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
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel