[sip-comm] 3GPP sip-communicator


#1

Yes I was not very clear on this point :wink:
My question was: Is there a kind of state machine that controls SIP
messages sequences? This would allow to switch between IETF and 3GPP
behaviour and to control properly transactions.

So for the present time, the model is only transactional, isn't it? You
receive a message and you send the relevant response without considering
the session on its own. In fact, for testing, the transactional model is
really sufficient and easier to implement so that is ok.

Thanks Emil, I will let you know what is going on the 3GPP side,

Pierre-Antoine

路路路

-----Original Message-----
From: Emil Ivov [mailto:emil_ivov@yahoo.com]
Sent: 23 October 2003 20:55
To: ANTONINI Pierre-Antoine FTRD/DMR/LON
Cc: users@sip-communicator.dev.java.net
Subject: Re: [sip-comm] 3GPP sip-communicator

Hello Pierre-Antoine,

I would like to add some 3GPP features to the SIP-communicator.

I am really glad to hear that. It'd be nice to let us know how things
are going and whether sip communicator behaves properly in such an
environment. In any case, don't hesitate to ask should any problems
occur.

For the implementation of 183Session,PRACK, UPDATE, ....shall I only
need to add some methods in the class callProcessing.java such as
processPrack,processUpdate or are there other changes to make?

On first thought, I don't see anything else that would need to be
touched. All 3 messages should be accepted by the stack, as a normal
provisional response (for 183Session Progress) and non INVITE requests
for PRACK and UPDATE. You should just make sure that your
processXxx() methods are called from SipManager.processResponse() and
SipManager.processRequest()

In fact is there a control on swapped SIP messages (I mean, do they
have to respect any given order according to a state machine) or
implementing processing classes is sufficient?

... I didn't really understand that question. Apart from the 183 Session
Progress response which needs to be sent only while the INVITE
transaction is in its Calling/Proceeding state, PRACK and UPDATE will be
normally handled whenever they arrive. Make sure that you send the OK
responses in the same server transaction as the PRACK/UPDATE request.

Hope this helps.

Cheers
Emil

http://www.emcho.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#2

Hello Pierre-Antoine,

Yes I was not very clear on this point :wink:
My question was: Is there a kind of state machine that controls SIP
messages sequences? This would allow to switch between IETF and 3GPP
behaviour and to control properly transactions.

So for the present time, the model is only transactional, isn't it?

Not quite. You also have dialogs. Dialogs are identified through a
dialog ID, which consists of the Call-ID and From and To tags. In your
case an Early State Dialog will be created with the 183 response.
Following UPDATE and PRACK requests would need to be in the same
dialog. In jain-sip you can extract the dialog from the transaction
and then simply use its Dialog.sendRequestMethod() to make sure that
your requests gets the appropriate tags and call id.

Thanks Emil, I will let you know what is going on the 3GPP side,

That'd be nice, thanks.

Cheers
Emil

路路路

-----Original Message-----
From: Emil Ivov [mailto:emil_ivov@yahoo.com]
Sent: 23 October 2003 20:55
To: ANTONINI Pierre-Antoine FTRD/DMR/LON
Cc: users@sip-communicator.dev.java.net
Subject: Re: [sip-comm] 3GPP sip-communicator

Hello Pierre-Antoine,

I would like to add some 3GPP features to the SIP-communicator.

I am really glad to hear that. It'd be nice to let us know how things
are going and whether sip communicator behaves properly in such an
environment. In any case, don't hesitate to ask should any problems
occur.

For the implementation of 183Session,PRACK, UPDATE, ....shall I only
need to add some methods in the class callProcessing.java such as
processPrack,processUpdate or are there other changes to make?

On first thought, I don't see anything else that would need to be
touched. All 3 messages should be accepted by the stack, as a normal
provisional response (for 183Session Progress) and non INVITE requests
for PRACK and UPDATE. You should just make sure that your
processXxx() methods are called from SipManager.processResponse() and
SipManager.processRequest()

In fact is there a control on swapped SIP messages (I mean, do they
have to respect any given order according to a state machine) or
implementing processing classes is sufficient?

... I didn't really understand that question. Apart from the 183 Session
Progress response which needs to be sent only while the INVITE
transaction is in its Calling/Proceeding state, PRACK and UPDATE will be
normally handled whenever they arrive. Make sure that you send the OK
responses in the same server transaction as the PRACK/UPDATE request.

Hope this helps.

Cheers
Emil

http://www.emcho.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

Cheers
Emil

http://www.emcho.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net