RE: Redirection by a UAS

> SIP allows a UAS to reject an INVITE request 
> with a 3xx response. A particular application 
> of this is to achieve call forwarding no reply 
> or deflection. With forwarding no reply the 
> 3xx response is issued in accordance with a 
> script in the UA after alerting the user for 
> a certain time. With deflection the 3xx 
> response is issued as a direct result of user 
> action in response to alerting.
>
> A problem arises if the request cannot 
> successfully be redirected in accordance with 
> the contact URI in the 3xx response. Reasons 
> could include, but are not limited to, the 
> following: URI not found, not authorized, busy. 
> The question is, how to notify the redirecting 
> UAS that the request has failed. In the case of 
> forwarding no reply, it might be desirable to 
> continue alerting the user at that UAS until 
> it can be determined that forwarding is 
> successful (e.g., when another UAS begins 
> alerting). In the case of deflection it might 
> be useful to inform the user that deflection 
> was unsuccessful and give the user another 
> opportunity to answer the call.
>
> The only way of achieving this at present is 
> for the proxy that retargets the request as 
> a result of the 3xx response to repeat the 
> request to the original contact on detecting 
> failure of the retargeted request. This is not 
> entirely satisfactory because it does not 
> explicitly indicate the reason for repeating 
> the request and it may have undesirable impact 
> on call detail recording / missed call logging 
> at the UAS.
>
> Does anyone else see this as a problem and is 
> anyone aware of alternative solutions? 

solution 1: 
  Instead of sending a 3xx, it could act as a
  transaction-stateful-proxy and proxy the
  INVITE to the forwarded-to party.

solution 2:
  Go through the standards process to define
  a mechanism that allows service policies and 
  relationships to be clearly communicated
  within a 3xx that contains multiple Contact 
  entries.  Using the Contact's q values helps
  with fault tolerance; however more information
  is needed to clearly communicate other common 
  services like simultaneous-ringing,
  call-forward-busy, and call-forward-no-answer.

_______________________________________________
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