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

["Francois Audet" <audet at nortel.com>]

As John was saying, another draft is on the way.

No use discussing the old one.

> -----Original Message-----
> From: sipping-bounces at ietf.org 
> [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
> Sent: Thursday, September 29, 2005 06:27
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: r.jesske at t-com.net; sipping; joanne at avaya.com; 
> Elwell,John; Gonzalo Camarillo
> Subject: Re: [Sipping] Re:Comments 
> ondraft-elwell-sipping-redirection-reason-02.txt
> 
> 
> 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
> 
> GARCIN Sebastien RD-CORE-ISS wrote:
> > Hi,
> > 
> > Call Forwarding unconditionnal is one example (with an AS 
> intercepting 
> > the INVITE).
> > 
> > sébastien
> > 
> > -----Message d'origine-----
> > De : sipping-bounces at ietf.org 
> [mailto:sipping-bounces at ietf.org] De la 
> > part de Gonzalo Camarillo Envoyé : jeudi 29 septembre 2005 
> 10:14 À : 
> > Elwell, John Cc : r.jesske at t-com.net; joanne at avaya.com; 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 
> > 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://www1.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://www1.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://www1.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