[Serusers] Record-Route and Route parameters patch

[Bogdan-Andrei Iancu]

We are all aware of SER limitation due the fact it is *only* transaction 
statefull at proxy level, any dialog support being missing. There are 
many features/services which actually requires a dialog awareness, like 
storing the information in the dialog creation stage, information which 
will be used during the whole dialog existence.
The most urging example is NAT traversal, in dealing with the within the 
dialog INVITEs (re-INVITEs). When processing the initial INVITE, the 
proxy detects if the caller or callee is behind some NAT and fixes the 
signalling and media parts - since not all the detection mechanism are 
available for within the dialog requests (like usrloc), to be able to 
fix correspondingly the sequential requests, the proxy must remember 
that the original request was NAT processed.
There are many other cases where dialog awareness fixes or helps....it's 
not my goal to make a list here....

The solution is to store additional dialog-related information in the 
routing set, headers which show up in all sequential requests; by 
routing set I would say the Route hdrs and RURI; the routing set is 
build based on Record-Route and Contact hdrs.
So far, the way to go was using the Contact header (via parameters) as 
carrier. In most of the cases works, but this mechanism is not RFC 
reinforced - I had a talk with Juha and he found some phones which 
actually ignore the Contact hdr parameters, which is perfect allowed by 
RFC....Not to mention that which Contact hdr (UAC or UAS) appear in 
routing info depends on the request direction (UAC->UAS or UAS->UAC) and 
Record-Route parameters are re-infonced by RFC (see 12.1.1 UAS behavior)

So the next try is to add this information in the Record-Route header 
inserted by the proxy. Within the dialog, this information can be found 
(with no direction dependencies) in Route header (with or proxy address)...

And here is a patch for the RR module which adds this functionality:

1) adding parameters to Record-Route; since RR is inserted during req. 
processing (as lump), no textops function can be apply to it. So use the 
add_rr_param("param") function - it can be called also before or after 
the record_route() call; I would say it's more convenient from scripting 
point of view (no dependencies between doing record_route() and adding 
params);

2) checking Route parameters: this could be done via textops, but it 
would be dangerous -> you have to identify the Route header 
corresponding to your proxy (which will be quite difficult to put as 
regexp), So use check_route_param("regexp") function which will check 
the proper Route parameters against the given regexp. Must be call after 
loose_route().

Basic scenario (example):

UAC                                SER 
PROXY                                        UAS

   ------ INVITE ---------->      record_route()          --------- 
INVITE -------->
                              add_rr_param(";foo=true")

   ----- reINVITE --------->       loose_route()          -------- 
reINVITE ------->
                            check_route_param(";foo=true")

   <---- reINVITE ----------       loose_route()          <------- 
reINVITE --------
                            check_route_param(";foo=true")

   <-------- BYE -----------       loose_route()          <--------- BYE 
-----------
                            check_route_param(";foo=true")

The patch doesn't alter any of the previous functionality.
Jan take a look and let's put it on CVS.

bogdan





-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rr.patch
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050415/5dc56a89/attachment.txt>