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

From: "Elwell, John" <[email-masked]>
Date: Wed, 02 Nov 2005 08:12:35 +0000

I too feel this is a shaky solution, because the full impact on history-info
would need thinking out, particularly the impact on indices. Does the
additional H-I entry have the same index as the existing one for this URI?
If so, this probably would be confusing to a consumer of H-I. Or does it add
one to the index? If so it is probably in danger of conflicting with another
index already allocated by the proxy for parallel forking. The existing H-I
solution where the retargeting or recursing entity always adds new entries
and assigns indices is relatively simple, but allowing a redirect server to
do this fundamentally changes H-I.

John

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 01 November 2005 18:10
> To: Gonzalo Camarillo
> Cc: Mary Barnes; sipping; Elwell, John
> Subject: RE: [Sipping] Redirection on busy and History Info
> 
> I think it is a slippery slope.
> 
> A typical "IP PBX" (i.e., a big blob controling IP Phones and TDM
> phones) or a Gateway can
> often redirect "internally".
> 
> In this model, it would then generate "fake" History-Info with 486 and
> other codes. 
> 
> If I am the only one uncomfortable with this, then we *could* 
> just write
> guidelines on rules
> for mapping History-Info to PSTN.
> 
> But again, this seems very bizarre to me...
> 
> I'd like to hear other opinions on this.
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]] 
> > Sent: Monday, October 31, 2005 23:52
> > To: Audet, Francois [SC100:9T51:EXCH]
> > Cc: Barnes, Mary [RICH2:B601:EXCH]; sipping; Elwell, John
> > Subject: Re: [Sipping] Redirection on busy and History Info
> > 
> > 
> > Hi Francois,
> > 
> > a UAS stating that there was a 486 response and then a 302, 
> > when all it 
> > did was redirecting because the user was busy (i.e., there 
> was no 486 
> > response in the network) is not actually cheating, IMO. It is just 
> > modeling itself as two SIP entities (a virtual proxy and a 
> > UAS) with a 
> > SIP interface between them.
> > 
> > We have a similar case with the double routing mechanism 
> described in 
> > RFC 3486 used with Sigcomp, where a proxy record-routes 
> > twice. It is not 
> > cheating; it is just modeling itself as two proxies linked by a SIP 
> > interface.
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > 
> > Francois Audet wrote:
> > > 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.
> > > 
> > > 
> > >>-----Original Message-----
> > >>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
> > >>
> > >>_______________________________________________
> > >>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
> > >>
> > >>
> > 
> > -- 
> > 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
> > 
> > 
> 

_______________________________________________
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: Wed, 02 Nov 2005 10:32:19 +0200

Hi John,

> Does the additional H-I entry have the same index as the existing one
> for this URI? 

A different index.

> If so, this probably would be confusing to a consumer
> of H-I. Or does it add one to the index? If so it is probably in
> danger of conflicting with another index already allocated by the
> proxy for parallel forking. 

No. There are no conflict in the example being proposed in this thread. 
They would have different prefixes.

> The existing H-I solution where the
> retargeting or recursing entity always adds new entries and assigns
> indices is relatively simple, but allowing a redirect server to do
> this fundamentally changes H-I.

I do not see how this changes H-I. H-I's goal is to record what happened 
to a request, and this is exactly the information we are looking for.

Then, we will need to decide how to endode commands like the ones you 
propose to encode in the Request-URI, but the recording part could 
actually be done with H-I.

Cheers,

Gonzalo