Skip to main content

SIP services adjustment

14 replies [Last post]
baranowb
Offline
Joined: 2006-01-09
Points: 0

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)

Process Request
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

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

16.6.5
* configurable(1) optional headers

16.6.6
* configurable(1) sorted set of "must pass through" sip proxies

16.6.7
* it dont understand how this could be of use to anyone, any scenarios?

16.6.8
* 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
-third 200

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.

Any comments?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivelin
Offline
Joined: 2003-07-13
Points: 0

>
> 16.4 "Route Information Preprocessing" talks about
> maddr.
> I am having hard time reading the text here as well.
> Probably a good question for the JAIN SIP interest
> list.
> It is clear that if maddr points to a domain, which
> the proxy is responsible for, then the pointer should
> be stripped and the message forwarded. It is not
> clear however what needs to happen if maddr does not
> point to a domain that the proxy is responsible for.
> Should the request be rejected or forwarded without
> any action?

I take my confusion back. The next section in the RFC is very clear on what needs to be done with maddr: 16.5 "Determining Request Targets".

ivelin
Offline
Joined: 2003-07-13
Points: 0

> 16.4
> * add lr param to Record - Route - configurable it
> can be present, but it doesnt have to, - now its not
> added

lr param is not mentioned in 16.4. The earliest I see lr is in 16.6.4. If you refer to 16.6.4 "Record-Route", then my take is that since its an extension mechanism for backward compatibility, we don't have to add it at this stage, but can make a TODO note in the code.

> * 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.4 "Route Information Preprocessing" talks about maddr.
I am having hard time reading the text here as well. Probably a good question for the JAIN SIP interest list.
It is clear that if maddr points to a domain, which the proxy is responsible for, then the pointer should be stripped and the message forwarded. It is not clear however what needs to happen if maddr does not point to a domain that the proxy is responsible for. Should the request be rejected or forwarded without any action?

mranga
Offline
Joined: 2003-06-06
Points: 0

> > 16.4
> > * add lr param to Record - Route - configurable it
> > can be present, but it doesnt have to, - now its
> not
> > added
>
> lr param is not mentioned in 16.4. The earliest I see
> lr is in 16.6.4. If you refer to 16.6.4
> "Record-Route", then my take is that since its an
> n extension mechanism for backward compatibility, we
> don't have to add it at this stage, but can make a
> TODO note in the code.

lr should be added to the Record-Route header.

>
> > * 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.4 "Route Information Preprocessing" talks about
> maddr.
> I am having hard time reading the text here as well.
> Probably a good question for the JAIN SIP interest
> list.
> It is clear that if maddr points to a domain, which
> the proxy is responsible for, then the pointer should
> be stripped and the message forwarded. It is not
> clear however what needs to happen if maddr does not
> point to a domain that the proxy is responsible for.
> Should the request be rejected or forwarded without
> any action?

Local policy dependent I expect. I dont think anything forbids you from forwarding the request statelessly.

ivelin
Offline
Joined: 2003-07-13
Points: 0

> > 16.4 "Route Information Preprocessing" talks about
> > maddr.
> > I am having hard time reading the text here as
> well.
> > Probably a good question for the JAIN SIP interest
> > list.
> > It is clear that if maddr points to a domain,
> which
> > the proxy is responsible for, then the pointer
> should
> > be stripped and the message forwarded. It is not
> > clear however what needs to happen if maddr does
> not
> > point to a domain that the proxy is responsible
> for.
> > Should the request be rejected or forwarded
> without
> > any action?
>
> Local policy dependent I expect. I dont think
> anything forbids you from forwarding the request
> statelessly.

That's exactly my read.

Forwarding statelessly makes sense when the proxy is not responsible for the domain in maddr, but when it is, then it should use some local policy (location service as mentioned in 16.5) to determine the end point that should receive the message. If no local policy applies, it should respond with "Ambiguous request" (detailed in 16.5.).

jbemmel
Offline
Joined: 2005-03-01
Points: 0

Some comments on some of the above features:

- timer C: this is an absolute MUST HAVE. Without this, the system will collect stale INVITE transactions over time (ie INVITEs for which no final response was received), and it eventually runs out of memory

- 'lr' parameter: always set this on Record-Route headers, not setting it is simply wrong

- loop detection: you can do without this for the moment, it's tricky to get right

- 'maddr' : not commonly used any more, except in multicast scenario's - can leave it out

ivelin
Offline
Joined: 2003-07-13
Points: 0

very valuable input from someone close to SIP implementations and a key JSIP RI developer.
jbemmel, thanks a lot.

> Some comments on some of the above features:
>
> - timer C: this is an absolute MUST HAVE. Without
> this, the system will collect stale INVITE
> transactions over time (ie INVITEs for which no final
> response was received), and it eventually runs out of
> memory
>
> - 'lr' parameter: always set this on Record-Route
> headers, not setting it is simply wrong
>
> - loop detection: you can do without this for the
> moment, it's tricky to get right
>
> - 'maddr' : not commonly used any more, except in
> multicast scenario's - can leave it out

ivelin
Offline
Joined: 2003-07-13
Points: 0

> 16.3.5 - Proxy Reuquire
> * configurable(1) set of values, or certain criteria
> that message has to match to add this header?

Its not clear what you don't understand. The text in the rfc seems clear to me. The implementation should always return 420 (Bad Extension) if there is a Proxy-Require header field with any unknown option tags.
Our initial implementation doesn't need to allow configurable list of such option tags.

> 16.3.6 - Proxy - Authorization
> * configurable(1) set of values/criteria when request
> needs to be authorized to be passed

We don't have to worry about authorizing proxy requests. This is typically the work of Session Border Control servers. Can be added to the implementation with a TODO comment and see how much user demand there is for it.

ivelin
Offline
Joined: 2003-07-13
Points: 0

The primary goal for the next release of the SIP Proxy & Registrar should be to make them compatible with SIP RA 1.2. New features should be scheduled for a release after that.

Further comments below:

> (numbers are sections and subsections of rfc - these
> are also listed in proxy src)
>
> Process Request
> 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

Yes. Even though this is an optional feature, we should schedule a task in bugzilla to implement it. Doesn't have to be implemented for the next release of the proxy.

> * 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
> 16.6.8 is pointed as sollution, but I cant understand
> it clearly.

The text sounds conceptually clear. There are multiple fields that the proxy needs to set if it chooses to deal with loops and spirals. If none of these fields changed by the time the message comes back to the proxy, then its a loop case and the message should be stopped with the appropriate response; if some of the fields have changed then the message went through other hops before coming back to the proxy and this is a spiral, the message should be forwarded on.

Of course the devil is in the details of implementing the right fields and making sure that the spiraling test works with other popular proxies.

This is a feature, which is optional and should be scheduled for a future release (maybe 1.2.1).

ivelin
Offline
Joined: 2003-07-13
Points: 0

responding in multiple parts to not clutter the messages:

> 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?)

Yes, stateful proxy will be a primary scenario within JSLEE environment.

I would think however that a stateless proxy should also be an option for high performance scenarios. Do you think stateless proxy will not be a common use case within JSLEE?

mranga
Offline
Joined: 2003-06-06
Points: 0

> responding in multiple parts to not clutter the
> messages:
>
> > 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?)
>
> Yes, stateful proxy will be a primary scenario within
> JSLEE environment.

I am not sure. What is the target use case? Is it for a PBX ? Stateful proxy is going to be slower and less scalable. Stateless proxy servers are not able detect certain errors in routing. ( Do you care? ) A call stateful ( not necessarily Transaction Stateful ) proxy that tracks only Call IDs and not transactions or Dialogs may be the thing to aim for.

>
> I would think however that a stateless proxy should
> also be an option for high performance scenarios. Do
> you think stateless proxy will not be a common use
> case within JSLEE?

ivelin
Offline
Joined: 2003-07-13
Points: 0

> > Yes, stateful proxy will be a primary scenario
> within
> > JSLEE environment.
>
> I am not sure. What is the target use case? Is it for
> a PBX ?

PBX is one application. Another one would be Rule based routing. For example calls for acme.com should be limited to 10 per minute. Is this something that you wouldn't do in a stateful proxy?

> Stateful proxy is going to be slower and
> less scalable.

Clearly. That is why I am thinking that stateless should be an option as well.

> Stateless proxy servers are not able
> detect certain errors in routing. ( Do you care? )

Not terribly.

> call stateful ( not necessarily Transaction Stateful
> ) proxy that tracks only Call IDs and not
> transactions or Dialogs may be the thing to aim for.

I think I agree with the concept. Can you clarify the difference between call stateful vs. dialog stateful.

mranga
Offline
Joined: 2003-06-06
Points: 0

> > > Yes, stateful proxy will be a primary scenario
> > within
> > > JSLEE environment.
> >
> > I am not sure. What is the target use case? Is it
> for
> > a PBX ?
>
> PBX is one application. Another one would be Rule
> based routing. For example calls for acme.com should
> be limited to 10 per minute.

Easy - just dont allow acme.com to own more than 10 distinct call ids.

Is this something that
> you wouldn't do in a stateful proxy?
>
> > Stateful proxy is going to be slower and
> > less scalable.
>
> Clearly. That is why I am thinking that stateless
> should be an option as well.
>
> > Stateless proxy servers are not able
> > detect certain errors in routing. ( Do you care? )
>
>
> Not terribly.
>
> > call stateful ( not necessarily Transaction
> Stateful
> > ) proxy that tracks only Call IDs and not
> > transactions or Dialogs may be the thing to aim
> for.
>
> I think I agree with the concept. Can you clarify the
> difference between call stateful vs. dialog stateful.

Call stateful would simply track new callIds and treat everything else statelessly. Consequently, it could not do anything about stray responses (not matching a transaction or arriving late). It cannot distinguish between spirals and loops (I believe - Jeroen can correct me if he is listening). You would simply decrement Max-Forwards to avoid endless looping. You cannot handle call forking at the proxy server ( the end-point has to handle its own forked calls - not every endpoint will have that capability ).

In essence, its just essentially a forwarding agent. Request comes in - slap on record route. Add Via and off it goes. Once your call setup is authenticated ( which you can do statefully ), you keep no more transaction state - just call state. A table that maps call ID to some record for the on-going call is all you need. Because you keep no transaction state, timer C is not needed ( there is no transaction state to discard ).

Transaction stateful would create transactions (not dialogs). The advantages are that you could detect errors in routing better. You can handle call forking at the proxy.

Dialog stateful would create transactions and Dialogs. It is a Back to Back User Agent (B2BUA). Advantages are that you can handle firewall easily. Disadvantages are overhead.

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> > > > Yes, stateful proxy will be a primary scenario
> > > within
> > > > JSLEE environment.
> > >
> > > I am not sure. What is the target use case? Is
> it
> > for
> > > a PBX ?

The use case for stateful proxy on J2EE is much more basic than that: as soon as you want to do some processing that takes longer than say 200ms (e.g. database calls, Web services), and/or needs to be done only once (e.g. generate a CDR), you need to create a transaction to filter retransmissions (for UDP at least)

> Call stateful would simply track new callIds and
> treat everything else statelessly. Consequently, it
> could not do anything about stray responses (not
> matching a transaction or arriving late). It cannot
> distinguish between spirals and loops (I believe -
> Jeroen can correct me if he is listening).

Actually, a stateless proxy can do that too, by putting enough state within the SIP request itself (ie in the Via header).

> You would
> simply decrement Max-Forwards to avoid endless
> looping. You cannot handle call forking at the proxy
> server ( the end-point has to handle its own forked
> calls - not every endpoint will have that capability
> ).
>
> In essence, its just essentially a forwarding agent.
> Request comes in - slap on record route. Add Via and
> off it goes. Once your call setup is authenticated (
> which you can do statefully ),

I think you mean statelessly here

> you keep no more
> transaction state - just call state. A table that
> maps call ID to some record for the on-going call is
> all you need. Because you keep no transaction state,
> timer C is not needed ( there is no transaction state
> to discard ).
>
> Transaction stateful would create transactions (not
> dialogs). The advantages are that you could detect
> errors in routing better. You can handle call forking
> at the proxy.
>
> Dialog stateful would create transactions and
> Dialogs. It is a Back to Back User Agent (B2BUA).
> Advantages are that you can handle firewall easily.
> Disadvantages are overhead.

There is also an "in-between" form: in IMS, the S-CSCF for example needs to keep enough state to be able to generate a BYE request both ways. So it needs the call-id, from/to including tags, track Cseqs, ... However, it does not need to create 2 Dialogs (in fact, it is forbidden to do that)

baranowb
Offline
Joined: 2006-01-09
Points: 0

seems as this topic didnt draw any attention.
I have created wiki page with some simple class diagrams:
http://wiki.java.net/bin/view/Main/Baranowb
Hope this will explain what I had in mind here.