[Serdev] Concept for a SIP cluster implementation

[Andreas Granig]

Juha Heinanen wrote:
> in that case, i didn't understand your proposal.  anyway, path header is
> not supported by most SIP UAs, which would nullify its use here.  also,

I don't see why the UAs necessarily have to support it. RFC 3327 says in 
§5.3:

"However, the Path mechanism should technically work in the absence of 
UA support (at some compromise to security), so some registrars MAY 
choose to support the extension in the absence of a Supported header 
field value in the request."

So if you let the admin of the registrar to configure when to send back 
the Path header to the UA in the reply or when to reply "420 Bad 
Extension", it's flexible enough to work without UA support.

I've currently implemented the way that the admin can decide to:
   - never include Path in the reply
   - include Path in the reply if UA indicates support for Path
   - reply with 420 if UA doesn't indicate support for Path but a
     path header is present


> user must be able to make a call without first registering, which is
> another reason why what you propose doesn't work.

Why? A UA acting as caller or a UA acting as callee are two different 
scenarios here.
If the UA acts as caller, the intermediate proxies set a Record-Route 
for the INVITE if necessary and forward it to the next proxy. No Path 
header comes in here.
If the UA acts as callee, the home proxy knows from the Path header of 
the REGISTER the intermediate proxies which to traverse for the INVITE.

So I don't understand your point of view.

Andy