Skip to main content

Re: Meeting Notes

  • From: Nitzan Nissim < >
  • To:
  • Cc:
  • Subject: Re: Meeting Notes
  • Date: Tue, 14 Jan 2014 13:28:26 +0200

I checked with our team, and we couldn't find in our records any such case
where form mattered to an end point.
If no one else on the EG has any reservations about this, then we are OK
with Keith's suggestion.

Thanks,
Nitzan




From:   Tom Strickland 
< >
To:     
" "
            
< >,
Date:   13/01/2014 04:55 PM
Subject:        Re: Meeting Notes
Sent by:        




The original JIRA issues mentions this as an interop problem, However,
following the call, I am still not clear on the extent to which this is
being driven by interop needs that have been observed anywhere, as opposed
to being theoretical. Perhaps, in a lapse of concentration, I missed
someone outlining such a real example.

The use case driving this seems to be:

Assume that there are two dialogs, A and B, which are connected -
essentially as a B2BUA. Our use case is that we need to be able to copy the
exact form (== short or long form) of a header's possibly many values over
from one dialog to the other. We have agreed that you should be able to
specify the form of a header when setting it, so this use case is really
about being able to read the exact form of each header - in fact, of each
value of a header, assuming that those values are on different lines.

This use case seems to assume that there are endpoints out there that care
about the form, and that there are situations under which we would want to
mantain a mixture of forms for a header. Is this really the case? Has
anyone observed this in the wild?


Tom


On 13 January 2014 14:27, Nitzan Nissim 
< >
 wrote:

  The limitation with the approach of always converting to the long format,
  is that it doesn't provide a way to preserve a unified form between
  incoming and outgoing messages.
  I think that the comment in the JIRA issue mentions this as a possible
  interop problem.

  Thanks,
  Nitzan





  From:   binod pg 
< >
  To:     
,
  Date:   13/01/2014 01:34 PM
  Subject:        Re: Meeting Notes



  Do any one else have an opinion on this? Let me know if anyone disagrees
  with this proposal.

  - Binod.

  On 1/9/2014 4:53 PM, Keith Lewis wrote:
        All,

        The notes for issue 28 say "We decided that the behaviour will be
        specified only for the new version of the API getHeaderNameList()".

        On reflection this seems to me to be a bad idea.
        If the existing functionality of getHeaderNames() is incompletely
        specified then we should fix that rather than leaving it undefined.
  A
        good standard is not vague.

        SIPSPEC-28 raises the issue of a message that contains both long
  and
        compact name of the same header.
        It seems to me that the spec is also unclear as to what form should
        be presented to the application when a header is received using
  only
        the compact form - should it abstract away the received header form
        and always use the long form? The javadoc does not say.

        It would seem that in JSR289 it is possible to write applications
        that only refer to header names using the long form when
  interacting
        with the methods setHeader, addHeader, getHeaders and getHeader.
        This is good since it means that knowledge of the compact forms can
        be left to the container.
        For many headers there is no compact form so the long form is the
        natural canonical representation.

        I suggest that we should specify that both getHeaderNames and
        getHeaderNameList should use the long form for all headers
        irrespective of the form in which they were received on the wire or
        the form that they will be sent. This will be what some containers
  do
        anyway. It represents a small loss of information but a useful
        abstraction.

        Keith Lewis


        On 9 January 2014 06:08, Binod 
< >
 wrote:
          Attendees : Nitzan, Tom, Keith, Eric, Wei, Binod

          - Issue 15 (Timers configuration): There was a discussion whether
          this is important to be handled
            on a per application basis. EG members does not seem to be
          observing usecases for this at the moment.

          - Issue 16: setOutboundInterface(SipURI). JSR 289 did not have
  this
          method since SipURI has more information
            (eg: transport) than just InetAddress. So, this API is better
          avoided. However there was a suggestion that
            container may supply InetAddress more directly apart from
          supplying a list of SipURIs as interfaces. Binod will work on
  this.

          - Issue 17: Terminating proxy dialog: We decided that it is
  useful
          to have a method to terminate proxy dialogs.

          - Issue 28: Form of getHeaderNames api. We decided that the
          behavior will be specified only for the new version
            of the API getHeaderNameList(). When there are both compact and
          long form of same header appear
            in the message, long form will be choosen as default. There was
  a
          discussion whether application would
            need to access the list of names in long or mixed forms. We are
          alluding to providing an overriden API
            getHeaderNameList(HeaderForm) to satisfy the requirements.

          - B2BUaHelper: There is no simpler replacement for the linking
  APIs
          that are present in B2BUaHelper, since we are
            not working on a new object model for B2B. So, there was a
          discussion on whether we should leave
            B2BUaHelper as it is without enhancement or deprecate it.
  Another
          option considered is to deprecate
            methods, where there is a replacement, leaving the linking APIs
          as is, which appear more acceptable to
            EG.

          - Allowing SipApplicaion annotation to be specified in SIP
  Servlet
          instead of package-info.java. It seems generally
            a good thing to do.

          - Current plan is to submit the public review some time towards
  the
          end of February. Given the face to face is
            unlikely, early comments are appreciated.

          - Binod.


        --------------------
        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.  CafeX Communications.








--------------------
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.  CafeX Communications.



Meeting Notes

Binod 01/09/2014

Re: Meeting Notes

Keith Lewis 01/09/2014

Re: Meeting Notes

binod pg 01/13/2014

Re: Meeting Notes

Nitzan Nissim 01/13/2014

Re: Meeting Notes

Tom Strickland 01/13/2014

Re: Meeting Notes

Nitzan Nissim 01/14/2014

Re: Meeting Notes

Eric Cheung 01/14/2014

Re: Meeting Notes

Binod 01/15/2014

<Possible follow-up(s)>

Meeting Notes

Binod 01/23/2014
 
 
Close
loading
Please Confirm
Close