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

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 : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la part de DRAGE, Keith (Keith)
Envoyé : lundi 6 septembre 2010 14:50
À : Hadriel Kaplan; Worley, Dale R (Dale)
Cc : sipcore@ietf.org
Objet : Re: [sipcore] #2: Editorial: section 2 is really confusing

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

> -----Original Message-----
> From: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> Sent: Friday, September 03, 2010 9:04 AM
> To: Worley, Dale R (Dale)
> Cc: sipcore@ietf.org; DRAGE, Keith (Keith)
> Subject: Re: [sipcore] #2: Editorial: section 2 is really confusing
> 
> 
> On Sep 2, 2010, at 5:37 PM, Worley, Dale R (Dale) wrote:
> 
> > ________________________________________
> > From: Hadriel Kaplan [HKaplan@acmepacket.com]
> > 
> > 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.
> > ________________________________________
> > 
> > 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
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore