Skip to main content

Re: B2B proposal

  • From: Binod < >
  • To:
  • Subject: Re: B2B proposal
  • Date: Thu, 13 Jun 2013 16:30:56 +0530

I have the same concerns which Jonas have on this proposal.

For example,

Three methods in SipInviteRequest seem to accept the session
as a parameter and that seem to indicate that those methods
should have been on the Session?

And when we have five methods added to Session that addesses
a concern, we need to look at, whether we should separate that
concern or not.

thanks,
Binod.

On Wednesday 12 June 2013 11:58 PM, Jonas Borjesson wrote:
Hi all,

I agree with George – i.e., 1A is my preferred solution since as I'm
sure you know by now that I like interfaces, things become more
explicit. Apart from that, I do have a few other questions/comments:

=== Consistency ===
The suggestion calls for a lot of new very specific methods, such as
SipInviteRequest.getUnacknowlegedProvisionalResponse(s),
SipFactory.createContinuationRequest and
SipSession.getActiveInvites(UAMode).

The first two ones are very specific but the third one has two
meanings, incoming and outgoing which is defined by the UAMode. Going
with the rest of the methods and the overall intent of the proposal
should they just be renamed to
SipSession.getActiveIncoming/OutgoingInvites? I can go both ways but
just wanted to ask. I think consistency is super important in an API.
However, from a simplicity point of view I have some other concerns
about these every specific methods...

Also, we often returns Collection but sometimes pass in Set. If the
intent is indeed to e.g. not allow duplicates then sure, use a Set but
then I would ask if that really matters for the proposed changes? So
is the useage of Set deliberate?

And finally, in 289 Iterators are what is typically returned so if
nothing else the return values from these new proposals should
probably do the same (even though there are some inconsistencies in
289 as well – SipApplicationSession.getTimers() e.g.) .

=== Simplicity ===

In general, we should certainly make the life of the developers easy
but I don't always think creating a bunch of different very special
purpose methods will actually help. If we end up creating methods such
as SipFactory.createContinuationRequest then I believe that the API is
broken as it is and patching it is only going to make developers more
confused.

--- CreateContinuationRequest ---

So, createContinuationRequest, apart from making that particular use
case just slightly easier, is it a good idea? Perhaps the routing
directive should be added to the SipFactory.createRequest methods
instead? If we decide to keep the createContinuationRequest, why not a
createReverseRequest too?


I guess I personally do not like the createContinuationRequest because
for consistency sake we should then also add all the other
possibilities but the API becomes really cluttered, which is even
worse. So, I'm voting for not including this method and if really
needed enhance the SipFactory.createRequest ones instead, which I
believe is also what Binod suggested.


Also, on a separate note, the javadoc isn't super clear what the
directive is for the newly created request. I assume is is NEW, which
makes sense but the only reference I have found regarding this is the
javadoc on SipServletRequest.setRoutingDirective, which is referring
to the deprecated SipFactory.createRequest. Perhaps we should improve
the javadoc here...


(side note2: for a beautiful API that gets stuff done, check out the
Python Requests API (though http is way simpler protocol but this API
is what I try and strive for)
http://docs.python-requests.org/en/latest/)


--- SipInviteRequest.getUnacknowledgedProvisionalResponse ---

Why do we need to pass in the SipSession? If we do, it seems like this
method should be on the SipSession as opposed to the request. Since it
is on the request, I would assume this method would only return
responses for this particular transaction, correct? And if so, the
SipSession is not needed since the request you are operating on
explicitly is associated with a SipSession, or perhaps I'm missing
something...



--- SipSession.getActiveInvites ---

What about getActiveXXX? i.e., what about all the other methods?

On Fri, May 31, 2013 at 6:48 AM, Lewis, Keith 
< >
 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
dialogue 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
SipServletRequest.
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
responses.
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
SipInviteRequests.
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.

Keith

On Tue, May 14, 2013 at 5:11 PM, Lewis, Keith 
< >
 wrote:
Binod,

Thanks for the feedback.

Some comments inline below.

Keith


On Fri, May 10, 2013 at 8:58 AM, Binod 
< >
 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 
< >
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




Re: B2B proposal

Jonas Borjesson 06/12/2013

Re: B2B proposal

Binod 06/13/2013

Message not available

Message not available

Fwd: B2B proposal

Strickland, Tom 06/13/2013

Re: B2B proposal

Jonas Borjesson 06/13/2013

Re: B2B proposal

Strickland, Tom 06/14/2013

Re: B2B proposal

Binod 06/14/2013

Re: B2B proposal

Strickland, Tom 06/14/2013

Re: B2B proposal

Binod 06/17/2013

Re: B2B proposal

Nitzan Nissim 06/17/2013

Re: B2B proposal

Strickland, Tom 06/17/2013

Re: B2B proposal

Jonas Borjesson 06/14/2013

Re: B2B proposal

Lewis, Keith 06/15/2013
 
 
Close
loading
Please Confirm
Close