[reSIProcate] Re: InviteSession spec questions
On Nov 8, 2004, at 6:50 PM, 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? If so,
what would this mean? If 1xx to reINVITE is allowed, does this mean
the UAC would ever want to send a CANCEL to a reINVITE?
Valid - but not particularly meaningful for xx>00, but it would be
legal for a UA to send an answer in, say, a 183 to a reinvite (esp if
it
supported 100rel).
Per spec UA can ask its user if it wants to accept being put on hold or
to add video perhaps - the user can decline. Thus, CANCEL could
make sense.
Now - I don't think this is something we need to provide to a DUM user.
If somebody wants to do this, they can go deeper into the stack.
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.
if the app wants out, why are you not sending the BYE right away? (May
be being stupid here - paying most attention to the ongoing
XCON meeting).
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?
Yes - 3261 talks about tearing down one early dialog without canceling
the entire request. BYE is what it says to use.
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.
That's correct. A 100 comes from the next _transaction_ stateful thing,
not the thing that knows about usages.
If a CANCEL is sent and no 487 is received, who should be responsible
for cleaning up the ClientInviteSessions in the early state?
Presumably, the DialogSet could create a timer and clean up any
remaining usages. How long should this timer be?
3261 talks explicitly about that for 2543 backwards compatibility -
64T1 IIRC.
RjS