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

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

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

That seems highly confusing to me.

> -----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