Subject: RE: [SIP] Draft about diversion out of date

From: Steve Levy <[email-masked]>
Date: Tue, 08 May 2001 09:11:10 -0700

Hi Igor,

It may help you if you get to take a look at some of the presentations from
the SIP Summit held last week in Dallas. The diversion header was mentioned
by a number of the presenters as a way of assisting in network
interoperability and helping enable enhanced services.

Steve

At 03:54 PM 5/7/01 -0400, Igor Slepchin wrote:
>A motivation section and examples of functionality that require this
>extension are conspicuously lacking in the current draft. Adding them may
>help me understand why this draft is needed in the first place.
>
>---
>Igor Slepchin
>
>
>> -----Original Message-----
>> From: Bryan Byerly [mailto:[email-masked]]
>> Sent: Friday, May 04, 2001 12:39 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Re: [SIP] Draft about diversion out of date
>> 
>> 
>> Hi Patrick,
>> 
>> There is an updated version of the I-D available.  I'll post it to the
>> list shortly.
>> 
>> thanks,
>> Bryan
>> 
>> [email-masked] wrote:
>> 
>> > Sirs,
>> >
>> > The following I-D "draft-levy-sip-diversion-01.txt" is now 
>> out of date.
>> > Could someone give us the future of that I-D:
>> > -No longer used
>> > -new version soon available,
>> > -else ?
>> >
>> > TIA for your response,
>> >
>> > Patrick
>> >
>> > _______________________________________________
>> > This list is for continuing development of the SIP protocol.
>> > The sip-implementor's list is the place to discuss implementation,
>> > and to receive advice on understanding existing sip.
>> > To subscribe to it, send mail to
>> > [email-masked] with "subscribe" 
>> in the body.
>> 
>> 
>> _______________________________________________
>> This list is for continuing development of the SIP protocol.
>> The sip-implementor's list is the place to discuss implementation,
>> and to receive advice on understanding existing sip.
>> To subscribe to it, send mail to 
>> [email-masked] with "subscribe" in the body.
>> 
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to 
>[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 13 May 2001 22:03:41 +0100

I suggest you look at the stage 2 documents for ISDN (Q.84.2through5 from
memory - its somewhere around there anyway). You will find that the
originating exchange receives all information about each forwarding hop
(step by step as it occurs). 

The forwarded to exchange gets the original and last forwarding numbers.

Whether these are presented to the end user depends on the wishes of the
calling and forwarding users.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Igor Slepchin[SMTP:[email-masked]]
> Sent: 	08 May 2001 15:19
> To: 	'Bryan Byerly'; Igor Slepchin
> Cc: 	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	RE: [SIP] Draft about diversion out of date
> 
	snip
> > Multiple diversions.
> 
> Hmm, these are not really supported by PSTN. Just as your draft says, the
> only information available in ISDN parameters are the called party and the
> redirecting number. Nowhere does PSTN remember all the previous
> redirections
> like suggested by the draft.
> 
>

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 15 May 2001 15:29:41 -0700

At 12:19 AM 5/15/2001, Jonathan Rosenberg wrote:
>Now, this problem is fixable. As Allison has mentioned during IETF 50, all
>extensions henceforth MUST describe how backwards compatibility operates.
>Therefore, the draft MUST describe how gateways, voicemail servers, and
>anything else that looks at Diversion, would work in its absence.

Jonathan, you mentioned that this was not standards track. Why must we 
describe backwards compatibility with any old 
draft-yournamehere-sip-xxx.txt document? I hope that was not the intention 
of the Allison since that could kill some efforts. We should only be 
concerned about backwards compatibility with real standards track RFC's. If 
people choose to implement independent drafts, they do so knowing that it 
isn't standard. The rest of the community shouldn't have to suffer 
compliance with that random draft. If the SIP WG didn't do a good job of 
communicating the IETF process to implementors, future work shouldn't have 
to suffer.