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

["Francois Audet" <[e-mail]>]

In the case where the far end actually sent a 486, it makes sense.

In the case where the far end did NOT send a 486, i.e., that forwards
the
call itself with a 302, it seems highly dubious to me to insert a
"fake" 486 inside a Reason header.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: Monday, October 17, 2005 16:20
> 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 Audet wrote:
> > You mean adding a Reason of 486 inside 302????
> > 
> > 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
> 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[e-mail]]
> >>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:[e-mail]]
> >>>>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
> >>>[e-mail] for questions on current sip Use 
> >>>[e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP