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

From: "Mark Watson" <[email-masked]>
Date: Tue, 8 May 2001 14:28:23 +0100

Any chance someone can point us at the presentations mentioned below ?

I thought that the Diversion draft had been dropped - the list at
http://www.softarmor.com/sipwg/draftstatus/sip-draftstatus.html indicates
'General dissent at IETF49'.

Nevertheless, I would agree with a requirement to deal with the case where
calls encounter diversion before entering the SIP network (i.e. in another
network). Calls which encounter diversion within the SIP network will use
the existing SIP mechanisms - redirect, REFER etc., but if the diversion
happens before the SIP network ...

Provision of any identity information associated with the diverting party,
though, would need to meet the same privacy and authenticity requirements as
any other identity information as described in the privacy draft. Any future
Diversion proposals should look at using the capabilities defined there,
rather than adding a new header for this information.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Steve Levy [mailto:[email-masked]]
> Sent: 08 May 2001 17:11
> To: Igor Slepchin; 'Bryan Byerly'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] Draft about diversion out of date
> 
> 
> 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: Bryan Byerly <[email-masked]>
Date: Wed, 09 May 2001 15:01:47 -0400

Hi Mark,

> Any chance someone can point us at the presentations mentioned below ?

Absolutely.  Please see the attached presentation of the Diversion I-D.

> http://www.softarmor.com/sipwg/draftstatus/sip-draftstatus.html
> indicates 'General dissent at IETF49'.

As I recall, the SIP WG chairs pressured the SIP WG to not accept
additional work items.  Presentations such as the Diversion I-D were
given 3 minute slots to briefly touch on new draft ideas.  There was not
time for discussion of the drafts and any discussion which was started
was abruptly cut off by the SIP WG chairs.  Therefore, I'd definitely
say that the softarmor site is overstating the WG reaction.

>Nevertheless, I would agree with a requirement to deal with the case
where calls encounter diversion before entering the SIP network (i.e. in
another network). >Calls which encounter diversion within the SIP
network will use the existing SIP mechanisms - redirect, REFER etc., but
if the diversion happens before the SIP >network ...

Right, I've yet to see an approach ala RFC3708 that provides the desired
information to the called user agent service without requiring extensive
called user agent service-specific policy configuration in the carrier's
gateways/nodes.  Such an approach leaves the door open for namespace
collisions (when separate carrier customers' have collisions in local
customer policy namespaces).  Further, imagine trying to interop domains
using different syntactical conventions ala RFC3708.  You would have to
install translation proxies just to re-write the Request-URI according
to local domain naming conventions.

All of this mess can be avoided by supporting Diversion.

> Provision of any identity information associated with the diverting
> party, though, would need to meet the same privacy and authenticity
> requirements as any other identity information as described in the
> privacy draft. Any future Diversion proposals should look at using the
> capabilities defined there, rather than adding a new header for this
> information.

Interesting idea...  we'd thought about taking a header hiding approach
early on.  We'll have to consider privacy interaction further.

thanks for your help!
Bryan

Bryan J. Byerly
[email-masked]

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 09 May 2001 15:17:06 -0400

Oops, the opaque-uri approach was presented in RFC3087 (not RFC3807).
Darn my dyslexic fingers!  Sorry for the confusion.

thanks,
Bryan

Bryan Byerly wrote:

> given 3 minute slots to briefly touch on new draft ideas.  There was
> not time for discussion of the drafts and any discussion which was
> started was abruptly cut off by the SIP WG chairs.  Therefore, I'd
> definitely say that the softarmor site is overstating the WG reaction.
>
> where calls encounter diversion before entering the SIP network (i.e.
> in another network). >Calls which encounter diversion within the SIP
> network will use the existing SIP mechanisms - redirect, REFER etc.,
> but if the diversion happens before the SIP >network ...
>
> Right, I've yet to see an approach ala RFC3087 that provides the
> desired information to the called user agent service without requiring
> extensive called user agent service-specific policy configuration in
> the carrier's gateways/nodes.  Such an approach leaves the door open
> for namespace collisions (when separate carrier customers' have
> collisions in local customer policy namespaces).  Further, imagine
> trying to interop domains using different syntactical conventions ala
> RFC3087.  You would have to install translation proxies just to
> re-write the Request-URI according to local domain naming conventions.
>
>> privacy draft. Any future Diversion proposals should look at using
>> the capabilities defined there, rather than adding a new header for
>> this information.
>
> Interesting idea...  we'd thought about taking a header hiding
> approach early on.  We'll have to consider privacy interaction
> further.
>
> thanks for your help!
> Bryan
>
> Bryan J. Byerly
> [email-masked]
>
>> Regards,
>>
>> Mark Watson
>> Nortel Networks
>>