Subject: [Sip] redirect token in caller preferences extension?

From: Marcin Dzieweczynski <[email-masked]>
Date: Tue, 04 Nov 2003 00:29:47 +0100

Hello

I try to implement caller preferences extension in already existing software (which is "ser" and Kphone). I'm not quite sure how UAC should apply "redirect" token. As I see it, when UAC is satisfied with redirection it should remove this token from the following INVITES otherwise it would be redirected forever. Is my thinking correct?

regards

Marcin Dzieweczynski

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Nov 2003 00:29:15 -0500

Marcin Dzieweczynski wrote:

> Hello
> 
> I try to implement caller preferences extension in already existing
> software (which is "ser" and Kphone). I'm not quite sure how UAC
> should apply "redirect" token. As I see it, when UAC is satisfied
> with redirection it should remove this token from the following
> INVITES otherwise it would be redirected forever. Is my thinking
> correct?

Actually, I think the spec is merely ambiguous on this point.

What is supposed to happen is that you get continually redirected to 
new URIs until you reach the UAS. The UAS itself would answer or 
reject the call (it could also redirect of course). Thus, the call 
should still work even if the UAC never removes the redirect token. 
However, the spec says that UAS behavior should be as if it were a 
proxy. This makes sense for the feature preferences, but not for the 
request handling preferences. The spec needs to be clarified that it 
applies to feature preferences and the queue request handling 
directive only. I'll make sure it gets clarified.

Of course, its also reasonable for a UAC to purposefully use the 
redirect preference once, and then remove it later. It depends on the 
specific feature that is being implemented.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2003 10:04:40 -0500

Marcin,

In retrospect I will agree with Jonathan that it might be useful to 
clarify this further. I guess this is justified by the fact that you 
asked the question.

But it always seemed obvious to me that it should work as Jonathan 
describes. Fundamentally, inserting the "redirect" request-disposition 
is a way for the UAC to say "I want to make all the decisions about 
which alternatives get tried."

If that was confusing, what about other cases? Is it clear that a proxy 
should ignore this option when it is acting on a Route header?

	Paul

Jonathan Rosenberg wrote:
> What is supposed to happen is that you get continually redirected to new 
> URIs until you reach the UAS. The UAS itself would answer or reject the 
> call (it could also redirect of course). Thus, the call should still 
> work even if the UAC never removes the redirect token. However, the spec 
> says that UAS behavior should be as if it were a proxy. This makes sense 
> for the feature preferences, but not for the request handling 
> preferences. The spec needs to be clarified that it applies to feature 
> preferences and the queue request handling directive only. I'll make 
> sure it gets clarified.
>