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

From: "Mary Barnes" <[email-masked]>
Date: Mon, 31 Oct 2005 07:26:43 -0600

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] 

John

_______________________________________________
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

_______________________________________________
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 16:25:55 +0200

Hi,

I would like folks to state whether or not this type of solution would 
meet the requirements of the services they have in mind...

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo