[Serdev] Concept for a SIP cluster implementation

[Greger V. Teigre]

> I already contacted Fermin a few weeks ago, and since he has another
> job now, he won't work a lot on it anymore. But I will probably steal
> some code from the path module ;o)

Ok. I will contact Fermin. If the module is not to be maintained in
experimental, I agree with you that it is better that you take over the path
code.

> Also I think it logically belongs rather into the registrar module
> than into a seperated one, because it is always involved in save()
> and lookup().

Path is also used in IMS (CSCF) and any structural changes should IMO keep 
the original
intention of the code. I saw Dragos from FOKUS in dialog with Fermin on 
this, so
maybe he can help out in verifying that the code stays compatible with IMS 
requirements.

>> - From my point of view, I cannot see any reasons for why this
>> shouldn't be possible to include in HEAD once it has proven its
>> stability in experimental
>
> See above. When integrating it into usrloc and registrar, you have the
> code exactly where the relevant things actually happen (parsing the
> REGISTER and storing the values into usrloc in save() and loading it
> from usrloc in lookup()).

Yes, I see that.

> When placing the code in an extra module, you have to do this parsing,
> storing and loading again, which makes no sense IMHO. And since it
> needs 0.10.x because of the branch routing functionality anyway, I would
> prefer to integrate it right there.
>
> It also won't have an impact on scenarios where no Path is used, so...

Ah! I see, I didn't get that you wanted the code directly into head, without 
going into experimental.  That I will not have an opinion on :-) But AFAI 
can see, implementing Path is something that would strengthen SER's 
capabilities as long as the RFC (and 3GPP) specs are followed.

g-)