[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comparison of retargeting proposals
- To: "Ian Elz" <ian.elz at ericsson.com>, "Mary Barnes" <mary.barnes at nortel.com>, "Hans Erik van Elburg" <hanserik.van.elburg at ericsson.com>, "Juha Heinanen" <jh at tutpro.com>, "Christer Holmberg" <christer.holmberg at ericsson.com>
- Subject: Re: [Sip] Comparison of retargeting proposals
- From: "Francois Audet" <audet at nortel.com>
- Date: Wed, 2 Apr 2008 11:34:34 -0500
- Cc: sip at ietf.org, "DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>
- Delivered-to: ietfarch-sip-web-archive at core3.amsl.com
- Delivered-to: sip at core3.amsl.com
- In-reply-to: <C0E80510684FE94DBDE3A4AF6B968D2D030DA325 at esealmw118.eemea.ericsson.se>
- List-help: <mailto:sip-request@ietf.org?subject=help>
- List-id: Session Initiation Protocol <sip.ietf.org>
- List-post: <mailto:sip@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
- References: <1ECE0EB50388174790F9694F77522CCF15DAC007 at zrc2hxm0.corp.nortel.com> <C0E80510684FE94DBDE3A4AF6B968D2D030DA325 at esealmw118.eemea.ericsson.se>
- Sender: sip-bounces at ietf.org
- Thread-index: AciU15ikttSY0DgZRKSOS5eBZj0SKgABw/Ug
- Thread-topic: [Sip] Comparison of retargeting proposals
That's not a problem with History-Info, it's a "problem" with Tel URIs.
Tel URIs doesn't allow to use "?Reason=302" or whatever, which makes sense
because Tel URIs are not necessarily used by SIP. It could be used by
PSTN, H.323, whatever you want. So allowing SIP parameters in there (like
embedded SIP headers) makes no sense. If you want to force
SIP, don't use a Tel URI.
Why are we talking about these types of parameters in the first place?
If we need to add something to History-Info to clarify the target parameter
(whatever that means), then it should be a History Info parameter, not
a URI parameter.
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz at ericsson.com]
> Sent: Wednesday, April 02, 2008 08:38
> To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00);
> Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
> Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> Subject: RE: [Sip] Comparison of retargeting proposals
>
> Francois,
>
> You have missed one vital issue relating to History-Info.
>
> You cannot use a tel URI in History-Info as RFC3966 does not
> allow you to use header parameters. H-I uses header
> parameters for Reason and Privacy in H-I entries.
>
> To use a tel URI in a H-I entry requires that you convert it
> to a sip URI which requires that a suitable domain be found
> to create a valid entry.
>
> -----Original Message-----
> From: Francois Audet [mailto:audet at nortel.com]
> Sent: 01 April 2008 17:30
> To: Mary Barnes; Hans Erik van Elburg; Juha Heinanen;
> Christer Holmberg
> Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> Subject: Re: [Sip] Comparison of retargeting proposals
>
> The biggest problems with History-Info (IMHO) are:
>
> - It is written so that the UAC may generate the first
> History-Info entry
> or (more typically), it's proxy will. Creates some
> confusion on who does what.
> - It's optional
> - The number of entries can be pruned by proxies, making the
> content unreliable.
> - The last hop (i.e., replacing with contact) is not made
> obvious in the list (the
> whole point of this discussion).
> - People have used it as a replacement to diversion-header,
> i.e., to map to
> ISDN redirection number information. <--- This is the
> biggest problem
>
> All of those could be solve by a -bis.
>
> (There are also a few minor mistakes in some of the flows).
>
> > -----Original Message-----
> > From: Barnes, Mary (RICH2:AR00)
> > Sent: Tuesday, April 01, 2008 06:28
> > To: Hans Erik van Elburg; Audet, Francois (SC100:3055);
> Juha Heinanen;
> > Christer Holmberg
> > Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> > Subject: RE: [Sip] Comparison of retargeting proposals
> >
> > The proper use of History-Info isn't rocket science, but it does
> > require careful reading of the spec and proper
> implementation (i.e., I
> > agree if you don't implement the spec properly, then it is
> a mess but
> > that can be the case for any spec that isn't implemented properly).
> > There are some inaccuracies in one of Dale's examples on
> forking that
> > makes it look far more error prone and problematic than it
> should be.
> > I'll respond separately with details.
> >
> > Mary.
> >
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > Hans Erik van Elburg
> > Sent: Tuesday, April 01, 2008 3:07 AM
> > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg
> > Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> > Subject: Re: [Sip] Comparison of retargeting proposals
> >
> > The point is that History-Info does not solve the problem
> so something
> > new is needed anyway.
> >
> > And proper use of History-Info is rocket science as Dale has shown.
> >
> > /Hans Erik
> >
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > Francois Audet
> > Sent: Tuesday, April 01, 2008 2:16 AM
> > To: Juha Heinanen; Christer Holmberg
> > Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> > Subject: Re: [Sip] Comparison of retargeting proposals
> >
> > There are existing implementations of History-Info in the field.
> >
> > It's not rocket science.
> >
> > And I don't see why introducing something else will be simpler. It
> > will just be extra complexity.
> >
> > > -----Original Message-----
> > > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> > Behalf Of
> > > Juha Heinanen
> > > Sent: Saturday, March 29, 2008 05:48
> > > To: Christer Holmberg
> > > Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> > > Subject: Re: [Sip] Comparison of retargeting proposals
> > >
> > > Christer Holmberg writes:
> > >
> > > > However, I still fail to understand how Target would be more
> > > "complex"
> > > > than e.g. History-Info.
> > >
> > > christer,
> > >
> > > ANY solution for anything must be MUCH simpler than history-info,
> > > which is far too complex by itself.
> > >
> > > i haven't seen anyone fully implement history-info and
> most likely
> > > that is because of its complexity. if you are now going
> to invent
> > > some other mechanism that is as complex or even more
> > complex, it has
> > > no change in real world.
> > >
> > > i therefore suggest that h-i is deprecated and a replaced
> > by a simpler
> >
> > > mechanism.
> > >
> > > -- juha
> > > _______________________________________________
> > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > sip-implementors at cs.columbia.edu for questions on current sip Use
> > > sipping at ietf.org for new developments on the application of sip
> > >
> > _______________________________________________
> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org for new developments on the application of sip
> > _______________________________________________
> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org for new developments on the application of sip
> >
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip