RE: [reSIProcate] rejecting an info when in connected, which InviteSession to use?
Well, I did end up finding a scenario that will cause problems, specifically
on a re-INVITE.
Why does ServerInviteSession::reject() default to "assert(0)" instead of
passing the reject command to the base class? In my scenario I would be
rejecting a re-INVITE for a previously connected ServerInviteSession.
ClientInviteSession::reject() defaults to the base class implementation.
Thanks,
-Justin
-----Original Message-----
From: Justin Matthews [mailto:justin.matthews@xxxxxxx]
Sent: Thursday, March 24, 2005 3:29 PM
To: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate] rejecting an info when in connected,which
InviteSession to use?
Ok, so I just found the acceptInfo() and rejectInfo() functions. For now I
should be all set. Hopefully the scenario I described does not come up and
my implementation will work.
Thanks,
-Justin
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin
Matthews
Sent: Thursday, March 24, 2005 2:59 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] rejecting an info when in connected,which
InviteSession to use?
Hello,
If I have a session connected, either UAS (ServerInviteSession) or UAC
(ClientInviteSession) and I receive an INFO request and want to reject it,
it looks like I should be using the InviteSession type when calling
reject(). The problem I have is that I want to select (cast from
DialogUsageManager::getHandled()) either a ServerInviteSession or
ClientInviteSession and always use those derived classes. This is because I
exit from my InviteSessionHandler and pass the event to another subsystem.
When that subsystem processes the event (example: it wants to reject an INFO
request) I don't want to have to figure out if I need to cast to
InviteSession for a particular request (if the original onNewSession() was a
ClientInviteSession, then I want to store that and use it for all future
processing). How are other people handling this if they pass the logic of
handling events in their InviteSessionHandler to another subsystem and
return later to execute the appropriate command (accept(), reject(),
provideOffer...)? I could pass a token to the my subsystem that identifies
the event, so that when the subsystem returns with a response I could cast
to the appropriate InviteSession. Is there a better way?
Thanks,
-Justin
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel