Subject: [Sipping] olson-sipping-refer-extensions tail wagging the dog?

From: Cullen Jennings <[email-masked]>
Date: Sun, 09 Nov 2003 21:38:31 -0800

Mostly like this stuff but one thing I think *might* cause some problems...

Signaling (such as the phone sending a 200) is an artifact of something that
happened on the phone - such as it got answered. By telling the phone to do
the artifact, the phone might have to guess what the root cause operation to
cause that artifact is.

For example, my phone might send a 200 in two different cases. One is where
it some goes hits the speaker phone button when it is ringing. The other is
when it has rung for 10 seconds and it answers, plays a prompt and records a
message and emails it to me. If the phone gets a refer telling it to send a
200 to some ringing call - the phone will need to guess if it should go off
hook in speaker phone mode or use voice mail mode. I know this is a somewhat
contrived example but I think you get the idea that refer is using a
signaling artifact to request a basic operation and that might lead to
ambiguous cases. I see the 200 as the tail and the speaker phone button as
the dog.

Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Nov 2003 10:31:39 -0500

Cullen,

I agree with you. This isn't just restricted to referring responses. 
There is a general issue that the semantics of REFER are underspecified.

- when I send a REFER of an INVITE *in* an existing call dialog,
   I believe there is an assumption in the published call flows
   that the resulting new call will supercede the old one, taking
   over the media resources of that call. But AFAIK that assumption
   isn't written down, much less normative.

- when a REFER is sent to a phone, independently of any existing dialog,
   a lot of different things could happen, similar to what you mention
   blow for sending a 200:
   . the phone could alert, await acceptance by a local user,
     and then send the INVITE;
   . the phone could alert the local user and send the INVITE in
     parallel. If the Refer-To user answers first, that call could
     then hear ringback until the local user answers;
   . a speakerphone could be enabled, and then the INVITE sent;
   . ...
   It is hard to know how the feature can be used without knowing
   something of the semantics it will yield.

- there have been proposals for more exotic REFER uses, such as
   REFER of a GET method with an http url. While one can imagine some
   plausible semantics for this, it is again in general difficult to
   imagine how to use this capability without additional normative
   behavior.

So, I think there is a general issue of the semantics of REFER that 
needs to be beefed up.

	Paul

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 10 Nov 2003 08:37:48 -0800

I can see the potential for ambiguity here. Is it time to update the REFER
RFC with tighter semantics? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Monday, November 10, 2003 7:32 AM
To: Cullen Jennings
Cc: sipping
Subject: Re: [Sipping] olson-sipping-refer-extensions tail wagging the dog?

Cullen,

So, I think there is a general issue of the semantics of REFER that needs to
be beefed up.

	Paul

Cullen Jennings wrote:
> Signaling (such as the phone sending a 200) is an artifact of 
> something that happened on the phone - such as it got answered. By 
> telling the phone to do the artifact, the phone might have to guess 
> what the root cause operation to cause that artifact is.
> 
> For example, my phone might send a 200 in two different cases. One is 
> where it some goes hits the speaker phone button when it is ringing. 
> The other is when it has rung for 10 seconds and it answers, plays a 
> prompt and records a message and emails it to me. If the phone gets a 
> refer telling it to send a 200 to some ringing call - the phone will 
> need to guess if it should go off hook in speaker phone mode or use 
> voice mail mode. I know this is a somewhat contrived example but I 
> think you get the idea that refer is using a signaling artifact to 
> request a basic operation and that might lead to ambiguous cases. I 
> see the 200 as the tail and the speaker phone button as the dog.
> 
> Cullen
> 
> 
> 
> 
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Nov 2003 08:59:09 -0800

I'm presenting on Wednesday in SIP on the semantics of REFER.  I'm 
going to discuss several different possibilities semantically and make 
my own proposal/recommendation.  Feel free to pitch in some 
ideas/concerns for the slides.

thanks,
-rohan

On Monday, November 10, 2003, at 07:31 AM, Paul Kyzivat wrote:

>> something that
>> where