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

[Fermín Galán Márquez]

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

Good argumentation. Definitely, I think you are right: no Path headers
processing should be done.

------
Fermín
Agora Systems, S. A.