Subject: [Sip] REFER request with method parameter != INVITE in refer-to header

From: Ofra Wachsman <[email-masked]>
Date: Thu, 25 Sep 2003 14:02:28 +0300

Hi
I have some questions about Refer-To header with method=SUBSCIRBE or
method=REFER in it's URI. (rfc 3515)
1. When receiving REFER request with method=SUBSCIRBE, a new subscription
should be created. how do I know what is the event of this subscription?
same problem for method=REFER, how do I know the Refer-To header for the new
REFER?
Is there a draft defining such behavior?

2. If I created this subscription, what are the states of the new
subscription, that we should notify the referrer of? only receiving
responses? what about receiving notifications (if so, what will be the
status code in the body status line?)?
 
Ofra

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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 26 Sep 2003 09:04:29 -0500

> Is there a draft defining such behavior?
These can be defined using the URI "?" header escaping mechanism:

Some examples (which may not be completely escaped correctly, but
they show the spirit of the thing:)

Refer-To: sip:rjs-presence@example;method=SUBSCRIBE?Event=presence

Refer-To:
sip:rjs-refer@example;method=REFER?Refer-To=<sip:target's-target>

> status code in the body status line?)?

The REFER creates an implicit subscription to the status of the 
referrenced request and that only. So, if the REFER is to a
SUBSCRIBE, you will get notification about the success or 
failure of that SUBSCRIBE transaction, but not information
about any future NOTIFYs due to that SUBSCRIBE.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Sep 2003 11:32:12 -0400

This may be a bit off-topic, so I have changed the subject.

>>method=REFER in it's URI. (rfc 3515)

One thing troubles me about REFER, and my degree of discomfort goes up 
when is is applied in these more complex ways. The issue is how the 
referee is able to discern the implications of what is being asked to do 
- what corellary actions it should perform.

For instance, in this case I might be able to tell someone else to 
subscribe to presence. But what should it do with the information when 
it is received? I don't have any good way to tell it what I intend for 
it to do, so by implication it must be presumed to be able to figure it 
out on its own, either because there is one single thing it does with 
such information, or because it can figure it out from context, such as 
based on who is asking.

This is potentially a problem even for referring an INVITE, but it is at 
least tempting to believe that a given UA has only a few alternatives 
for what can do, that can be figured out from context. E.g., when a 
refer of invite is sent in an existing dialog where an invite is active, 
I believe there is an assumption that the receiving UA will reassign the 
local media resources so that they are connected to the new call rather 
than the old call. Many call flows assume this, but AFAIK there is no 
standard that says this.

For other uses of refer I find it harder to convince myself that the 
recipient can infer the appropriate actions to take.

This seems likely to lead to proprietary systems that can't 
interoperate, because they depend on remote devices that make particular 
assumptions about this.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Fri, 26 Sep 2003 17:11:20 -0700 (PDT)

I agree that this can become complex. I don't agree
that this is an interoperability problem. The
complexity comes from attempting to solve more complex
scenarios. And therefore I think the complexity is
justified.  I certainly believe that these type of
problems deserve attention and where it makes sense,
standardization.

> > they show the spirit of the thing:)
sip:rjs-presence@example;method=SUBSCRIBE?Event=presence
> > Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com