[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] draft-audet-sipping-feature-ref-00: What a REFER can and can not do



No, I didn't say this: I said you couldn't use it today for Answereing a call
and for other features listed in the draft.

REFER is already capable of doing many useful things.

You CAN use REFER to:

- REFER to a SIP or Tel URI without refering to an existing dialog 
  (which will by default mean INVITE should be sent). This is a "Make Call" feature.

- REFER to a SIP or Tel URI with a method=blabla without
  referring to an existing dialog. For example, SUBSCRIBE, REFER, REGISTER, whatever.

- You can use REFER to a sip or Tel URI refering to an exising dialog (meaning by
  default INVITE). This can be use for many things including transfer, conferencing,
  music on hold, etc).

- You can use REFER to a SIP or Tel URI with a method=blabla referring to an
  existing dialog. For example BYE, CANCEL, etc. This could be use for "terminate"
  call for example. This was discussed in draft-mahy-sip-remote-cc-05.

- You can use REFER to push a Web Page by using a http URI (see Application 
  Interaction framework). This is highly synergistic with this spec actually and doing
  something different thant REFER would be detrimental to the community.

- You can use REFER to send somebody to email with mailto URI.

- In fact, the spec allows you to use any damned type of URI you want. h323:, whatever.
  So, I ask the question, why not urn:???????

However, REFER does NOT allow to:

- Send REFER to point to a response instead of method. Our previous 
  draft-mahy-remote-cc-05 wanted to add this.

- Send REFER to point to things that don't have a corresponding method or response
  to render it.
  

Now, on your suggestion below:

- What you are suggesting below is exactly what draft-mahy-remote-cc-05 did. And it
  was rejected. In fact there are some significant disadvantages with this method. It
  requires the Application to know way too much about the remote controlled device for
  it to be practical, and for the remote control to overly trust the application, and
  might therefore be coaxed into performing unatural acts (like, error responses it
  doesn't even understand for example). It also required an unsustainable amount of 
  state synchronization.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com] 
> Sent: Tuesday, March 11, 2008 04:07
> To: Audet, Francois (SC100:3055)
> Cc: sipping
> Subject: draft-audet-sipping-feature-ref-00: What a REFER can 
> and can not do
> 
> Hi,
>  
> The draft claims that certain things can't be done with 
> REFER, and at the meeting Francois also said that REFER can 
> only be used to "trigger establishment of a call".
>  
> Bit, if I remember previous discsussions on the list 
> correctly, you can include a method parameter in the Refer-To 
> SIP-URI to trigger non-INVITE requests, e.g. BYE to trigger a 
> disconnect, UPDATE to trigger a hold (in addition you will 
> have to include some SDP attributes, e.g. using sipfrag), and 
> maybe even REFER to trigger a transfer.
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
>  
>  
> 
> ________________________________
> 
> Lähettäjä: sipping-bounces at ietf.org puolesta: Francois Audet
> Lähetetty: ma 10.3.2008 15:31
> Vastaanottaja: Adam Roach
> Kopio: Cullen Jennings; Rohan Mahy; sipping
> Aihe: Re: [Sipping] I-D Action:draft-audet-sipping-feature-ref-00.txt
> 
> 
> 
> No it's not in there.
> 
> No matter how often I read and re-read MBUS, I can't figure 
> out anything that even comes close to be relevant to the topic...
> 
> > -----Original Message-----
> > From: Adam Roach [mailto:adam at nostrum.com]
> > Sent: Monday, March 10, 2008 07:27
> > To: Audet, Francois (SC100:3055)
> > Cc: Alan Johnston; Rohan Mahy; Cullen Jennings; sipping
> > Subject: Re: [Sipping] I-D
> > Action:draft-audet-sipping-feature-ref-00.txt
> >
> > On 3/10/08 10:23 AM, Francois Audet wrote:
> > > Yes, it is making the observation that MBUS is unsuitable.
> > >  
> >
> > And that's fine, but it needs to be both explicit and motivated, 
> > instead of merely implied.
> >
> > Or did I miss that section?
> >
> > /a
> >
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use sip-implementors at cs.columbia.edu for questions on current 
> sip Use sip at ietf.org for new developments of core SIP
> 
> 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP