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

[Fermín Galán Márquez]

> I think we should move this on a different list, as it will go
> off-topic. If there are more people interested in IMS I would suggest to
> open a different email list, like ser-ims for example.

As long as the Path extension this module implements (or tries implementing
:) is under IETF standards (in fact, RFC 3327), I think is better to keep
discussion in the global ser-devel list.

However, about the Internet (IETF) vs IMS (3GPP) discussion (I've seen the
thread get hotter and hotter in several mails, but I'm more interested in
technical than philosophical or political issues :), note 3GPP is using IETF
extensions to implement IMS (there is a liaison agreement between both
standardization bodies: 3GPP has been requesting several IMS-oriented SIP
extensions to IETF that IETF has been developing in draft and RFC
documents).

> As the comments are getting too long, here are my considerations:
>
> 1. Fixing the bug in the 1-element-Route.
> I suspect that you are parsing the route header. That is not necessary.
> Just take the entire content of the header. parsing only makes sense if
> you want to check if the is correct.

I'm not sure about you are meaning with this bug... The 1-element-Route is a
consequence of the 1-element-Path (item 1 and 2 are related). It's more a
limitation than a bug...

> 2. How many elements the Path contains
> it is 90% safe to assume that there is only one P-CSCF for a user.
> Unfortunately, if 3GPP speacks about "preloaded _list_ of" I would
> assume that there would be cases when there are more. For example a NAT
> proxy between the P-CSCF and the UE.

Right. A general implementation of the RFC 3327 should consider a list.

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

> 4. Mapping P-Asserted-Identity<->Contact
> Probably I should explain why IMS does not trust To/From. Well simply
> because they might be faked.What happens in IMS is that on registration
> and IPSec tunnel is established between the P-CSCF and the UE. And the
> P-CSCF will only allow the UE to use identities that it previously
> registered for that contact. The UE can indicate a preferred identity
> with P-preferred-identity. This is necessary as the other parts of the
> networks need to be assured about the UE's identity. As the P-CSCF does
> not check the To/From headers they can not be trusted inside the core
> network.

Thank for the explanation. However, I wonder if in some place in the 3GPP
specs (which TS, which section, etc.) this is clearly stated as you explain.

However, the "dummy" P-CSCF that I have been using to test the path module
doesn't include P-Asserted-Identity headers, just To/From.

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

> 6. Route header location
> I have the same opinion about lumps ;-). The thing is that I might do
> multiple processing on the message. The first step is OK, because I only
> modified the already-there headers. But after that I must look into
> headers and also lumps and I found that incredibly stressing!!! I
> understand that you want ultimate speed, but come on, there must be a
> way to integrate the lumps into the message so that the 2nd time you
> will be looking in just one list of headers.
> For adding after the last Via, you should find that Via and then insert
> a lump right afther that and to that lump attach a lump add with the new
> header. That sounds weird ;-).

I know the theory, but I've failed in the past trying to implement so. This
is why I asked for help of other more lump-experienced people in order to
implement the Route placing :)

> I would very much like to participate and to help you and I would
> certainly try, but I am incredibly busy at the moment and I hope that
> for the moment will still help in a way.

I'm also quite busy, so I don't know when I can have the time to keep
working on the code. However, I think is interesting to establish a TODO
list for the path module, in order me, you o any interested people could
work on it. My conclusions are:

- Multiple elements in a Path header
- Module parameter to allow both Route processing: just pasting from Path
(RFC-way) or removing the user token in SIP URI (IMS-way).
- Put the Route header derived from the path vector route just after Via.
- User P-Asserted-Identity to perform binding instead To/From

I've try to upload the current implementation to the SER CVS, but I've first
know how the development is structure. Anybody can help?

Best regards,

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

[1] G. Camarillo, M. García-Martín, "The 3G IP Multimedia Subsystem", Ed.
Wiley, 2004. ISBN: 0-470-87156-3. IMHO, a very good IMS reference.