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

RE: [reSIProcate] ServerInviteSession::accept() vs re-INVITE


The code is doing what was intended - the comments should be fixed, as you
have suggested - I'll update these.

Whether the intended design is the best or not, is another issue.  :)  The
idea is that the application doesn't need to take time to response to a
re-invite (ie. There is no device to ring) and should be immediately be
accepting the request anyway.  Thus there is no handler called to indicate
that you received the re-invite (other that onOffer), and thus no need to
call accept().  Perhaps a misleading point here - is that even though
accept() is not required, calling reject() is valid, if you don't like the
SDP in the re-invite offer.

Thanks for pointing out the misleading comments!

Scott


-----Original Message-----
From: Dmitry Semyonov [mailto:dsemyonov@xxxxxxx] 
Sent: Friday, June 10, 2005 9:29 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] ServerInviteSession::accept() vs re-INVITE

On Fri, 10 Jun 2005, Dmitry Semyonov wrote:

> There is the following comment inside ServerInviteSession class:
> 
> /** accept a re-invite, etc.  Always 200? this is only applicable to the
UAS */
> virtual void accept(int statusCode=200);
> 
> But it seems accept() must not be called for re-invites. (At least 
> after provideAnswer()). Otherwise DUM (debug) will assert inside 
> the function due to unhandled mState == Connected. It seems 
> provideAnswer() alone is enough.
> 
> If my understanding is correct, could somebody update the misleading 
> comment? TIA

At the same time accept() is required for incoming calls after 
provideAnswer(). This is totally inconsistent! One more misleading 
comment:

/** Called to set the answer that will be used in the next messages that
    sends an offer. Does not send an answer */
                    ~~~~~~~~~~~~~
virtual void provideAnswer(const SdpContents& answer);

But it _sends_ in case of re-INVITE!

So, probably the code should be updated to match the comments instead.

-- 
...Bye..Dmitry.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel