Re: [reSIProcate] dum changes to Invite Sessions

[david Butcher <david@xxxxxxxxxxxxxx>]

Quoting Jason Fischl <jason@xxxxxxxxxxxxxx>:

[snip]
> 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

I prefer not exposing the send method. I propose that the adorn functionality is
provided as immediate callbacks.

virtual void provisionalAdorn(SipMessage& msg) {}
virtual void rejectAdort(SipMessage& msg) {}
virtual void acceptAdorn(SipMessage& msg) {}

If the app wants, it can override the adorn method(s). The send is called from
dum like this: 

handler->provisionalAdorn(msg);
send(msg);

This is a synchrounous interface; the application can marshall whatever state it
needed in the adorn at the time of the provisional/reject/accept call.

david