[reSIProcate] Re: InviteSession spec questions
On Nov 8, 2004, at 20:01, Rohan Mahy wrote:
Hey,
On Nov 8, 2004, at 19:50, Jason Fischl wrote:
Hi Robert and Rohan,
Derek and I have a few questions that shouldn't take you too long but
we are a bit blocked on these issues right now.
Is it valid to send a provisional response (1xx) to a reINVITE?
no
make that yes
If so, what would this mean?
the UAS wants to prompt the user regarding the change. although this
is not well motivated in 3261.
If 1xx to reINVITE is allowed, does this mean the UAC would ever want
to send a CANCEL to a reINVITE?
yuck. i don't think we should encourage this behavior. i do not
support adding a facility in our stack to generate a 1xx to reINVITE
nor a CANCEL to a reINVITE.
What should dum do if acting as a UAC it reINVITEs, doesn't get a
response (other than 100) and the application asks to end the invite
session. My take is that it should create a timer (64 x T1), wait for
the response to the reINVITE or the timer to fire (whichever comes
first) and send BYE.
no need to wait. you only need to wait if you want to change the
session description and you already have an offer or answer exchange
in progress.
Does the application need a way to end specific ClientInviteSessions
that are in the early state? Consider an INVITE that forked and
created two ClientInviteSessions with 1xx. The application can send a
CANCEL which will end both usages. If we provide an end interface on
the specific usage, should it send a BYE on the early dialog?
Otherwise, what will it mean to end a specific early dialog?
It seems useful, but I can't think of a specific application that does
this. Perhaps this is just an audio specific view, and that video or
text clients would be much more likely to have a UI where you might
cancel specific early dialogs.
I am proposing that a usage NOT be created when a 100 is received.
The usage(s) would be created after 1xx or 2xx is received. If a
CANCEL is sent and no 487 is received, who should be responsible for
cleaning up the ClientInviteSessions in the early state?
I think you can actually put the client state machine in terminated
even if you don't get the 487. The "preterminated" state may need to
run a timer to wait for incoming messages, but I think you are in
pretty good shape here.
Presumably, the DialogSet could create a timer and clean up any
remaining usages. How long should this timer be?
32 secs?
thanks,
-rohan