Subject: RE: [Sipping] Re: Comments ondraft-elwell-sipping-redirection-reason-02.txt

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 29 Sep 2005 10:20:58 +0200

Hi,

Call Forwarding unconditionnal is one example (with an AS intercepting the INVITE).

sébastien 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Gonzalo Camarillo
Envoyé : jeudi 29 septembre 2005 10:14
À : Elwell, John
Cc : [email-masked]; [email-masked]; sipping
Objet : [Sipping] Re: Comments ondraft-elwell-sipping-redirection-reason-02.txt

Hi,

> Because that doesn't work when a 3xx is used - 302 does not capture 
> the fact that it was because of busy, say.

You would return a 302 with a History-Info header field with a 486 Busy... the problem with the 302 response has nothing to do with the new namespace. You have the same problem even if you use a new namespace.

> Also not all reasons can be represented by SIP response codes. I am 
> currently writing a new (00) draft along with some other people. This 
> will propose a different mechanism but will still require a new 
> namespace to reflect different service retargeting reasons. Hoping to 
> hit the cut-off date for Vancouver.

Can you provide examples of reasons that cannot be represented by SIP response codes? If they are general reasons, what we need to do is to create new response codes. We probably do not need a new namespace.

Thanks,

Gonzalo

_______________________________________________
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

_______________________________________________
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: Thu, 29 Sep 2005 09:26:50 -0400

The problem I have with all this is that there are a potentially 
infinite number of reasons why a call addressed to one place ends up one 
place or another. (Note that when it is addressed to an AOR, it is in 
general *never* answered by a server at that AOR, but instead is always 
forwarded someplace else.)

Some possible destinations are learned by registration, some (such as 
voicemail) are learned by configuration. Various kinds of call 
forwarding destinations may also be learned by configuration.

This attempt at reason codes seems to be trying to categorize the 
algorithms used to decide where the call is delivered. But those 
algorithms are not standardized in any way, at least in this venue. 
Without a model for how to classify *real* call routing algorithms into 
these categories, the categories are meaningless. I think there is an 
assumption that "everybody will understand how to do this", but I don't 
think that is so.

	Paul