RE: [reSIProcate] ClientInviteSession::end() questions
The case where end() is called before onProvisional is called should be
handled by a BYE being sent once a provisional response is received; CANCEL
can't be used, as cancel will destroy the DialogSet.
A DialogSet should be destroyed when the last active dialog is destroyed,
but only if 64T1 has passed since the the request that created the DialogSet
was sent.
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Godin
Sent: Monday, January 17, 2005 6:36 AM
To: 'Jay Hogg'; reSIProcate List
Subject: RE: [reSIProcate] ClientInviteSession::end() questions
" Question: It appears that the presumption is that if a DialogSet only
has 1 dialog active then the DialogSet should be destroyed when the
dialog is destroyed. "
You are right, and I agree that this behavior limits flexibility. I've been
working on making changes to the way this works in the teltel DUM branch
(soon be merged into the main branch). I (and others) think that an
AppDialogSet -> DialogSet end() function would be appropriate. It would
either cancel the Invite if no final responses have been received yet or
send a BYE request to dialogs appropriately.
To handle the scenario you are talking about - I think that calling end() on
a particular InviteSession/Dialog should not terminate the dialogset. If
the app is indeed not interested in the dialogset anymore (ie. Not
interested in the possibility of more responses from a forked request) -
then it would call (App)DialogSet->end.
I'll discuss this with Jason/Derek.
The "bug" you mention should be cleared up, when this branched is merged
back in as the Invite state machine has been completely redesigned.
-----Original Message-----
From: Jay Hogg [mailto:jay@xxxxxxxxxxxxxx]
Sent: Sunday, January 16, 2005 11:57 AM
To: reSIProcate List
Subject: [reSIProcate] ClientInviteSession::end() questions
Developers,
I have a question around the implementation of
ClientInviteSession::end() and usage in a couple of circumstances. I
think I've run into a by-design choice and possibly a bug.
Log not attached at this time - there are a lot of my application log
messages interleaved with resip.
Given a Invite that is sent to a phone.
The phone acknowledges with a 183 and starts ringing.
onNewSession fires
- based on information in the message I decide I do not want this
dialog - end()
- nothing happens - no messages.
onProvisional/onEarlyMedia callbacks fire.
Now if you pickup the phone you get a 200 Ack followed by DUM issueing a
BYE.
The goal was to get the phone to stop ringing with a BYE/CANCEL right then.
The dialog state is Early - ClientInviteSession::end() explicitly
decides there is only 1 dialog active and passes it to DialogSet::end()
which is what is doing "nothing" to the active dialog.
(bug?) It looks like it may be treating it is "Initial" since
onProvisional hasn't fired yet and deferring handling (WaitingToEnd)
until the ACK shows up instead of ReceivedProvisional and cancelling the
dialog immediately.
Question: It appears that the presumption is that if a DialogSet only
has 1 dialog active then the DialogSet should be destroyed when the
dialog is destroyed. This presumtion is correct on a
ServerInviteSession but I'm not sure that it holds on a
ClientInviteSession - there may be other answers coming (forked) after
the first one and I just don't want the first one. The code *supports*
cancelling 2..n in ClientInviteSession::end() but special-cases 1. Is
this "RFC Standard", "Design Choice" or "Just the way it is"? Am I
missing something?
Thanks,
Jay
_______________________________________________
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