[Serdev] contribution: SER module implementing Path extension (RFC 3327)

[Dragos Vingarzan]

Fermín Galán Márquez wrote:

>>3. Pasting the Path could be problematic.
>>Not at all. I guess you have just made the assumption that you should
>>drop the user part from the route because the P-CSCF. Well, if you do
>>that, you will break my P-CSCF :-) because I am actually using it. The
>>username can be used as and indication for the request direction in this
>>case and you should just leave it there. I could also use a different
>>port or a parameter in the URI.
>>    
>>
>
>This is an obscure point...
>
>In one hand, in RFC 3327, the Path is pasted without any processing (compare
>the stored path vector -page 9- with the resulting Route -page 12), as you
>said.
>
>In the other hand, the 3GPP literature shows how the user token is removed.
>In particular:
>
>- TS 24.228 (v5.10): compare the Path introduced by the P-CSCF in Table 6.2
>15(<sip:term at pcscf1.visited1.net;lr>) with the resulting Route in Table
>7.4.2.1-4 (<sip:pcscf2.visited2.net;lr>).
>
>- The same in [1]: compare Fig 5.6 with Fig. 5.32.
>
>Therefore, what to do in the module? I think the best approach is to be
>flexible enough to allow both ways, maybe using a "flag" module parameter
>(two values: "RFC-way" and "IMS-way"). Currently, the "IMS-way" is used.
>  
>
It's incredible how incomplete TSpecs can create confussion.
What happened in that example is that user1 called user2. Now there is
nor register in there for user2, so I guess you assumed that the Path
header for user2 was with term at . But I would say that it wasn't. I
really don't think that some router should introduce a header value that
other router should modify before forwarding. Also the 2nd user does not
care about the userpart so there must be a reason why it was sent, right?

Now, in various parts of the 34.229 it is stated that when sending
information like the Path header (the Service-Route for example is
similar, but in different directions, or the ISC interface with
AppServs) the setting server can use it to indicate various session
information like in this case the call direction - terminating (or in
other cases a processing session identifier on the ISC interface).

Also there are 3 points where you could use it, username beeing just one
of them and I hope we won't also argue about the other two.
- username
- port number - but this implies running the server on different ports
just to identify things
- parameter in the uri

>>5. Public/aor associations and stuff
>>The thing is that there are these implicitly registered identity sets.
>>So when you register one of that, you got them all registered. So you
>>practically register just one, but the HSS (the AAA server) replies with
>>the registered set. Also the P-CSCF and the UE finds this out by
>>subscribeing to the reg event at the S-CSCF.
>>Well, I guess things are getting a little to complicated for the time
>>beeing ;-)
>>    
>>
>
>To integrate the path module in an implicit registration framework could be
>too complicated. So, in a first approach, I think is better consider
>conventional explicit registration.
>
>  
>
Then the P-Asserted-Identity can be skiped for the beginning.


Cheers,

-- 
-----------------------------------------
Dipl. Eng. Dragos Vingarzan
FOKUS/NGNI
Kaiserin-Augusta-Allee 31
10589 Berlin,Germany
Phone +49 (0)30 - 3463 - 7385
Mobile +49 (0)162 - 153 - 0154
eMail vingarzan at fokus.fraunhofer.de
Web www.fokus.fraunhofer.de
We could change the world if God will give us the source code...
-------------------------------------------------------