Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

From: "Francois Audet" <[email-masked]>
Date: Mon, 17 Oct 2005 17:47:15 -0500

You mean adding a Reason of 486 inside 302????

That seems highly confusing to me.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, October 17, 2005 11:14
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: Michael Hammer (mhammer); sipping; Elwell, John
> Subject: Re: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> Francois,
> 
> Mike can correct me if I am wrong, but I think the two of you are 
> talking past one another. My understanding was that Mike was 
> proposing 
> that the 302 be returned with a Reason:486 in it. In that case, it 
> appears that the H-I should be populated with the 486 rather 
> than the 302.
> 
> 	Paul
> 
> Francois Audet wrote:
> > If an SBC stips out URI parameters, it will certainly cause 
> breakage. 
> > I think SBC vendors understand this.
> > 
> > SBC vendors however are likely to consider History-Info 
> removal to be 
> > a "feature" similar to topology hiding...
> > 
> > --
> > 
> > On the 486 thing...
> > 
> > Many gateways and SIP phones implement Call Forwarding Busy locally
> > using 302. This means it doesn't rely on a proxy for the forwarding
> > logic.
> > 
> > I have seen implementations using 486 with a Contact. However, there
> > is no garantee that the other side will recurse in this case (which 
> > is why most people use 302).
> > 
> > 
> >>-----Original Message-----
> >>From: Michael Hammer (mhammer) [mailto:[email-masked]]
> >>Sent: Monday, October 17, 2005 10:46
> >>To: Audet, Francois [SC100:9T51:EXCH]; sipping
> >>Cc: Elwell, John
> >>Subject: RE: [Sipping] Re: 
> >>draft-elwell-sipping-service-retargeting-00.txt
> >>
> >>
> >>With respect to 302 v. 486, there seems to be differences of
> >>opinion about which takes precedence.  You say 302, others 
> >>say 486.  This begs for a BCP.  Seems like the supplied 
> >>Reason header should take precedence. 
> >>
> >>Correction, I should have said first non-3xx entry to get the
> >>voicemail behavior you describe.
> >>
> >>Below, I am not talking about modifying the H-I headers
> >>information at all, just making use of what is present in 
> >>that header, which doesn't seem to be defined.
> >>
> >>And as for what an SBC will muck with or not, anything in the
> >>message is open to manipulation.  I don't know of anything 
> >>that could stop it from stripping parameters it doesn't know about.
> >>
> >>Mike
> > 
> > 
> > _______________________________________________
> > 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: Mon, 17 Oct 2005 19:19:58 -0400

> That seems highly confusing to me.

The following is from draft-ietf-sip-history-info-06:

    4.3.3.1.2 Reason in the History-Info header

    For retargets that are the result of an explicit SIP response, a
    Reason MUST be associated with the hi-targeted-to-uri.  If the SIP
    response does not include a Reason header, the SIP Response Code that
    triggered the retargeting MUST be included as the Reason associated
    with the hi-targeted-to-uri that has been retargeted.  If the
    response contains a non-SIP Reason header (e.g. Q.850), it MUST be
    captured as an additional Reason associated with the hi-targeted-to-
    uri that has been retargeted, along with the SIP Response Code.  If
    the Reason header is a SIP reason, then it MUST be used as the Reason
    associated with the hi-targeted-to-uri rather than the SIP response
    code.

This says that if a 302 response contains a Reason header with a 486, 
then the H-I reason should be set to 486.

This doesn't seem at all confusing to me - the reason the 302 was sent 
was because the target was busy. If you care about reasons for 
redirection I would think this is a key feature.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Oct 2005 15:01:17 -0500

> That seems highly confusing to me.

That's more or less what I think I proposed, except I buried it in a  
History-Info header field.

One of the things that puzzles me about H-I is that while the RFC  
allows use of H-I in 302 responses, it doesn't talk about it in any  
great detail.

It would be very nice to have an H-I use-cases draft with some good  
examples.

--
Dean