[reSIProcate] Re: InviteSession spec questions

[Rohan Mahy]

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