Skip to main content

Sip RA so called alpha

3 replies [Last post]
Joined: 2006-01-09
Points: 0

Hey. Together with Ivelin we agreed on making small step towards releasing RA.
So far SIP ra entered stage when no new features will be added. Code is pretty stable.
Last changes are goint to be commited when new stack is introduced (except debug changes,proxy/cancel logic activity handling )

One new property has been intriduced:
which specifies timeout in miliseconds for dialog session. After that time, if no message is received on dialog activity ( or corresponding TXs) dialog is considered to be timed out and thus expunged.
( I was not sure but it looks like good idea to send BYE to dialog that is going to be expunged when it timeouts, like in rfc 4028 - what do You think?)

I would like to make few points to start discussion:
- is there any "no" vot eto move new RA into MC repo? Old ra can be checked out any way via tag or branch, right ?
- are there any requests/wishes to what new proxy/registrar should allow/do ??

If anything works not as it should, let me know.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-05-13
Points: 0

Hi Baretek,
given the fact that the new resource adaptor has a different ra type and that JAIN SLEE support versioning, the two resource adaptors can coexist in the mobicents repository.

Joined: 2006-01-09
Points: 0

yes, two ras can coegsist - but for now both must use mux.
Yes - both direction are ( should work, cant see point where shouldnt) supportet, I mean send and rcv.
I have added jar file to sourceforge package to give a taste for sip ra. Im moving to to other issues - first will be to give RA a way to create dialogs automaticly.

There is also some new code in cancel handling it has been slightly altered to give sbb chance to process INVITE before CANCEL logic takes over everything. (There is new property which is reponsibl for how much RA will wait)

Joined: 2005-03-01
Points: 0


1) it sounds like you're talking about a MAX_IDLE_TIME instead of a TIMEOUT (the name is confusing to me)

2) shouldn't it be receive *or send*, instead of only receive?