SIP services adjustment
I took some time looking into src of current proxy and interaction with registarar, and ofcourse infamous rfc 3261.
and some que
Here is what is not done already and should be to make current proxy complete stateful proxy(this is our goal right?)
and soem question born during that time. Ok so here it goes:
(numbers are sections and subsections of rfc - these are also listed in proxy src)
16.3.4 - Loop detection:
* proxy adds param(?) to Via header - thanks to this it can detect if request has been processed by this node before
* spiraling - if proxy detects param that it has set it means that this request is either looping (discard) or spraling:
- if i is spiraling how it is detected? 16.6.8 is pointed as sollution, but I cant understand it clearly.
16.3.5 - Proxy Reuquire
* configurable(1) set of values, or certain criteria that message has to match to add this header?
16.3.6 - Proxy - Authorization
* configurable(1) set of values/criteria when request needs to be authorized to be passed
* add lr param to Record - Route - configurable it can be present, but it doesnt have to, - now its not added
* maddrr value (its added now)- what does it exaclt does in Record-Route header? Normaly it specifies address where reqeust/response should be sent
if it is specified in Fro/To headers ? But here?
16.5 Finding new targets
* If we have more than one target the message is forked, here we have to create "Response context" - meaning we need something that will have trace of all
CTx associated with original STx that was created by original request. Using InitialEventSelector that sets custom name as call-Id (and possibly plus From tag value?)
as good idea - CTxs and STx can have that in common, right? This way we will have one proxysbb entity to handle forward.
* configurable(1) optional headers
* configurable(1) sorted set of "must pass through" sip proxies
* it dont understand how this could be of use to anyone, any scenarios?
* add Contnet-Length if not present - cl header should contain length of message body - how this is computed? It this byte count? javadoc for Cl header contains reference to section 4.4 of rfc 2616
How does this fit to CL in sip?
16.6.11 Timer - C
- What is that? This is VERY vaguely described, no examples etc.
16.7 Process Response
16.7.1 - Find response context - IES = Call-ID + ?
16.7.2 - Update C-Timer =???
16.7.4-6 - DOnt fully understand those points. It not said straight but:
- if some response comes proxy waits for all other CTx to receive response
- if 2xx, 6xx and 1xx ( except 100) is received it is forwarded immediatly, right? And some actions are performed on other txs
For instance if we have 4 CTxs
-first receives for isntance 406 Reponse
-second receives 300
200 is forwarded back, all other pending tx's are terminated/canceled, 406 response is discarded, fourth CTx doesnt have chance to receive response since it is canceled/terminated
16.7.7 Autohrization aggregation
* aggregates all Auth Require headers from responses - do we need to to something special here? For isntance keep track of nodes that require auth?
16.7.8 - optional Rewrite Record-Route
*configurable(1) set of pairs "target domain" - "proxy name in domain"
Correct me if Im wrong.
Also it seem good idea to provide SbbLocalInterface that has to be implemented by Sbb that will act as registrar service for proxy. Now proxy is tightly coupled with location service. However if we provide such interface anyone can implement his own location service
as sbb. This way switching between different impl of location service woule be very easy - simply change sb-ref in child relation in sbb-jar.xml, right?
Also it seems good idea to do the same with registrar, wouldnt it?
One more issue remains - sip ra 1.2, automatic dialog creation and proxy?
How does this relate to each other? I mean if we have service that creates dialog proxy wont receive event since it will be fired as "in dialog". This happens because RA determines whaether in dialog event can be received. However at that moment it doesnt have any knowledge if it will be processed. If its not, dialog could be created (if it is INVITE request) anyway - possible solution is to make RA check if that INVITE was processed successfuly, if not it should fire again that event, as not in dialog event.
Secodn solution would be to change slitghtly design and make RA fire events when they are expected, I mean if RA detects that both 1.1 and 1.2 are expected it will fire both , but this can lead to some ambiguity.