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

[Paul Kyzivat <[e-mail]>]

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