headers
Ramon Poca | 8 Oct 2009 14:39
Picon

Listening for OPTIONS asynchronously

Hi!

I've been using sipunit to test our B2BUA and related systems. One of 
the things I'd like to do is to listen for incoming OPTIONS requests 
(like those sent by NAT proxy modules) and answer them.

Could this be done? Could this be done ASYNCHRONOUSLY?

Regards,

--

-- 
*Ramon Poca*
ramon.poca <at> androme.es <mailto:ramon.poca <at> androme.es>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Permalink | Reply | 1 comment |
headers
becky mcelroy | 8 Oct 2009 15:42
Picon

Re: Listening for OPTIONS asynchronously

Hi Ramon,

Probably your best option for asynchronous handling is to use your own
SipStack class that extends org.cafesip.sipunit.SipStack and override the
processRequest() method to check for and process an OPTIONS request if the
received request is OPTIONS, else call super.processRequest(request).

Depending on your situation, it may be that you can use a SipPhone, calling
its listenRequestMessage() once and call its waitRequest(timeout) whenever
your program can go idle for some time ('timeout' amount of time). The
waitRequest() method will block your program ONLY IF no request has come in
since the last time you called it. Received requests are queued up
(beginning with the call to listenRequestMessage()), so if the queue has
something in it when you call waitRequest(), then waitRequest() returns
immediately with the first one in the queue.

Hope this helps-
Becky

On Thu, Oct 8, 2009 at 8:39 AM, Ramon Poca <ramon.poca <at> androme.es> wrote:

> Hi!
>
> I've been using sipunit to test our B2BUA and related systems. One of
> the things I'd like to do is to listen for incoming OPTIONS requests
> (like those sent by NAT proxy modules) and answer them.
>
> Could this be done? Could this be done ASYNCHRONOUSLY?
>
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ramon Poca | 8 Oct 2009 15:54
Picon

REGISTER/unREGISTER oddities

Hi there!

I've been using SIPUnit to test our SIP servlet, and found some oddities.

    *

      - SipPhone.unregister() seems not to be working when there is an
      authentication challenge/response.

    *
          o

            - SipPhone.register() loops indefinitely when authentication
            fails and a 401 is returned twice, instead of aborting when
            available credentials are exhausted.

          o

            - Due to the "unregister()" problem, I tried to use
            register() with an expires of 0, but then SipPhone does not
            set the header.

I've modified SipUnit locally to fix this, but I don't know wether this 
behaviour is intentional or not, as to submit a patch.

Are those by design?

--

-- 
*Ramon Poca*
ramon.poca <at> androme.es <mailto:ramon.poca <at> androme.es>
(Continue reading)

Permalink | Reply | 3 comments |
headers
becky mcelroy | 12 Oct 2009 03:47
Picon

Re: REGISTER/unREGISTER oddities

Hi Ramon,

No, those behaviors are not intentional. If you have the corrections handy
and can commit them to the sipunit 'patch' branch, that would be great! I'll
get them in.

Thanks for reporting and fixing that-
Becky

On Thu, Oct 8, 2009 at 9:54 AM, Ramon Poca <ramon.poca <at> androme.es> wrote:

> Hi there!
>
> I've been using SIPUnit to test our SIP servlet, and found some oddities.
>
>    *
>
>      - SipPhone.unregister() seems not to be working when there is an
>      authentication challenge/response.
>
>    *
>          o
>
>            - SipPhone.register() loops indefinitely when authentication
>            fails and a 401 is returned twice, instead of aborting when
>            available credentials are exhausted.
>
>          o
>
>            - Due to the "unregister()" problem, I tried to use
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ramon Poca | 19 Oct 2009 11:25
Picon

Re: REGISTER/unREGISTER oddities

Hi Becky,

My "corrections" are just to fix my tests, and I believe that the 
problem should be fixed better, but mainly are:

1) On org.cafesip.sipunit.SipPhone.register(SipURI requestUri, String 
user, String password, String contact, int expiry, long timeout)

Line: 323 (aprox)
Remove the if (expires != 0), and just set it even if is 0. An Expires 
of 0 causes an effective unregister()

2) On org.cafesip.sipunit.SipPhone.sendRegistrationMessage(Request msg, 
String user,
String password, long timeout)

Add a flag to check we don't loop indefinitely when receiving 401/407's 
from the server.

Line: 498 (aprox)
     private Response sendRegistrationMessage(Request msg, String user,
             String password, long timeout)
     {
+       boolean authenticationFailed = false;
         SipTransaction trans = sendRequestWithTransaction(msg, false, 
null);

Line: 590 (aprox)
                 response = ((ResponseEvent) response_event).getResponse();
                 status_code = response.getStatusCode();
(Continue reading)

Permalink | Reply | 1 comment |
headers
becky mcelroy | 23 Oct 2009 03:07
Picon

Re: REGISTER/unREGISTER oddities

Thank you Ramon!

On Mon, Oct 19, 2009 at 5:25 AM, Ramon Poca <ramon.poca <at> androme.es> wrote:

>  Hi Becky,
>
> My "corrections" are just to fix my tests, and I believe that the problem
> should be fixed better, but mainly are:
>
> 1) On org.cafesip.sipunit.SipPhone.register(SipURI requestUri, String user,
> String password, String contact, int expiry, long timeout)
>
> Line: 323 (aprox)
> Remove the if (expires != 0), and just set it even if is 0. An Expires of 0
> causes an effective unregister()
>
>
> 2) On org.cafesip.sipunit.SipPhone.sendRegistrationMessage(Request msg,
> String user,
> String password, long timeout)
>
> Add a flag to check we don't loop indefinitely when receiving 401/407's
> from the server.
>
> Line: 498 (aprox)
>     private Response sendRegistrationMessage(Request msg, String user,
>             String password, long timeout)
>     {
> +       boolean authenticationFailed = false;
>         SipTransaction trans = sendRequestWithTransaction(msg, false,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane