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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jun 2002 17:08:10 -0400

Apologies for the delay in responding. Responses inline.

Henrikson, Eric H (Eric) wrote:
> 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.  

Well, it shouldn't be. Thats the proposal.

> 
> 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)?

Either a parameter, or more simply, the user part.

Think of it this way. A URI identifies a resource. In the case of a 
conference server, the URI identifies a particular instance of a 
conference. It therefore really points to a collection of state that 
collectively represent the conference. The user part is a pointer to 
that state. So, for example:

sip:[email-masked]

Now, your S-CSCF is a resource too. In its case, the resource is the 
particular instance of the application invocation context that this 
request is associated with. The URI therefore points to a collection of 
state that collectively represent the context. The user part is a 
pointer to that state. So, for example:

sip:[email-masked]

Thus, you require no new parameter or standardization.

> 
> 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 .

They don't need to just be egpp compliant. Any reasonably implemented 
b2bua should honor route headers like a proxy does. Therefore, it ought 
to work with any b2bua.

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

Yes, sorry. To many p-header drafts, too little time....

-Jonathan R.

-- 
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