Subject: Re: [sipcore] #2: Editorial: section 2 is really confusing

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Sep 2010 16:01:32 +0200

I prefer not to use the term "diversion" because there is a well defined set of ISDN diversion services, and while the use of History-Info does encompass equivalents of such services, it encompasses much more. 

Changing the target to a new Request-URI may encompass diversion (in the ISDN sense), but it could also encompass a number of other cases, including freephone and number portability.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
> Sent: Tuesday, August 31, 2010 4:34 PM
> To: Hadriel Kaplan; Mary Barnes
> Cc: [email-masked]
> Subject: Re: [sipcore] #2: Editorial: section 2 is really confusing
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On 
> Behalf Of Hadriel Kaplan [[email-masked]]
> 
> Do you not want to use the term "Divert" because of the 
> Diversion header?
> 
> I think it's the only term left that isn't ambiguous... 
> "retarget" is being used for any/all cases of changing the 
> request-uri, and "forward" is used for generic message 
> routing procedures, and "redirect" is used for 3xx cases.  So 
> there isn't a term left I can think of that means "changing 
> the target to a new user/identity" (i.e., "call forwarding" 
> in the PSTN).
> 
> And really the draft would be clearer if there was a unique 
> term for that, because a lot of use-cses depend on it: 
> finding the previous or current diverted-to party.
> ______________________________________________
> 
> People use these various terms freely, but in reality, none 
> of them are well-defined and people don't use the same 
> definition for each term.  The current doc carries forward 
> this confusion by deferring the meanings to previous 
> documents.  The only useful way to deal with the situation is 
> to define the terms we want to use ab initio in this document.
> 
> Dale
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Sep 2010 10:50:00 -0400

Oh, excellent point.  In fact, mapping in the freephone sense isn't really the same "kind" as mapping in the call-forwarding sense, and will make it neigh impossible to distinguish at the UAS.  How will a UAS actually be able to tell apart diversions from others? (for example, to interwork to Diversion or to ISDN)

Perhaps what we really need is a specific tag for actual diverting - for the case of changing the identity of the target such that the new identity has no inherent relation to the previous target, for example with a "dv" param; whereas the freephone case the new target is much closer to "mapping" in the common english sense and would use a "mp".  No?

-hadriel

---

From: Mary Barnes <[email-masked]>
Date: Wed, 1 Sep 2010 10:20:30 -0500

We had a couple more tags in previous versions of the individual
draft, but we removed those for the sake of simplicity and addressing
the known use cases. If we think the tags we have are not sufficient,
we can revisit (I personally liked have very unique tags even if the
end behavior for the tags was the same).

Mary.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 15:15:54 -0400

From: Mary Barnes [[email-masked]]
> On Tue, Aug 31, 2010 at 1:36 PM, Worley, Dale R (Dale)
> <[email-masked]> wrote:
> > From: Mary Barnes [[email-masked]]
> >
> > > I'm of the
> > > mindset right now that we should resolve all the other editorial
> > > issues and see if being more precise with the current definitions
> > > doesn't help and just live with the ambiguity as we've lived with it
> > > for other terms.  The important aspect is what happens with the
> > > protocol and I think it's more important to get the normative text
> > > correct.
> >
> > It seems to me that the definitions of "retargeting", "redirecting",
> > etc. (with the possible exception of "diversion") are not clear and
> > have never been clear.  Up until 4244bis, this hasn't mattered.  But
> > in 4244bis these allegedly distinct operations cause different things
> > to go on the wire, so we have to make the definitions unambiguous.
> 
> The intent is that the tags (or lack thereof) are what adds the
> clarification.  There's only so much we can do to not avoid conflict
> with other terms.  IF we were rewriting RFC 3261, then certainly, we
> could resolve this issue.  My suggestion is that we clean up all the
> other issues, etc. that folks have highlighted and then we'll see
> where we are. It might become more obvious (to me at least) how best
> to use the terms as I'm in the middle of the edits.

In regard to "retarget", "forward", "rerouting", "contact routing",
and even "diversion", we should note that defining them (in any
manner) is not necessary for this work to progress.  If those terms
were to have any ultimate relevance, they would appear in the text
that specifies when "rc" and "mp" are to be use, which is:

   6.3.1

   o  "rc": The Request-URI is a contact that is bound to an AOR in an
      abstract location service.  The AOR-to-contact binding has been
      placed into the location service by a SIP Registrar that received
      a SIP REGISTER request.

   o  "mp": The Request-URI is a URI that represents another user.  This
      occurs when a request is to be statically or dynamically
      retargeted to another user.

And we may disregard the second sentence of the second case, as it
describes an example of the case; the specification is the first
sentence.

Once that sentence is disregarded, it's clear that "retarget" et
al. have no normative appearance in the document.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Sep 2010 16:41:30 -0400

That's only because no one's submitted a tracker ticket to go use <favorite-term> where appropriate in the draft. :)

The draft needs a re-write to use the terms, so that it will be easier to read.  Even if it's not in section 6.3.1's specific normative statements (though it should be), using the terms elsewhere in non-normative will make it easier to grok I think.

But first we need to agree on the terms.  Just using the word "retarget" again and again doesn't help imo, when we really mean different, specific sub-types of retargeting in different cases. (for the cases that matter)

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 16:54:41 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]

My approach is to avoid using "those words" at all, because I see them as not being effectively defined.

But I think that everyone agrees that we must have a solid correspondence between:

- the paramters, tags, or values that distinguish the different cases (Currently "mp", "rc", and "[none]".)

- the correspondence between them and the specific situations that they indicate (Currently section 6.3.1.)

- the (carefully defined!) words we use to name those situations

In regard to "the words" themselves, of course we have to beware that almost all the words we'd like to use have been used heavily before, sometimes with careful definitions (e.g., "diversion" in PSTN) and sometimes rather sloppily (e.g., "retarget" in RFC 3261).  The latter may cause a conflict between "being clear" and "being compatible with previous usage".

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Sep 2010 16:54:47 -0400

And I was probably one of the people arguing against too many tags. :)
Unfortunately, the use-case I personally really care about is recording diversions.  Both in order to interwork to/from the Diversion header, and for ISUP interworking, and because I still hear complaints from operators that SIP doesn't have the redirection information so they have to still carry ISUP IAMs.  So I need an identifier of which of these H-I entries are *actual* diverts and not just SIP being SIP.  I know it's just one use-case among many, but I'm probably not alone in needing it.(?)  If I am I'll shut up about it.

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 17:37:33 -0400

________________________________________
From: Hadriel Kaplan [[email-masked]]

Can you point us to the data model of the info that they want/need?  And do you know how parallel the models of Diversion and ISUP are?

(BTW, would it be possible to carry this information in Reason headers in the hi-entry URIs?)

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Sep 2010 04:04:13 -0400

See RFC 5806 section 9.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 6 Sep 2010 14:49:36 +0200

RFC 5806 is someones interpretation of what occurs in the ISDN which has not been verified anywhere by expert review.

I suggest you go to the relevant ISDN stage 2 descriptions if you wish to understand the data flows in the ISDN design:

ITU-T recommendations Q.82.2 and Q.82.3, from which both the DSS1 and ISUP protocols both map.

Note that for private networking, there is a further split in this model which separates the diversion detection function from the diversion enaction function. Thus while the public ISDN diversion is always by forward switching (due primarily to charging issues), private ISDN diversion can be by rerouteing (the SIP equivalent is doing diversion by sending a 3xx back).

The equivalent private ISDN standard is documented by ISO in ISO/IEC 13872 (2003) but the most accessible form is probably as ECMA-international ECMA-173

regards

Keith

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Friday, September 03, 2010 9:04 AM
> To: Worley, Dale R (Dale)
> Cc: [email-masked]; DRAGE, Keith (Keith)
> > Unfortunately, the use-case I personally really care about 
> is recording diversions.  Both in order to interwork to/from 
> the Diversion header, and for ISUP interworking, and because 
> I still hear complaints from operators that SIP doesn't have 
> the redirection information so they have to still carry ISUP 
> IAMs.  So I need an identifier of which of these H-I entries 
> are *actual* diverts and not just SIP being SIP.  I know it's 
> just one use-case among many, but I'm probably not alone in 
> needing it.(?)  If I am I'll shut up about it.
> > Can you point us to the data model of the info that they 
> want/need?  And do you know how parallel the models of 
> Diversion and ISUP are?
> 
> See RFC 5806 section 9.
> 
> -hadriel

---

From: <[email-masked]>
Date: Tue, 7 Sep 2010 10:44:35 +0200

In order to use at best the H-I header, it should be better to clearly include the diverting case (the most used today, imv).
I suggest 2 solutions to solve the "diversion" identification among H-I entries:
1- add a tag 'dv' identifying the diverting users in the sense of ISUP protocol (and/or Diversion header)
or
2- extend the Reason header with new reason-cause and new reason-text (eg. ?Reason=application;cause=1;text=call diversion)

We can then concentrate on the other abilities of the H-I header, so that applications could convey usefull information (eg. Add more Reason values like ?Reason=application;cause=2;text=freephone and so on).

Regards

Marianne

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de DRAGE, Keith (Keith)
Envoyé : lundi 6 septembre 2010 14:50
À : Hadriel Kaplan; Worley, Dale R (Dale)
Cc : [email-masked]
Objet : Re: [sipcore] #2: Editorial: section 2 is really confusing

regards

Keith

> is recording diversions.  Both in order to interwork to/from the 
> Diversion header, and for ISUP interworking, and because I still hear 
> complaints from operators that SIP doesn't have the redirection 
> information so they have to still carry ISUP IAMs.  So I need an 
> identifier of which of these H-I entries are *actual* diverts and not 
> just SIP being SIP.  I know it's just one use-case among many, but I'm 
> probably not alone in needing it.(?)  If I am I'll shut up about it.
> want/need?  And do you know how parallel the models of Diversion and 
> ISUP are?
> 
> See RFC 5806 section 9.
> 
> -hadriel