On Fri, May 31, 2013 at 6:48 AM, Lewis, Keith < " target="_blank"> > wrote:
> I attach a new version of the transaction proposal.
> It addresses some issues I noticed with the previous version.
> There are some changes to the method names and a reduction in the number of
> methods which may address some of the comments from the last meeting.
> Here are the main changes
> For reliable provisional responses I now use the term "unacknowledged"
> rather than pending in the method names and description.
> I realised that there can be more than one invite transaction within a> dialog which has unacknowledged provisional responses. This means that> when retrieving a provisional response we need to use a combination of the
> invite request, the session and the rseq. This could have been achieved by
> adding the invite as a parameter to a method on the session. It seemed more
> natural to put the method on the request and pass the session and rseq as
> parameters. Since the method only applies to invite requests I am proposing
> that we create a new interface - SipInviteRequest - which extends
> The section on linking has been updated to reflect the fact the we need to
> store a reference to the invite as well as the rseq when linking provisional
> I moved the method for accessing final responses to the new interface and
> renamed it from getPendingInviteResponse to getFinalResponse.
> I combined the two getPendingRequest methods on SipSession into one method
> which returns a map and simplified the definition of pending. I added a
> UAMode parameter to select just incoming or outgoing requests - this seemed
> more useful than mixing both in the same map and reflects which is done in
> the B2buaHelper.getPendingMessages method.
> I added a new method SipSession.getActiveInvites which returns a map of
> I split the createInviteResponseForDerivedSession method into 2 separate
> methods - createDerivedSession and SipInviteRequest.createResponse - this
> addresses the concern with the complex name. It also allows additional
> responses to be sent on a derived session thus allowing some useful B2B
> behaviour missing from the existing B2BuaHelper.
> On Tue, May 14, 2013 at 5:11 PM, Lewis, Keith < " target="_blank"> > wrote:
>> Thanks for the feedback.
>> Some comments inline below.
>> 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"
>>> - 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
>> 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
>>> that collection from session? For example, we can define a interface
>>> called Session.PendingMessageCollection that extend the java
>>> By default, this interface can act as the collection of uncommitted
>>> 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?
>>> - 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
>> 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.
>>> 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"> >
>>>> Hi all,
>>>> Here is the thrupoint proposal for B2B changes.
-------------------- 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
Message not available
Message not available
Fwd: B2B proposal