<< Back to previous view

[SIPSERVLET_SPEC-32] It is not 100% clear in the documentation whether an empty list for a particular header in B2BuaHelper.createRequest(..., headerMap) will clear that header out. Created: 18/Jan/13  Updated: 26/Mar/14  Resolved: 05/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: Improvement Priority: Major
Reporter: jonbo372 Assignee: binod
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod, bpulito, echeung, jonbo372, jverbil, nitzann and wchen

 Description   

By using the B2BuaHelper.createRequest(..., headerMap) the user can create a new "b2bua:ed" request where system headers such as Route-headers can be overridden. However, the documentation is not really clear what the behavior is when you supply an empty value-list for a particular header. Consider the following example:

Incoming INVITE which has two route headers like so:

INVITE sip:alice@example.com SIP/2.0
...
Route: <route 1>
Route: <route 2>

If I wanted to use the b2buahelper to create the second leg but do not want to the Route headers to be present in the new request one could assume that the following would work:

Map<String, List<String>> headerMap = ...
headerMap.put("Route", new ArrayList<String>());
SipServletRequest req = helper.createRequest(origRequest, linked, headerMap);

I would now assume that the previous two routes have been wiped out. It is not clear in the specification that this is what is supposed to happen and at least one container implementation had not implemented it this way.



 Comments   
Comment by jonbo372 [ 25/Feb/14 06:13 PM ]

Per our discussion on the weekly meeting, we do agree that a clarification is needed since there are at least two different opinions of what the current wording in the javadoc actually means.

=== Option 1 ===
If you supply an empty list for a particular header, then that header will be removed. This is what the original entry suggests.

=== Option 2 ===
If you supply an empty list for a particular header then the original headers and their values are preserved.

Also, if you prefer Option 2, please specify what should happen in the following example:

Incoming request with three X-Hello headers like so:

INVITE sip:alice@example.com SIP/2.0
...
X-Hello: hello one
X-Hello: hello two
X-Hello: hello three
...

Map<String, List<String>> headerMap = ...
List<String> helloHeaders = new ArrayList<String>();
helloHeaders.add("hello world");
headerMap.put("X-Hello", helloHeaders);
SipServletRequest req = helper.createRequest(origRequest, linked, headerMap);

How many X-Hello headers exists in the new request and what are their values?

Please vote which option you prefer so that we can clarify the behavior in the javadoc and align the behavior of the containers.

Comment by jonbo372 [ 25/Feb/14 06:15 PM ]

Personally, I vote for Option 1...

/Jonas

Comment by echeung [ 25/Feb/14 06:39 PM ]

I vote for option 1.
Eric

Comment by jverbil [ 25/Feb/14 08:35 PM ]

Option 1

Comment by wchen [ 26/Feb/14 05:16 AM ]

I misread the issue at the meeting. After reading it again, yes, option 1.

Comment by nitzann [ 26/Feb/14 08:58 AM ]

Option 1

Comment by bpulito [ 26/Feb/14 01:32 PM ]

Option 1

Comment by jonbo372 [ 26/Feb/14 06:59 PM ]

Seems like there is a consensus for Option 1 so let's update the javadoc to make this clear.

Comment by binod [ 05/Mar/14 11:56 AM ]

Included the fix in the latest javadoc.

https://sipservlet-spec.java.net/javadoc/2.0/draft/javax/servlet/sip/B2buaHelper.html





[SIPSERVLET_SPEC-29] Clarify which headers the container populates in new request Created: 17/Jan/13  Updated: 26/Mar/14  Resolved: 24/Feb/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: Improvement Priority: Major
Reporter: echeung Assignee: binod
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod and echeung

 Description   

SipFactory.createRequest javadoc says "Returns: the request object with method, request URI, and From, To, Call-ID, CSeq, Route headers filled in."

Not clear on the rationale of this set of headers. e.g. Max-Forwards is mandatory in RFC3261 table 2, and it seems most container implementations populate it. The javadoc should add this to the list.

The Allow header is a SHOULD in RFC3261. It may be useful if the container populate it with the methods it support as well. (The app can then trim remove anything it does not want to support)



 Comments   
Comment by binod [ 24/Feb/14 04:26 PM ]

As per the discussion on the EG meeting, decided to add Via, Max-Forwards and Allow as container populated headers.

The 0.8 version distributed contains the fix to the javadoc.
https://sipservlet-spec.java.net/javadoc/2.0/draft/javax/servlet/sip/SipFactory.html





[SIPSERVLET_SPEC-28] Compact header form behavior unclear Created: 17/Jan/13  Updated: 26/Mar/14  Resolved: 07/Feb/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: Improvement Priority: Major
Reporter: echeung Assignee: binod
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod and echeung

 Description   

The Javadoc of SipServletMessage is unclear:

  • The behavior of getHeaderNames() is unclear. If the message contains both long and compact name of the same header, e.g. Supported and k, should both be returned, or one, and which one?
    (Suggest only one to be consistent to getHeader() and setHeader())

Currently, the application has no knowledge of the header form of an incoming message. The application can influence the header form on an outgoing message. Also note that if there are mixed usage of long and compact forms, there is no way to preserve the forms when copying from one message to another. This may cause problem for some corner interop situations.



 Comments   
Comment by binod [ 10/Dec/13 11:20 AM ]

Now that we have a new method getHeaderNameList(), would it make sense to specify long and compact name behavior only to the new method or should we also specify the behavior of getHeaderNames?

Comment by binod [ 07/Feb/14 11:16 AM ]

As per the EG discussion, we decided that both getHeaderNames and getHeaderNameList will return header names in the long format. The implementations seem to be comfortable with this change and will not introduce backward incompatibility.





[SIPSERVLET_SPEC-16] Allows for applications to set the outbound interface based on SipURI Created: 25/Oct/12  Updated: 26/Mar/14  Resolved: 07/Feb/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: Improvement Priority: Major
Reporter: deruelle_jean Assignee: binod
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod, deruelle_jean and echeung

 Description   

The current API allows only applications to set the outbound interface (in proxy or sipsession) based on InetAddress but the ServletContext provides a SipURI List. The goal would be to align and allows to set based on SipURI instead of (or in addition to) InetAddress



 Comments   
Comment by echeung [ 08/Feb/13 01:35 PM ]

For historic context, this was the rationale for the asymmetry:

----- on 9 Jan 2008---
Hello,

We'd like to propose a change to simplify the setOutboundInterface (http://www.289eg.org/cb/proj/tracker/itemDetails.do?navigation=true&task_id=1028) syntax and semantics.

The idea is to introduce two methods :
void setOutboundInterface(java.net.InetSocketAddress address)
void setOutboundInterface(java.net.InetAddress address)

Instead of existing:
void setOutboundInterface(SipURI uri)

The motivation of this change is to allow the developers to easily influence the source port number and IP address chosen by the container when originating requests for SipSession/Proxy/ProxyBranch without interfering with RFC-defined transport selection rules.

Kristoffer and I spent some time discussing various use cases around the existing 1.1 API (i.e. uri is supplied instead of just the address or address/port combination).

While trying to write all the corner/error cases out, I realized that the RFC-dictated transport selection rules were rather difficult to work around and a simpler mechanism would be preferable.

Please let us know what you think.

Thanks
Jarek & Mihir

----- on 1 May 2008, in response to a question on consistency---
The short answer is no.
The idea behind using URI in the ctx attr is that a container implementation could indicate which interfaces are SIPS capable, or possibly limited to a specific transport ('transport=tcp'). The setOutboundInterface takes and InetAddr because we don't want it to interfere with SIP transport type selection rules.

Thanks,
Jarek

Comment by binod [ 31/Jan/14 11:32 AM ]

As per the discussion in the EG meeting, we decided that, the container will provide a list of IP addresses to the application, so that they can directly use what is obtained from the servlet context. Following are the suggested updates to the API for the same.

Add to SipServlet:
public static final String OUTBOUND_ADDRESSES =
"javax.servlet.sip.outboundAddresses";

Add to SipServletContext:
List<InetAddress> getOutboundAddresses();

Comment by binod [ 07/Feb/14 11:21 AM ]

This change is now incorporated.

https://sipservlet-spec.java.net/javadoc/2.0/draft/javax/servlet/sip/SipServlet.html#OUTBOUND_ADDRESSES

https://sipservlet-spec.java.net/javadoc/2.0/draft/javax/servlet/sip/SipServletContext.html#getOutboundAddresses()





[SIPSERVLET_SPEC-7] Container provides dialog termination behavior Created: 04/Oct/12  Updated: 26/Mar/14  Resolved: 05/Feb/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: echeung Assignee: echeung
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: edr pr
Participants: binod and echeung

 Description   

This is a simplification for developers, as it is not trivial to terminate a dialog correctly especially in races. Container can terminate INVITE and non-INVITE dialogs by sending the correct message sequence. Should also handle multiple dialog usages (RFC5057).

Note some terminating SIP messages (like NOTIFY) can contain payload. So, we will need to look into the problem more deeply. Also certain non-dialog creating requests such as REGISTER or PUBLISH still have long-lived semantics so we may want to consider them too.



 Comments   
Comment by binod [ 05/Feb/14 07:36 AM ]

Please see section 8.2.5 of the specification draft.





[SIPSERVLET_SPEC-6] Container handles SIP session-timer Created: 04/Oct/12  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: echeung Assignee: binod
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod and echeung

 Description   

This is a simplification for developers where the container takes care of the SIP Session Timers mechanism (RFC 4208). In most cases applications do not need to be aware of session-timer messages. We will need to determine the correct behavior when the app is acting as proxy, ua, or b2bua.



 Comments   
Comment by binod [ 03/Feb/14 11:23 AM ]

Please see the section 8.2.7 for the details of the session timer interface.





[SIPSERVLET_SPEC-5] Access to active SipApplicationSessions Created: 04/Oct/12  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: echeung Assignee: binod
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod and echeung

 Description   

Currently there is no way to obtain a list of active SipApplicationSession within an application. Although most containers have a way to obtain the number of active SipApplicationSession and SipSession through some proprietary management interface, there is really no way to get to the actual SipApplicationSessions, and do things like check on their status and invalidate them for cleanup.

This feature request is for a way to obtain the list of all active SipApplicationSessions, probably as a method on SipSessionsUtil class. Note to maintain separation of applications, only the SipApplicationSessions belonging to the same application should be obtained.

From EG meeting on 3 October 2012: Due to concern about performance implications in a distributed environment,
even if optimizations are possible, it was agreed that this API method will only return the SAS within the same JVM, and not across a cluster.



 Comments   
Comment by binod [ 26/Mar/14 06:12 AM ]

Section 16.3 explains the details about accessing application sessions.





[SIPSERVLET_SPEC-4] Clarify specific API in distributed environment Created: 04/Oct/12  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: echeung Assignee: binod
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: binod, echeung and keith-lewis

 Description   

It would be useful to mandate certain behavior if an implementation chooses to support clustering. For example,
SipSessionsUtil.getApplicationSessionById() should work across the cluster. Key based session targeting should work across the cluster. In case of
migration or failover of session from one container to another, how the attributes are restored should be standardized.



 Comments   
Comment by keith-lewis [ 05/Mar/14 04:16 PM ]

We agree that it should be mandatory for key based session targeting to work across the cluster.

We should however allow for topologies where the SAS is located on particular nodes in the cluster.

It would be good to have the following methods of the SAS always available.

  • encodeURI
  • encodeURL
  • getApplicationName

The first 2 methods only need access to the SASid.
The app name can be retrieved by the SipSessionUtil object.

To achieve this we could require that even when the full object is not available the container should supply a "skeleton" object which implements these methods.
All other methods could return a IllegalStateException.

To allow the developer to know whther it has the "real" object we can provide a new method on the SAS called isLocalSession() (or isAvailableLocally?)

SipSessionsUtil.getApplicationSessionById() should never return null - it either returns the skeleton object or a real one.

Comment by binod [ 26/Mar/14 07:17 AM ]

We had a discussion on this in the EG meeting.

In general, it is hard to get consensus on issues related to distributed environment. This is partly due to
the fact that the distributed environment is not well defined in generally in java space and sip servlets
in particular because of its asynchronous nature.

The conclusion was containers should have more flexibility in their topologies and implementation choices and is
best left for them to innovate.





[SAILFIN-1182] 487 to INVITE is not received for b2bua cancelling Created: 18/Sep/08  Updated: 04/Nov/08  Resolved: 04/Nov/08

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: binod Assignee: yule_jie
Resolution: Cannot Reproduce Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File issue_1182.tar.gz     GZip Archive server.log.gz    
Issuezilla Id: 1,182
Tags:
Participants: binod, echeung and yule_jie

 Description   

Please see the e-mail thread for details.

http://www.nabble.com/Problem-with-CANCEL-related-handling-with-2-B2BUA-applications-
to19533760.html



 Comments   
Comment by echeung [ 18/Sep/08 09:47 AM ]

original poster added in cc

Comment by echeung [ 22/Sep/08 10:07 AM ]

Correction - the same 2 problems are observed in b42, so maybe it is not a new
problem afterall.

In any case, to recap, in the following app chain, when uac sends CANCEL, b2bua1
and b2bua2 apps passes on the CANCEL. But:

uac ---- b2bua1 ---- b2bua2 ---- uas

1) b2bua1 never receives the 487 response to INVITE. The container
should send it to b2bua1 without any involvement from b2bua2.

2) b2bua1's doResponse() is called with 200 OK response to CANCEL.

Comment by echeung [ 22/Sep/08 10:08 AM ]

to clarify, uac and uas are external user agents. The container has 2 apps,
b2bua1 and b2bua2.

Comment by echeung [ 01/Oct/08 03:18 AM ]

Created an attachment (id=707)
server.log file showing problem with 2 apps: rerouteUponFailureTest — noAnswerTimeoutTest

Comment by yule_jie [ 07/Oct/08 04:27 AM ]

Reassign to me

Comment by yule_jie [ 07/Oct/08 06:05 AM ]

Fixed the first issue: "app1 does not receive 487 response" by modifying
INVITESession. Still working on the second issue.

Comment by yule_jie [ 14/Oct/08 03:08 AM ]

Modified NonInviteClientTransaction, ConfirmedProxyImpl, ProxyImpl,
INVITESession and ProxyBranchImpl to stop 200 OK response for CANCEL before it
reaches the servlets.

Comment by echeung [ 14/Oct/08 11:56 AM ]

I just installed b55 and ran the test again, and confirmed that the first issue
is resolved in the case of:

(UAC) — RR – NAT — (UAS)

(RR and NAT are B2BUA)

However, in another test case where there is a non-record-route, non-supervised
proxy between RR and NAT, RR still does not receive the 487 response to INVITE.

(UAC) — RR – CCF – NAT — (UAS)

(CCF is a non-record-route, non-supervised proxy)

I wonder if the fix relies on NAT being the next application from RR?

Comment by echeung [ 14/Oct/08 12:16 PM ]

More info: Making CCF a record-route, supervised proxy, the problem is the
same. RR does not receive the 487 response to the INVITE request.

Comment by yule_jie [ 16/Oct/08 01:23 AM ]

Cannot reproduce this problem. I have tried
1. (CCF is a non-record-route, non-supervised proxy)
2. (CCF is a record-route, supervised proxy)

Both of them worked for me. RR received 487. Can you provide your test servlets?

Comment by echeung [ 16/Oct/08 11:46 AM ]

Created an attachment (id=752)
application war files and server.log

Comment by echeung [ 16/Oct/08 11:48 AM ]

Attached a tar.gz containing the 3 applications:
RR - rerouteUponFailureTest.war
CCF - ccfTest.war
NAT - noAnswerTimeoutTest.war

and server.log. Note that noAnswerTimeoutTest logs receipt of 487 response from
external UA. But rerouteUponFailureTest does not log receipt of 487.

Did you run your test on b55, or on the newest code?

Comment by yule_jie [ 04/Nov/08 12:55 AM ]

Please try with the latest build.





[SAILFIN-608] GenericServlet.getInitParameterNames() returns wrong type Created: 25/Feb/08  Updated: 27/Oct/08  Resolved: 27/Oct/08

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 1.0
Fix Version/s: b24

Type: Bug Priority: Major
Reporter: echeung Assignee: prasads
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 608
Tags:
Participants: echeung, ehsroha and prasads

 Description   

getInitParameterNames() returns an Enumeration of EnvironmentProperty objects,
while the Java EE javadoc says it should return an Enumeration of String objects.



 Comments   
Comment by echeung [ 25/Feb/08 12:20 PM ]

first discovered on b20. Problem also present in b22.

Comment by ehsroha [ 27/Feb/08 07:42 AM ]

Re-assign to Prasad.

Comment by prasads [ 29/Feb/08 02:52 AM ]

Assigning this bug to myself. This issue may be arising due to the change in the
deployment backend.

Comment by prasads [ 29/Feb/08 02:53 AM ]

Moving this to a STARTED state

Comment by prasads [ 14/Mar/08 02:16 AM ]

The issue was fixed in b24
The change was getParameterNames() method was defined in the servlet descriptor
and that returned an Enumeration of String





[SAILFIN-153] Comma in SIP extension headers is interpreted as separator for 2 header-values Created: 02/Nov/07  Updated: 27/Oct/08  Resolved: 27/Oct/08

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: echeung Assignee: sankara
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 153
Tags:
Participants: echeung, ehsroha, prasads and sankara

 Description   

If an incoming SIP message has an extension header, e.g.

X-My-Header: a,b

SailFin interprets it as 2 header-values, "a" and "b".

However, RFC3261 specifies that only header whose grammar is of the form
header = "header-name" HCOLON header-value *(COMMA header-value)
can be interpreted this way. The grammar for extension headers is:
extension-header = header-name HCOLON header-value

Therefore, there should only be 1 header-value, in this example "a,b"



 Comments   
Comment by ehsroha [ 07/Feb/08 05:35 AM ]

Re-assign to Kristoffer!

Comment by prasads [ 20/Feb/08 09:46 AM ]

Re-assigning this to Sankar

Comment by sankara [ 06/Mar/08 01:23 AM ]

This issue will be addressed as part of the fix for issue 30. I am not making
this as a duplicate of issue 30 as they are filed as a different issues.

Comment by sankara [ 08/May/08 09:48 PM ]

Issue 724 is fixed now and this issue is resolved with the fix for 724.

      • This issue has been marked as a duplicate of 724 ***




[SAILFIN-60] UAC application invoked to handle retransmissions of 200 OK Created: 01/Oct/07  Updated: 27/Oct/08  Resolved: 27/Oct/08

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: echeung Assignee: ehsroha
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 60
Tags:
Participants: echeung, ehsroha and jens_tinfors

 Description   

It seems that when a UAC application sends INVITE, then receives 200 OK, if
there are retransmission of the 200 OK the application is invoked for each of
the received retransmission (i.e. doSuccessResponse() get called)

This can be reproduced by running the sample B2BUA application from the JSR116
RI, using SIPp as the caller and callee through the B2BUA. Set up the SIPp
script so the caller does not send ACK until after a few seconds. You can see
that the UAC side of the B2BUA gets called for each 200 OK retransmission.

This is in violation of JSR116 section 7.1.6: "It is the containers
responsibility to retransmit application generated ACKs for 2xx’s when a 2xx
retransmission is received and the container must not deliver the 2xx
retransmission to the UAC application."



 Comments   
Comment by ehsroha [ 30/Oct/07 09:58 AM ]

Corrected com.ericsson.ssa.sip.INVITESession.java and added a regression test case.

Comment by jens_tinfors [ 30/Jan/08 04:14 AM ]

Re-opening this issue again since its constantly failing.

Comment by jens_tinfors [ 01/Feb/08 08:20 AM ]

There is a test case for this issue that currently fails due to problems reported in issue 326.
Issue 326 talks about other problems but affects this issue. non the less, im setting this to WONTFIX since
it is per se not broken (it is just a poor bystander...)

/jens





[SAILFIN-51] SipServletMessage.removeHeader() problem with capitalization of header names Created: 18/Sep/07  Updated: 27/Oct/08  Resolved: 27/Oct/08

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: echeung Assignee: ehsroha
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 51
Tags:
Participants: echeung, ehsroha and qmaghes

 Description   

SipServletMessage.removeHeader() appears to have problem with upper and lower
cases in header names.

For example, in the following code fragment of a B2BUA:

doInvite(SipServletRequest req)
{
...
SipServletRequest req2 = sipFactory.createRequest(req1, false);
req2.addHeader("X-SailFin", "some data");
req2.removeHeader("X-SailFin");
req2.send();
...
}

The request sent out contains a "X-Sailfin" header. Note the "Fin" is now "fin".



 Comments   
Comment by ehsroha [ 06/Feb/08 05:05 AM ]

evalution: minor correction

Comment by qmaghes [ 21/Apr/08 07:05 AM ]

Fixed in trunk. Using formatted headername key when doing remove from header
map.





Generated at Sat Apr 19 23:31:44 UTC 2014 using JIRA 4.0.2#472.