Subject: RE: [Sipping] Redirection on busy and History Info

From: "Mary Barnes" <[email-masked]>
Date: Mon, 31 Oct 2005 10:38:52 -0600

John, 

Yes, this is slightly different behavior than currently specified,
because this is going against the SHOULD as to what a redirect server
(or UAS acting as a virtual proxy per Gonzalo's example) should do. I
believe this is why Francois was considering this alternative to be a
hack.  I don't think it introduces particularly complex or ugly
behavior.  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. 

Mary

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, October 31, 2005 10:04 AM
To: Barnes, Mary [NGC:B601:EXCH]; Gonzalo Camarillo; sipping
Subject: RE: [Sipping] Redirection on busy and History Info

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

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Oct 2005 20:58:11 +0200

Hi,

 > Of course,  I think the primary debate isn't necessarily over

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