trying to REGISTER sailfin with some VOIP provider - IllegalStateException

[Brainwave]

Hi all,

I'm trying to make a piece of software that would register my sailfin instance within some VOIP provider. Perhaps I may be getting a little close to (mis)using SipServlet as a kind of client not a server, but why not...
So he communication would look like this:
sailfin        VOIP provider
REGISTER --->
<---- UNAUTHORISED (with nonce)
REGISTER---> (with authentication details)
<----- 200 OK

The first two messages work ok, now I have a problem with sending the second REGISTER. It should be (at least I want it to be) within the same SipSession (so it has the same call-id). The code is:

    protected void doErrorResponse(SipServletResponse response) throws ServletException, IOException {
        logger.severe("Session is in state:"+response.getSession().getState());
        logger.severe("creating request.");
        SipServletRequest request=response.getSession().createRequest("REGISTER");
        logger.severe("Request created:"+request.toString());
        logger.severe("Sending request.");
        request.send();
        logger.severe("Request Sent.");

And it gets to the createRequest where I get the IllegalStateException (cut&paste from server.log below). I can see that the session is in INITIAL state, but what I'm not sure of is if it is supposed to be in this state, or not.

I'm on version  b47, but I've tried b45 as well. Where do I make a mistake? Is it my mistake, or a kind of bug - in this case is there any known workaround for this?

Best regards,

Piotr

[#|2008-08-27T10:51:32.084+0200|SEVERE|sun-glassfish-comms-server1.0|pl.ngns.registrator.sip.MainServlet|_ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;_
RequestID=4b012f23-f966-418e-91c4-3c46c6b183ea;|Session is in state:INITIAL|#]

[#|2008-08-27T10:51:32.084+0200|SEVERE|sun-glassfish-comms-server1.0|pl.ngns.registrator.sip.MainServlet|_ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;_
RequestID=4b012f23-f966-418e-91c4-3c46c6b183ea;|creating request.|#]

[#|2008-08-27T10:51:32.085+0200|INFO|sun-glassfish-comms-server1.0|javax.enterprise.system.container.sip|_ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;|
Problem in servlet.
java.lang.IllegalStateException: Not allowed to create a request.
        at com.ericsson.ssa.sip.SipSessionImplBase.createRequestInitial(SipSessionImplBase.java:596)
        at com.ericsson.ssa.sip.SipSessionImplBase.createRequest(SipSessionImplBase.java:345)
        at pl.ngns.registrator.sip.MainServlet.doErrorResponse(MainServlet.java:48)
        at javax.servlet.sip.SipServlet.doResponse(SipServlet.java:183)
        at javax.servlet.sip.SipServlet.service(SipServlet.java:47)
        at com.ericsson.ssa.container.sim.SipServletFacade.service(SipServletFacade.java:85)
        at com.ericsson.ssa.sip.GeneralSession.dispatch(GeneralSession.java:200)
        at com.ericsson.ssa.sip.UA.dispatch(UA.java:672)
        at com.ericsson.ssa.container.sim.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:409)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:68)
        at com.ericsson.ssa.container.sim.ApplicationDispatcher.next(ApplicationDispatcher.java:523)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.sip.LocalRouteManager.next(LocalRouteManager.java:103)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.sip.DialogManager.next(DialogManager.java:668)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.sip.dns.ResolverManager.next(ResolverManager.java:247)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.sip.persistence.ReplicationManager.next(ReplicationManager.java:124)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.sip.transaction.TransactionManager.next(TransactionManager.java:345)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.container.GrizzlyNetworkManager.next(GrizzlyNetworkManager.java:936)
        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
        at com.ericsson.ssa.container.MessageProcessorFilter.processMessage(MessageProcessorFilter.java:400)
        at com.ericsson.ssa.container.MessageProcessorFilter.execute(MessageProcessorFilter.java:280)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.ericsson.ssa.container.GrizzlyNetworkManager$SharedCallbackHandler.onRead(GrizzlyNetworkManager.java:1670)
        at com.sun.grizzly.CallbackHandlerContextTask.doCall(CallbackHandlerContextTask.java:76)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
        at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)

[Binod]

Hi Piotr,

Can you try creating a new request using SipFactory and same  
SipApplicationSession and then add the authinfo?

thanks,
Binod.

On 27-Aug-08, at 3:01 PM, Brainwave wrote:

>
> Hi all,
>
> I'm trying to make a piece of software that would register my sailfin
> instance within some VOIP provider. Perhaps I may be getting a  
> little close
> to (mis)using SipServlet as a kind of client not a server, but why  
> not...
> So he communication would look like this:
> sailfin        VOIP provider
> REGISTER --->
> <---- UNAUTHORISED (with nonce)
> REGISTER---> (with authentication details)
> <----- 200 OK
>
> The first two messages work ok, now I have a problem with sending  
> the second
> REGISTER. It should be (at least I want it to be) within the same  
> SipSession
> (so it has the same call-id). The code is:
>
>    protected void doErrorResponse(SipServletResponse response) throws
> ServletException, IOException {
>        logger.severe("Session is in
> state:"+response.getSession().getState());
>        logger.severe("creating request.");
>        SipServletRequest
> request=response.getSession().createRequest("REGISTER");
>        logger.severe("Request created:"+request.toString());
>        logger.severe("Sending request.");
>        request.send();
>        logger.severe("Request Sent.");
>
> And it gets to the createRequest where I get the IllegalStateException
> (cut&paste from server.log below). I can see that the session is in  
> INITIAL
> state, but what I'm not sure of is if it is supposed to be in this  
> state, or
> not.
>
> I'm on version  b47, but I've tried b45 as well. Where do I make a  
> mistake?
> Is it my mistake, or a kind of bug - in this case is there any known
> workaround for this?
>
> Best regards,
>
> Piotr
>
> [#|2008-08-27T10:51:32.084+0200|SEVERE|sun-glassfish-comms-server1.0|
> pl.ngns.registrator.sip.MainServlet|
> _ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;_
> RequestID=4b012f23-f966-418e-91c4-3c46c6b183ea;|Session is in
> state:INITIAL|#]
>
> [#|2008-08-27T10:51:32.084+0200|SEVERE|sun-glassfish-comms-server1.0|
> pl.ngns.registrator.sip.MainServlet|
> _ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;_
> RequestID=4b012f23-f966-418e-91c4-3c46c6b183ea;|creating request.|#]
>
> [#|2008-08-27T10:51:32.085+0200|INFO|sun-glassfish-comms-server1.0|
> javax.enterprise.system.container.sip|
> _ThreadID=22;_ThreadName=SipContainer-clientsWorkerThread-5060-8;|
> Problem in servlet.
> java.lang.IllegalStateException: Not allowed to create a request.
>        at
> com
> .ericsson
> .ssa
> .sip.SipSessionImplBase.createRequestInitial(SipSessionImplBase.java:
> 596)
>        at
> com
> .ericsson
> .ssa.sip.SipSessionImplBase.createRequest(SipSessionImplBase.java:345)
>        at
> pl.ngns.registrator.sip.MainServlet.doErrorResponse(MainServlet.java:
> 48)
>        at javax.servlet.sip.SipServlet.doResponse(SipServlet.java:183)
>        at javax.servlet.sip.SipServlet.service(SipServlet.java:47)
>        at
> com
> .ericsson
> .ssa.container.sim.SipServletFacade.service(SipServletFacade.java:85)
>        at
> com.ericsson.ssa.sip.GeneralSession.dispatch(GeneralSession.java:200)
>        at com.ericsson.ssa.sip.UA.dispatch(UA.java:672)
>        at
> com
> .ericsson
> .ssa
> .container
> .sim.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:409)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:68)
>        at
> com
> .ericsson
> .ssa
> .container.sim.ApplicationDispatcher.next(ApplicationDispatcher.java:
> 523)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com.ericsson.ssa.sip.LocalRouteManager.next(LocalRouteManager.java:
> 103)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at com.ericsson.ssa.sip.DialogManager.next(DialogManager.java:
> 668)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com.ericsson.ssa.sip.dns.ResolverManager.next(ResolverManager.java:
> 247)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com
> .ericsson
> .ssa.sip.persistence.ReplicationManager.next(ReplicationManager.java:
> 124)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com
> .ericsson
> .ssa.sip.transaction.TransactionManager.next(TransactionManager.java:
> 345)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com
> .ericsson
> .ssa.container.GrizzlyNetworkManager.next(GrizzlyNetworkManager.java:
> 936)
>        at com.ericsson.ssa.sip.LayerHelper.next(LayerHelper.java:75)
>        at
> com
> .ericsson
> .ssa
> .container
> .MessageProcessorFilter.processMessage(MessageProcessorFilter.java:
> 400)
>        at
> com
> .ericsson
> .ssa
> .container
> .MessageProcessorFilter.execute(MessageProcessorFilter.java:280)
>        at
> com
> .sun
> .grizzly
> .DefaultProtocolChain
> .executeProtocolFilter(DefaultProtocolChain.java:137)
>        at
> com
> .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
> 104)
>        at
> com
> .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
> 90)
>        at
> com.ericsson.ssa.container.GrizzlyNetworkManager
> $SharedCallbackHandler.onRead(GrizzlyNetworkManager.java:1670)
>        at
> com
> .sun
> .grizzly
> .CallbackHandlerContextTask.doCall(CallbackHandlerContextTask.java:76)
>        at
> com
> .sun
> .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>        at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>
>
> --
> View this message in context: http://www.nabble.com/trying-to-REGISTER-sailfin-with-some-VOIP-provider---IllegalStateException-tp19177567p19177567.html
> Sent from the SailFin - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brainwave]

Yep, I did try this. The problem is that the request that is created gets a new call-id - so the authorization does not work (nonce that is sent by the provider is probably correlated with call-id rather than username or something). So the bottom line is - it has to be created in the very same SipSession.

Any idea?

Best Regards,

Piotr

Binod wrote:

Hi Piotr,

Can you try creating a new request using SipFactory and same  
SipApplicationSession and then add the authinfo?

thanks,
Binod.

[cut]

[sankara rao bhogi]

Brainwave wrote:
> Yep, I did try this. The problem is that the request that is created gets a
> new call-id - so the authorization does not work (nonce that is sent by the
> provider is probably correlated with call-id rather than username or
> something). So the bottom line is - it has to be created in the very same
> SipSession.
>
> Any idea?
>  
You could try

SipServletRequest <cid:part1.09050105.05090709@...> *createRequest*(SipServletRequest <cid:part1.09050105.05090709@...> origRequest,
                                boolean sameCallId)


Please note that this method is deprecated as it is not legal to create
another request with the same call id.

regards
sankar

> Best Regards,
>
> Piotr
>
>
>
> Binod wrote:
>  
>> Hi Piotr,
>>
>> Can you try creating a new request using SipFactory and same  
>> SipApplicationSession and then add the authinfo?
>>
>> thanks,
>> Binod.
>>
>> [cut]
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brainwave]

Thanks sankar, however as I'm just learning how to use the server, I'd prefer not to use deprecated methods. Anyway I made some progress in a way.

The state of SipSession (INITIAL) seems to be right (looking at the state machine in JSR fig 6-2). The JSR specs also say:

The INITIAL state is introduced to allow a UAC to generate multiple requests with the same Call-ID, From (including tag), and To (excluding tag), and within the same CSeq space. This is useful, for example, in the following situations:
[cut]
REGISTER requests sent from a UAC to the same registrar should all use the same Call-ID header field value and should increment the CSeq by one for each request sent [RFC 3261, section 10.2].

So that is the situation I'm in. So for now it seems for me like a bug. I also looked at the SipSessionImplBase, and it looks like this scenario is not handled well. I get the IllegalStateException exception because in createRequestInitial method a tmpCallData variable is checked:

private SipServletRequest createRequestInitial(String method) {
        if (!isValid()) {
            throw new IllegalStateException("The session is not valid.");
        }
        if (tmpCallData != null) {
[cut]
        } else {
            throw new IllegalStateException("Not allowed to create a request.");
        }

and tmpCallData is initiated only inside a private void reset() method which is invoked only inside updateSipSessionState method in case the state is EARLY (in my case the state is still INITIAL), and (cut&paste from the method):

                    if (((type == Type.Caller) || (type == Type.Proxy)) &&
                        ((status >= 300) && (status <= 699)) &&
                        SipFactoryImpl.isDialogCreational(method)) {
                    if ((type == Type.Caller)) {
                        reset();
                    }

So basically the code works as it is. Can anyone confirm that I'm right and that it is a bug?

Best Regards,

Piotr

sankara rao bhogi wrote:

Brainwave wrote:
> Yep, I did try this. The problem is that the request that is created gets a
> new call-id - so the authorization does not work (nonce that is sent by the
> provider is probably correlated with call-id rather than username or
> something). So the bottom line is - it has to be created in the very same
> SipSession.
>
> Any idea?
>  
You could try

SipServletRequest <cid:[e-mail]> *createRequest*(SipServletRequest <cid:[e-mail]> origRequest,
                                boolean sameCallId)


Please note that this method is deprecated as it is not legal to create
another request with the same call id.

regards
sankar
> Best Regards,
>
> Piotr
>
>
>
> Binod wrote:
>  
>> Hi Piotr,
>>
>> Can you try creating a new request using SipFactory and same  
>> SipApplicationSession and then add the authinfo?
>>
>> thanks,
>> Binod.
>>
>> [cut]
>>
>>
>>    
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[venu-2]

Hi Piotr,

Brainwave wrote:
> Yep, I did try this. The problem is that the request that is created gets a
> new call-id - so the authorization does not work

Could be a bug , can you create a test case reproducing the
authorization failure and file a bug
> (nonce that is sent by the
> provider is probably correlated with call-id rather than username or
> something). So the bottom line is - it has to be created in the very same
> SipSession.
>  


Regards
Venu

> Any idea?
>
> Best Regards,
>
> Piotr
>
>
>
> Binod wrote:
>  
>> Hi Piotr,
>>
>> Can you try creating a new request using SipFactory and same  
>> SipApplicationSession and then add the authinfo?
>>
>> thanks,
>> Binod.
>>
>> [cut]
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Binod]

On 28-Aug-08, at 8:54 AM, Venu wrote:

> Hi Piotr,
>
> Brainwave wrote:
>> Yep, I did try this. The problem is that the request that is  
>> created gets a
>> new call-id - so the authorization does not work
>
> Could be a bug , can you create a test case reproducing the
> authorization failure and file a bug


https://sailfin.dev.java.net/issues/show_bug.cgi?id=1113

Filed this issue.

- Binod.

>
>> (nonce that is sent by the
>> provider is probably correlated with call-id rather than username or
>> something). So the bottom line is - it has to be created in the  
>> very same
>> SipSession.
>>
>
>
> Regards
> Venu
>> Any idea?
>>
>> Best Regards,
>>
>> Piotr
>>
>>
>>
>> Binod wrote:
>>
>>> Hi Piotr,
>>>
>>> Can you try creating a new request using SipFactory and same
>>> SipApplicationSession and then add the authinfo?
>>>
>>> thanks,
>>> Binod.
>>>
>>> [cut]
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brainwave]

I've just did it in the morning - issue 1112...

Best Regards

Piotr

Binod wrote:

On 28-Aug-08, at 8:54 AM, Venu wrote:

> Hi Piotr,
>
> Brainwave wrote:
>> Yep, I did try this. The problem is that the request that is  
>> created gets a
>> new call-id - so the authorization does not work
>
> Could be a bug , can you create a test case reproducing the
> authorization failure and file a bug


https://sailfin.dev.java.net/issues/show_bug.cgi?id=1113

Filed this issue.

- Binod.

>
>> (nonce that is sent by the
>> provider is probably correlated with call-id rather than username or
>> something). So the bottom line is - it has to be created in the  
>> very same
>> SipSession.
>>
>
>
> Regards
> Venu
>> Any idea?
>>
>> Best Regards,
>>
>> Piotr
>>
>>
>>
>> Binod wrote:
>>
>>> Hi Piotr,
>>>
>>> Can you try creating a new request using SipFactory and same
>>> SipApplicationSession and then add the authinfo?
>>>
>>> thanks,
>>> Binod.
>>>
>>> [cut]
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]