Subject: [Sipping] Redirection by a UAS

From: "Elwell, John" <[email-masked]>
Date: Thu, 01 Apr 2004 16:24:00 +0100

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 authorised, 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?

John Elwell ([email-masked])

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 1 Apr 2004 19:36:52 -0500

> 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 
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Michael Hammer <[email-masked]>
Date: Fri, 02 Apr 2004 14:26:21 -0500

>   call-forward-busy, and call-forward-no-answer.

Would it be possible to include a last resort Contact that refers back to 
itself, but in such a way that the local part has a convention that 
indicates that the forwarding failed?

Mike

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 2 Apr 2004 15:35:44 -0500

> > > Would it be possible to include a last resort
> > > Contact that refers back to itself, but in such
> > > a way that the local part has a convention that
> >Yes, if both parties agree upon a solution.
> 
> Why both?  The contact is provided by the 
> called party.  The calling party simply uses 
> the contact.  Only the called party needs to know 
> what the convention means.  Did I miss something?

Trying the contact entry with the highest q value
is relatively obvious; however if I recall correctly,
rfc3261 does not even make choosing the highest 
q value a MUST.  The relationship between this 
contact entry and other contact entries are
currently not obvious or well standardized.

Some vendors simultaneous-ring if the q values 
are the same; other vendors do not.

Some vendors advance contact entries upon
any 4xx-6xx response; others do not.  Some 
vendors only advance if no response is received.

There is currently no defined parameter within
a contact entry which can communicate a no-answer
timer indicating the desire to advance to the 
next contact.  However I assume that some vendors
have toyed with trying to use the expires parameter
for this purpose.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 2 Apr 2004 14:55:19 -0500

Many vendors have either chosen to implement
a b2bua or proxy to resolve the issue.  Others
have implemented 3xx proprietary solutions.  

I am not aware on anyone having tried to
standardize a 3xx solution.  The main reason
is because it typically isn't the best solution
for complex services.  However it definitely 
would be beneficial for basic services.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 02 Apr 2004 14:55:03 -0500

>Yes, if both parties agree upon a solution.

Why both?  The contact is provided by the called party.  The calling party 
simply uses the contact.  Only the called party needs to know what the 
convention means.  Did I miss something?

Mike