Re: Meeting Notes
- From: Nitzan Nissim <
- 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.
From: Tom Strickland
Date: 13/01/2014 04:55 PM
Subject: Re: Meeting Notes
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?
On 13 January 2014 14:27, Nitzan Nissim
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
From: binod pg
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.
On 1/9/2014 4:53 PM, Keith Lewis wrote:
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.
good standard is not vague.
SIPSPEC-28 raises the issue of a message that contains both long
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
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
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
anyway. It represents a small loss of information but a useful
On 9 January 2014 06:08, Binod
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
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
- Issue 17: Terminating proxy dialog: We decided that it is
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
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
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.
option considered is to deprecate
methods, where there is a replacement, leaving the linking APIs
as is, which appear more acceptable to
- Allowing SipApplicaion annotation to be specified in SIP
instead of package-info.java. It seems generally
a good thing to do.
- Current plan is to submit the public review some time towards
end of February. Given the face to face is
unlikely, early comments are appreciated.
Note: The information contained in this message may be privileged
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
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.