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

[Dragos Vingarzan]

Hi Fermín,

Great to hear about this and I think it will be quite useful. I am also
working on CSCFs modules. Inlined you will find my remarks.
Unfortunately I have not read the RFC 3327 when I implemented this
functionality but I did read the 3GPP's TechSpecs so my comments are
mainly based on those. I will read the RFC shortly, but if I am ever
wrong, please correct me.

Fermín Galán Márquez wrote:

>Hello,
>
>I would like to share a SER module that we (Agora Systems) have developed to
>implement the SIP Path extension (RFC 2976). This development is aimed to be
>used in IMS proxies' implementation, in particular, to cope with the
>functionality in S-CSCF proxies.
>
>The module provides two functions:
>
>store_path(): store the content of the "Path" header in the request into a
>very simple database: key is the SIP URI in "From" (note that store_path()
>it's intended to be used during registration in registrar servers) and value
>is the "Path" content.
>  
>
This is a good start as you can actually call the function to save this
from the script. But here as an excerpt from TS 24.229 section
5.4.1.2.2   Protected REGISTER

> 7) check whether a Path header was included in the REGISTER request
> and construct a list of preloaded Route headers from the list of
> entries in the Path header. The S-CSCF shall preserve the order of the
> preloaded Route headers and bind them to the contact information that
> was received in the REGISTER message;
>
> NOTE 4: If this registration is a reregistration, then a list of
> pre-loaded Route headers will already exist. The new list replaces the
> old list.
>
- it must be a list - it would be great if you fixed that bug ;-) - also
it's preloaded and I assume that you can save the entire content of the
header as a simple text and later paste the entire thing into  a Route.
- never trust the From/To header - there are other trustable headers in
IMS, like P-Asserted-Identity, so binding it to the From is not a good
ideea as the From can be faked.
- I am binding it to a contact address as to a SIP URI found in a
header. Because of the Private/Public Identity mappings in IMS you could
have many public identities implicitly registered on a single UE and
maybe just one of them would have the Path saved correctly. Anyway, to
conclude, the Path is actually used to find the P-CSCF through which the
UE can be reached, so this is one more reason why this info must pe
mapped to the contact address of the UE.

>route_based_path(): retrieves the stored value (using the SIP URI in the
>Request URI as key), put it in a "Route" header and forward the request to
>that destination.
>  
>
it is actually path_based_route(), right? ;-).

>An example of how to use both function to implement a simplified S-CSCF is
>shown in the attached ser.cfg file.
>
>The code is attached in path.tgz file. Just uncompress it inside modules/
>directory in the SER sources. It has been development for SER version 0.8.14
>(but I think I would compile in newer versions without problem).
>
>Note that the code is very primitive, more a "proof-of-concept" that a
>strong and smart implementation. However, I think it could be interesting
>for others, which maybe want to help to improve it. We aren't SER gurus :)
>and maybe there are clever and smarter ways to do the same things in the
>code. For example, putting the "Route" header in a smarter place (the
>current implementation put "Route" always after all other headers, that is
>valid but not recommended in RFC 3261).
>  
>
I would suggest to put in in the registrar as this info is very similar
for example to NAT info. I also wanted to do this at first, but ended
with implementing my own registrar from ground up.
Also, put it as the first Route in the message because in various spots
the 3GPPs specs say that a CSCF should check the first Route header if
it is equal to itself and then act accordingly. So here your
implementation would break. And also if node A receives a message with
Route: B, A it should first route it through B then B will route back to A.
Here is how I do it
/**
 * Adds a header to the message as the first one in the message
 * @param msg - the message to add a header to
 * @param content - the str containing the new header
 * @returns 1 on succes, 0 on failure
 */
int cscf_add_header_first(struct sip_msg *msg, str *hdr)
{
    struct hdr_field *first;
    struct lump* anchor,*l;

    first = msg->headers;
    anchor = anchor_lump(msg, first->name.s - msg->buf, 0 , 0 );

    if (anchor == NULL) {
        LOG(L_ERR, "ERR:"M_NAME":cscf_add_header_first: anchor_lump
failed\n");
        return 0;
    }

    if (!(l=insert_new_lump_before(anchor, hdr->s,hdr->len,HDR_ROUTE_T))){
        LOG(L_ERR, "ERR:"M_NAME":cscf_add_header_first: error creating
lump for header\n" );
        return 0;
    }   
     return 1;
}

I know that the SIP gurus will argument that it would nicer to add it
actually after the last Via...


>Other thing that can be improved is the database. The current implementation
>uses a simple text file and, if the "Path" header doesn't include exactly
>one SIP URI (as in IMS, where "Path" is intend to include the SIP URI of the
>P-CSCF from where the user is registering) the header handler routines would
>fail.
>
>We would like to know any comment, suggestion or bug report. Modification on
>the code that could improve the existing functionality is also really
>welcome. We would like to work towards a stable module that could be
>interesting for SER users and included in the software package.
>  
>
>Best regards,
>
>------
>Fermín
>Agora Systems, S. A.
>  
>

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