Skip to main content

Re: B2B proposal

  • From: "Strickland, Tom" < >
  • To:
  • Subject: Re: B2B proposal
  • Date: Mon, 17 Jun 2013 14:33:45 +0100

I am coming around to Nitzan's point-of-view on this. The existence of multiple request objects on either the UAC or UAS side would not be that intuitive, as there would be a one-to-many relationship between the SIP message on the wire and its representation within the app: a little strange. Keith and I are coming up with a new B2BUA proposal - stay tuned :-)

Tom


On 17 June 2013 08:11, Nitzan Nissim < " target="_blank"> > wrote:
I am not sure that cloning the request is that obvious.
Does that mean we will have multiple requests sharing the same transaction?
What would it mean for attributes that are set on these requests?
I am not sure a change like this will be very backwards compatible or
performant...



Thanks,
Nitzan

_______________________________________________
Nitzan Nissim
SIP Container Architect, WebSphere SIP Infrastructure
IBM Software Group, AIM
Israel Software Lab
+972 (54) 6976107
+972 (8) 9482326
">






From:   Binod < "> >
To:     "> ,
Date:   17/06/2013 07:12 AM
Subject:        Re: B2B proposal



"Likely" was not an accident :-)

It is not specified anywhere. Actually, as you say below in this thread, we
should clarify that
and say it is a "must" to make it obvious for the developer.

thanks,
Binod.

On Friday 14 June 2013 06:15 PM, Strickland, Tom wrote:
      Likely to clone the SipServletRequest when the derived session is
      created? I've probably missed this (it wouldn't be the first time :-)
      but...
      Where in the spec does it say that they should/may/must create the
      cloned request? Quoting from the spec:

      --- Start-quote ---
      6.2.3.2 Derived SipSessions
      A derived SipSession is essentially a copy of the SipSession
      associated with the original request. It is constructed at the time
      the message creating the new dialog is passed to the application. The
      new SipSession differs only in the values for the tag parameter of
      the address of the callee (this is the value used for the To header
      in subsequent outgoing requests) and possibly the route set. These
      values are derived from the dialog-establishing message as defined by
      the SIP specification. The set of attributes in the cloned SipSession
      is the same as that of the original—in particular, the values are not
      cloned.
      New SipSessions corresponding to the second and subsequent 2xx
      responses (or 1xx responses with To tags) are available through the
      getSession method on the SipServletResponse. The “original”
      SipSession of the request continues to be available through the
      original request object.


      12.5 Original Request and Session Cloning
      The incoming request that results in creation of a SipSession is
      termed as the original request, a response to this original request
      can be created by the application even if the request was committed
      and application does not have a reference to this request. This is
      necessary because the B2BUA application may require to send more than
      one successful response to a request. For example, when a downstream
      proxy forked and more than one success responses are to be forwarded
      upstream. This can only be required on initial requests, as only
      original requests shall need such multiple responses.

      SipServletResponse
      B2buaHelper.createResponseToOriginalRequest(SipSession session, int
      status, String reasonPhrase) throws IllegalStateException;

      The response thus generated MUST have a different "To" tag from the
      other responses generated to the request and must result in a
      different SipSession. In this (and similar) cases the container
      clones the original SipSession for the second and subsequent dialogs,
      as detailed in 6.2.3.2 Derived SipSessions. The cloned session object
      will contain the same application data but its createRequest method
      will create requests belonging to that second or subsequent dialog,
      that is, with a "To" tag specific to that dialog.
      --- End-quote ---

      Common sense would suggest that it would be useful if the container
      cloned the request, but I don't read this text as implying that the
      container may/should/must do this. I would say that it must, but
      there is nothing that I can lean on in the spec text as an app
      developer that would allow me to rely on that hope :-)

      Tom



      On 14 June 2013 12:55, Binod < "> > wrote:

               >
               > --- 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...
               >
               > Version 2 of my proposal did have this method on the
               SipSession. I realised
               > a problem with that as explained in the email that
               accompanied version 3.
               >
               > The rseq value in a reliable provisional is only unique
               for that dialog. Due
               > to forking there can be several dialogs which return
               provisional responses.
               > In order to locate a specific response at a UAC which is
               downstream of a
               > forking proxy we need to pass the session (or derived
               session) along with
               > the rseq to the method on SipInviteRequest.
               >
               > If we put the method on the SipSession there is still a
               problem with the
               > uniqueness of the rseq value. PRACK can arrive after the
               corresponding ACK
               > by which time a new INVITE transaction can be in progress
               which also has
               > provisional responses. To retrieve the correct response we
               would need to
               > pass it the requestId of the INVITE transaction as well as
               the rseq.
               >
               > It seems best to avoid cluttering the SipSession interface
               with methods such
               > as this one.
               Ok, I think you lost me but I guess my original question was
               also that
               the request itself is uniquely associated with a particular
               sip
               session (it cannot have two) so if you ask the request, the
               sip
               session is implied. Right?

              A SIP request is uniquely associated with a SIP dialog, which
              is uniquely associated with a SipSession. This all seems
              simple enough, until you consider forking. When downstream
              forking occurs, you will have more than one SipSession, but
              still only have one SipServletRequest. This is not so bad
              when you are acting as a UAC, but when you are running a
              B2BUA and acting as a UAS, what happens when you want to
              "fork back" to the caller?

                  Alice          B2BUA          Proxy          Bob1
              Bob2
               1. INV(a1)---------->
               2.                   INV(b1)------->
               3.                                 INV(b1)------->
               4.                                 INV
              (b2)--------------------->
               5.                                 <-------180(b1)
               6.                   <-------180(b1)
               7. <----------180(a1)
               8.                                 <---------------------180
              (b2)
               9.                   <-------180(b2)
              10. <----------180(a2)

              Here we have an example of parallel downstream forking.
              Assume that the B2BUA is an app running on a SipServlet
              container. Everything else is a normal SIP actor outside of
              the container. At step (9), the response from Bob2 leads the
              container to realise that forking has occurred, and so it
              creates a derived SipSession from the session used to send
              the initial INVITE to Bob in step (2). When we need to send
              the first response to Alice in (7), then the existing
              SipSession is used, but to create the second response in (10)
              requires a new SipSession to be created. After all this
              forking: Alice has two SipSessions, but only one INVITE
              SipServletRequest - when that SipServletRequest is queried
              for Alice each has one INVITE. When you call getSession() on
              the INVITE SipServletRequest, it will return the original
              SipSession. All quite weird.
        Containers are likely to clone the SipServletRequest when the
        derived session is created.
        So, though I see your point, we can not assert that there can be
        more than one sipsession
        for a sipservlet request.

        thanks,
        Binod.


               Anyway, I suck at the prack stuff so I'm going to go with
               whatever you
               want as long as we make sure that the methods are clear, the
               documentation is there and we don't run the risk of
               confusing
               container implementors as well as users.

              As for the PRACK stuff, we are discussing this and Keith is
              writing up a further proposal that is hopefully a little more
              clear when it comes to handling PRACK transactions from one
              INVITE transaction overlapping with a different INVITE
              transaction (and thus possibly overlapping with its PRACK
              transactions).

              Tom

               >>
               >> --- SipSession.getActiveInvites ---
               >>
               >> What about getActiveXXX? i.e., what about all the other
               methods?
               >
               > Only INVITE transactions require an ACK, other
               transactions are complete
               > once the final response is sent/received. Similarly only
               INVITES can have
               > reliable provisional responses.

               Sure, but until you get a final response the "other" type of
               requests
               are still "active". And if you are after only whether or not
               you have
               received an ACK or not, wouldn't a method following the
               other
               getUnacknowledgedXXXX methods be more appropriate?

                    --
                    Tom Strickland, Software Developer, Thrupoint Software.
                    Tel: +44 (0) 2920 005110

              --------------------
              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








      --
      Tom Strickland, Software Developer, Thrupoint Software. Tel: +44 (0)
      2920 005110

      --------------------
      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







--
Tom Strickland, Software Developer, Thrupoint Software. Tel: +44 (0) 2920 005110
 
--------------------
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