Subject: [Sipping] Redirection on busy and History Info

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 30 Oct 2005 11:39:19 +0200

Hi,

this is a strawman on how to encode the redirection reason in a 302 
response using History-Info.

A UAS that needs to send a 302 response because its user is busy could 
act as a virtual proxy and return the following History-Info header 
field in the 302 response:

History-Info: <sip:[email-masked]; index=1,
               <sip:[email-masked]?Reason=SIP;cause=486;\
                  text="Busy Here">;index=1.1

The URI would be the same in both entries because the UAS acts as a 
virtual proxy.

The entity receiving the 302 would generate an INVITE with the following 
History-Info header field:

History-Info: <sip:[email-masked]?Reason=SIP;cause=302;\
                   text="Moved Temporarily">; index=1,
                <sip:[email-masked]?Reason=SIP;cause=486;\
                   text="Busy Here">;index=1.1

Comments?

Gonzalo

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Mon, 31 Oct 2005 16:04:16 +0000

Mary,

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 31 October 2005 13:27
> To: Elwell, John; Gonzalo Camarillo; sipping
> Subject: RE: [Sipping] Redirection on busy and History Info
> 
> Comments embedded below [MB].
> 
> Mary
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Monday, October 31, 2005 3:41 AM
> To: Gonzalo Camarillo; sipping
> Subject: RE: [Sipping] Redirection on busy and History Info
> 
> 
> Gonzalo,
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]] 
> > Sent: 30 October 2005 09:39
> > To: sipping
> > Subject: [Sipping] Redirection on busy and History Info
> > 
> > Hi,
> > 
> [JRE] So presumably, if the UAC (or proxy) does indeed 
> recurse based on
> the
> contents of the Contact URI in the 302 response, then it will 
> generate a
> third H-I entry to represent that? 
> 
> My comments on your proposal would be:
> 
> 1. This is not how UACs / proxies would work at present 
> according to the
> History-Info draft. When building a recursed INVITE request they would
> take
> existing History-Info entries from the original INVITE 
> request, not from
> the
> 3xx response.
> 
> 2. We have two entries with the same URI but different 
> indices, which is
> not
> recognised in the History-Info draft at present but might be harmless.
> 
> [MB] This alternative is very similar to what I had suggested 
> in one of
> the email threads last week.  History-Info doesn't care (nor does it
> violate the spec) that you might have two entries with the 
> same URI.  In
> the thread last week, I mentioned that this results in a 
> unique pattern
> in the H-I entries and the end application can make use of this to
> determine what happened (i.e. you retargeted because the intended
> recipient was busy). 
> [/MB] 
> 
[JRE] But this would require new UAC behaviour (or proxy behaviour, if proxy
does recursion) in order to copy H-I elements from the 3xx into the recursed
request. Was that your intention?

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 31 Oct 2005 18:50:44 -0600

Also, on the "what has happened so far" model, one issue is PSTN
interop.

I always held the view that SIP UAC or proxies should not 
generate "fake" History-Info to account for redirection that
occured outside of SIP (e.g., the PSTN). I.e.., it shouldn't
lie that that there was a 486 or 302 received when there 
were no such thing.

This is one of the main reason for the 3087 model.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Monday, October 31, 2005 10:58
> To: Barnes, Mary [NGC:B601:EXCH]
> Cc: sipping; Elwell, John
> Subject: Re: [Sipping] Redirection on busy and History Info
> 
> 
> Hi,
> 
>  > Of course,  I think the primary debate isn't necessarily over
> > whether one could or could not use History-Info for this type of 
> > service, but rather there is a preference to provide even more 
> > explicit service information, per the RFC 3087 model.
> 
> as Dave pointed out a few messages ago in a related thread, there are 
> two models: one where the entity explains what has happened 
> so far, and 
> the other where the entity tells what should happen in the 
> future. The 
> solution we are discussing here would cover the former model. 
> As long as 
> there are folks interested in that model, I guess it is worthwhile 
> pursuing that solution (or something equivalent).
> 
> Then, as a separate discussion, we can analyze how to support 
> the latter 
> model as well.
> 
> Cheers,
> 
> Gonzalo
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
>