Re: [splices] SIP INVOKE method

["Parthasarathi R (partr)" <[e-mail]>]

Rifaat,

SUBSCRIBE creates the dialog and within the created subscribe based dialog, INVOKE method (transaction) is sent from subscriber to perform the specific action based on the mentioned URN. Please correct me in case I misunderstand your proposal.

Please read inline

Thanks
Partha

-----Original Message-----
From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[e-mail]] 
Sent: Wednesday, May 18, 2011 5:07 PM
To: Parthasarathi R (partr); [e-mail]
Subject: RE: [splices] SIP INVOKE method

Inline...

> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[e-mail]]
> Sent: Tuesday, May 17, 2011 2:57 PM
> To: Shekh-Yusef, Rifaat (Rifaat); [e-mail]
> Subject: RE: [splices] SIP INVOKE method
> 
> Rifaat,
> 
> I skimmed through your draft. I like the idea of controlling remote UA 
> action using new method (INVOKE). Few comments in the draft:
> 
> 1) Sec 4.1: SUBSCRIBE with expire=0 is used to terminate INVOKE dialog 
> by INVOKE-Issuer. Whether it is ok to "INVOKE with expire=0" terminate 
> INVOKE dialog as it avoids the dependency on SUBSCRIBE message to terminate.
> 
The new plan is to remove the implicit subscription.

<Partha> How is it possible for INVOKE-Issuer to abort or stop the action in case required? </Partha> 


> 2) I foresee the complexity in creating explicit subscription because 
> two dialog creation methods (INVOKE & SUBSCRIBE) are used to make the 
> single action. It will be good in case INVOKE acts similar to INVITE 
> (Dialog creation & Action). INVITE has the implicit action like "ring 
> the phone" or "auto- answer" whereas INVOKE has explicitly mention the 
> action to be done in INVOKE- recipient.
> 
I am not sure that I understand your comment, but with the new plan the INVOKE will NOT create a dialog.


> 3) Do you foresee INVOKE dialog creation which change the action 
> within INVOKE dialog. For example: Following three actions using 
> single INVOKE dialog creation but updating the action based on the application information..
> 
>      Action 1:  Create the call
>      Action 2:  Hold the call
>      Action 3:  Terminate the call
> 
In this case, I expect the INVOKE-Issuer to first create a subscription and then to send the INVOKE requests in the context of that dialog.

<Partha>
In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then whether multiple simultaneous INVOKE operation is allowed or not. Example
              1) INVOKE hold action
              2) Even before INVOKE hold completion NOTIFY receives, INVOKE terminate call action

</Partha>

> Thanks
> Partha
> 
> ________________________________________
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Shekh-Yusef, Rifaat (Rifaat)
> Sent: Tuesday, May 17, 2011 10:57 PM
> To: Shekh-Yusef, Rifaat (Rifaat); [e-mail]
> Subject: Re: [splices] SIP INVOKE method Thank you all for your quick 
> review and feedback so far.
> I will work on a new version of the draft that removes the implicit 
> subscription.
> 
> Please, let me know if you have any other comments beside the implicit 
> subscription issue.
> 
> Regards,
> Rifaat
> 
> 
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Shekh-Yusef, Rifaat (Rifaat)
> Sent: Tuesday, May 17, 2011 9:15 AM
> To: [e-mail]
> Subject: [splices] SIP INVOKE method
> 
> Hi,
> 
> As discussed in the last SPLICES WG meeting in Prague, the REFER 
> method is overloaded and has limitations that prevents it from being 
> the ideal method for action invocation.
> We have worked on the following new draft that defines a new SIP 
> method to be used for invoking actions:
> https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/
> 
> We would appreciate it if people review the document and provide us 
> with their feedback.
> 
> Regards,
> Rifaat
> 
> 
> 
> 
>