Subject: RE: [Sip] Poll: expert review of draft-henrikson-sip-charging-in formation

From: "Henrikson, Eric H (Eric)" <[email-masked]>
Date: Wed, 29 May 2002 19:21:25 -0500

Jonathan,

Thank you for the comments.  I am open to any alternative that solves the problem of correlating the dialogs at the S-CSCF.

Please confirm that I am understanding your proposal correctly.  

The problem we are trying to solve only pertains to the case of a B2BUA type of application server for 3GPP.  If an INVITE is sent from a S-CSCF to a B2BUA, which then sends a new INVITE back to the S-CSCF, I don't see how using just the Route information can be used to correlate the new INVITE with the old INVITE.  Each INVITE may have different To tag, From tag and Call-ID.  The (plain) Route header in the new INVITE may be common with dozens of other INVITEs that have followed this same path.  

I find the following definition for Route:

        Route        =  "Route" HCOLON route-param *(COMMA route-param)
        route-param  =  name-addr *( SEMI rr-param )
        rr-param     =  generic-param

Are you suggesting that there is some parameter placed in the 2nd Route header element inserted by the S-CSCF that it uses for the correlation?  If so, then is it ok to use a 3GPP specific parameter defined within 3GPP specifications (rr-param)?

If that is what is meant, then I can see where the S-CSCF could define a unique value to send with the 2nd Route header, e.g. ";correlate=2349873453", and we could require that 3GPP compliant B2BUA Application Servers return 2nd Route header as the topmost Route header to the S-CSCF .

Eric Henrikson

p.s. I presume you are referring to the P-Original-Dialog-ID draft and not the charging information draft.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, May 29, 2002 1:04 PM
To: Dean Willis
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sip] Poll: expert review of
draft-henrikson-sip-charging-information

First off, I have to apologize for the lateness of these comments. Given
the scope of my comments, I should have raised them earlier. 

I have some serious concerns about this draft.

Most notably, I disagree entirely with the assessment that the problem
isn't entirely solved by loose routing. When the S-CSCF sends a request
to an application server, it ought to be inserting two loose routes -
one that points to the AS, and another that points back to itself,
containing whatever context is needed for the S-CSCF to do what it needs
to do from that point forward. The draft makes the following statement:

>  One may consider using the Route header as a mechanism to get the 
>     request sent back to the S-CSCF.  However, Route headers don't 
>     automatically transit an AS acting as a B2BUA. This could be 
>     overcome by using loose-routing and application logic in the B2BUA.  
>     But that is not the full problem to be solved. A strong correlation 
>     of dialogs is also needed for accounting purposes to treat the 
>     sequence of dialogs as a concatenated single dialog. A common 
>     identification tag needs to be carried in each related dialog so 
>     that the charging functions can associate all the dialogs. 

A smart B2BUA will not discard loose routes, particularly not one thats
used in 3gpp for this reason exactly. Thus, the principal motivation
given, being able to corelate incoming INVITEs from outgoing ones in a
spiral - is not correct. We explicitly designed the loose routing stuff
to enable exactly this kind of function (remember the Bjorkner service
route draft?).

The other argument that is given here - correlation of dialogs for
accounting purposes - makes no sense to me. The route header provides
the ability for the S-CSCF to completely correlate the incoming INVITE
to the one it sent out. It therefore has all the information it needs to
account for the calls and to know which applications are invoked. 

The last thing I want to do is specify two ways of doing the same thing.
Given that this kind of correlation is square in the sights of loose
routing, I am concerned about the overlap.

-Jonathan R.

Dean Willis wrote:
> 
> You may recall that we're doing an Expert Review of
> draft-henrikson-sip-charging-information.
> 
> If you have a strong opinion for, against, or supporting a need for
> further work, or any further suggestions for enhancement, please post
> them now.
> 
> --
> Dean Willis
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip