Skip to main content

Pending Messages Design. [Re: B2B proposal]

  • From: Binod < >
  • To:
  • Subject: Pending Messages Design. [Re: B2B proposal]
  • Date: Fri, 31 May 2013 14:18:20 +0530
  • List-id: <jsr359-experts.sipservlet-spec.java.net>

Hi All,

Please find the alternate design we were discussing in the meeting.

Note that, I was hoping that the RFC 6026 can be followed for deciding
whether the message is pending for the invite transaction.

JSR 289 also have uncommitted messages. Do we also need a
way to retrieve uncommitted messages? Something like

PendingMessages pm =
sipsession.getPendingMessages(SipServletMessage.UNCOMMITTED)?

thanks,
Binod.

On Tuesday 14 May 2013 09:41 PM, Lewis, Keith wrote:
" type="cite">
Binod,

Thanks for the feedback.

Some comments inline below.

Keith


On Fri, May 10, 2013 at 8:58 AM, Binod < " target="_blank"> > wrote:
Hi Keith,

Here are some comments on this document.

- In general, we should try to keep the methods as generic as possible.
  We do not need to save developer writing one extra line of code for
  "a particular case" at the cost of introducing a "special purpose" method.

- SipFactory.createContinuationRequest :
  I would instead have a createRequest(originalrequest, from, to, Set<String> excludeList)

- For the pendingxxx methods, there is conflict between pending state and
  Implicit transaction state defined in JSR 289. While it may be difficult to
  now change the behavior of implicit transaction state, we should not try to
  ignore that completely.

The aim in providing these methods is to reduce the need for applications to store messages. In defining the meaning of "pending" we are saying when the container can stop holding a reference to the message. We are not defining when the transaction is complete. I think the fact that we have now removed references to transactions from the names of the methods will help avoid confusion.
 

- There is no alternative to current b2buahelper.getPendingMessages method.
This is deliberate. Developers who are happy with this method can continue to use the B2BuaHelper. The fact that this method is cumbersome to use was the main motivating factor for us suggesting a new API. 

- How about defining the pending messages as a readonly collection? And retrieve
  that collection from session? For example, we can define a interface
  called Session.PendingMessageCollection that extend the java collection.   
  By default, this interface can act as the collection of uncommitted messages.
  The additional usecases like getting pending invites and getting reliable provisional
  responses etc can be added as extra methods to this interface.

- If an invite gets a reliable provisional response and involves prack, does the
  invite remain pending until ack for invite 2xx, right?
Yes

- Why do we need createInviteResponseForDerivedSession? The name sounds quite odd to
  me. Application can always do getPendingInvite() and then create a response, right?

Previously I named it the same as the equivalent method on the B2BuaHelper - createResponseToOriginalRequest -  but it was suggested that it should have a new name. This is my attempt. The method is special in that it creates a new (derived) session for a forked response so the name is meant to indicate this.

- SipServletRequest.getRequestId -> SipServletRequest.getId()

- I would try not to use sip method names directly in the api. So, instead of getPendingInvite,
  may be PendingMessageCollection.getRequest(String methodName) might be better?
 
Chapter 17 of RFC3261 distinguishes INVITE transactions and explains the special processing they receive. Since the method returns the initial request of an INVITE transaction it seems OK to name the method getPendingInvite(). We have the method getPendingRequest(String requestId) which can be used more generally for both INVITE and non-INVITE requests.

thanks,
Binod.

 

On Wednesday 08 May 2013 09:03 PM, Lewis, Keith wrote:
Here is an updated version of the B2B and transaction API.
Most of the changes are those suggested by the group.

Keith Lewis


On Fri, Mar 22, 2013 at 6:03 PM, Lewis, Keith < " target="_blank"> > wrote:
Hi all,

Here is the thrupoint proposal for B2B changes.

Keith

 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3





 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3




Attachment: pending-message.diff
Description: Text Data



Re: B2B proposal

Lewis, Keith 05/08/2013

Re: B2B proposal

Binod 05/10/2013

Re: B2B proposal

Lewis, Keith 05/14/2013

Re: B2B proposal

Binod 05/29/2013

Pending Messages Design. [Re: B2B proposal]

Binod 05/31/2013

Re: B2B proposal

Lewis, Keith 05/31/2013
 
 
Close
loading
Please Confirm
Close