[reSIProcate] Re: InviteSession spec questions

[Robert Sparks]

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