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