Hi, I'm looking for assistance in interpretation of the JSR289 JavaDocs for API javax.servlet.sip.SipFactory.createAddress(String).
The question is whether the following String should cause an implementation to throw a ServletParseException; <sip:10.10.10.10:5061;transport=tls>
Here are some notes on my investigation so far;
1. JSR289 SipFactory.createAddress(String) seems to be derived from JAIN AddressFactory.createAddress(String)
2. The JAIN JavaDocs clearly describe the acceptable syntax of the method parameter. And the above string is acceptable (though not recommended)
3. The JSR289 JavaDocs has less information and mentions To and From
addresses as examples but then later in the parameter description, the String is described as being a “valid value of SIP From or To header”. The transport token is not allowed in To/From headers are per RFC3261, 19.1.1, Table 1.
4. The JSR289 Address.toString() will only return a “valid value of SIP From or To header”
Points 1 and 2 seem to favour the argument for the NO case.
Points 3 and 4 seem to favour the argument for the YES case.
My conclusion so far is that the the answer is YES, an exception should be thrown. And in that case, the current WAS behaviour is incorrect as it fails to throw an exception and fails to log anything unusual. Note that WAS does (silently) remove the transport paramater as expected when the URI is not surrounded by (i.e. it works as expected when not converted to name-addr form)
Can WAS be updated to throw an exception?
This topic has been locked.
5 replies Latest Post - 2011-09-22T08:18:29Z by DiarmuidLeonard
Pinned topic SipFactory.createAddress(String) is not parsed correctly
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-09-22T08:18:29Z at 2011-09-22T08:18:29Z by DiarmuidLeonard
SystemAdmin 110000D4XK45 PostsACCEPTED ANSWER
Re: SipFactory.createAddress(String) is not parsed correctly2011-09-21T08:45:23Z in response to DiarmuidLeonardHi Diarmuid,
1. the JAIN Address and JSR289 Address are not the same, the JAIN Address only defines display name and uri whereas the JSR289 Address also defines header parameters so I do not think that you can compare them.
2. I agree that the definition of the SipFactory.createAddress method in JSR289 is confusing, it looks like the definition of the Address api has internal contradictions, on one hand the toString description is: "Returns the value of this address as a String. The resulting string must be a valid value of a SIP From or To header" but on the other hand in the Address API it states that "The Address interface is used to represent the value of all headers defined to contain one or more addresses as defined above. Apart from From, To, and Contact, this includes Route, Record-Route, Reply-To, Alert-Info, Call-Info, Error-Info, as well as extension headers like P-Asserted-Identity, P-Preferred-Identity, and Path." some of those headers support the transport parameter and it also supports wildcard Address value which is obviously not a valid to/from address (just for contact header).
In the Websphere SIP container implementation we decided that because the fact that the Address object can be used for all the above headers types (and the SipFactory.createAddress is the common way to create the Address header for all those headers) it must also support the transport parameter in the URI part without throwing an exception. to allow this Address to be used with the From/To headers the SIP container is removing the port/transport when setting the Address in those headers.
We believe that this is a reasonable solution to understand and solve the internal contradictions in the API.
I hope that this explanation answer your question,
Re: SipFactory.createAddress(String) is not parsed correctly2011-09-21T13:04:34Z in response to SystemAdminHi Asaf,
Thanks for the prompt reply.
1. I agree that JAIN is a different standard and is a weak argument for the case that the transport token is acceptable. But it's the only argument I could find to support the argument that the API should accept "name-addr" form.
2. I don't think the JSR289 spec is confusing or inconsistent. I just think it surprising that a) this API does not accept "name-addr" form and b) that this API is error prone because it is not obvious that it should only be used to create addresses for use in To/From/Contact headers. E.g. It seems that JSR-289 takes the view that Address.toString() should display the main attributes of an Address without routing/transport parameters. This doesn't mean that the Address doesn't contain other information or limit its use to To/From/Contact headers.
So In summary, WebSphere is doing what seems to both of us to be logical and reasonable, yet not in compliance with the spec.
There's one small point remaining to clear up. WAS 7 used to accept String in addr-spec format;
whereas WAS 8 does not and only accepts the transport parameter when in name-addr format;
In my understanding of RFC3261, this WAS behaviour is not consistent. Both formats are equivalent (and so both or neither should be accepted). If transport where not a URI parameter, the format would have to be
Therefore, would you agree that the following should be acceptable to the WAS implementation of the API?
SystemAdmin 110000D4XK45 PostsACCEPTED ANSWER
Re: SipFactory.createAddress(String) is not parsed correctly2011-09-22T07:39:19Z in response to DiarmuidLeonardWe change the behavior in Websphere 8.0 to be compliant with JSR289.
According to the API, in SipFactory.createRequest(): "Note that this implies that if either of the from or to argument is a SIP URI containing parameters, the URI must be enclosed in angle brackets. Otherwise the address will be parsed as if the parameter belongs to the address and not the URI."
Whenever a parameter in an Address object is outside of the angle brackets it should be considered as a Address parameter and not a URI parameter according to the JSR.
You are correct that both values are equal when they are used in a URI object but no in an Address object.
We added a SIP container custom property that can be used if you want to use the WAS70 behavior:
If you think that this is what you need in your application code you can set this custom property in your Websphere 8.0 environment and the behavior will be the same as in Websphere 7.0
I hope that this answer your question.
Re: SipFactory.createAddress(String) is not parsed correctly2011-09-22T08:18:29Z in response to SystemAdminHi Asaf,
My previous post overlapped with yours. Your reply fully answers my question and closes the thread, many thanks.
Now I agree with you that the spec for this API is confusing. As you have explained, API
SipFactory.createRequest(SipApplicationSession appSession, java.lang.String method, java.lang.String from, java.lang.String to)
actually defines the behaviour for SipFactory.createAddress(String). Specifially, any parameters in the String of SipFactory.createAddress(String) are considered to be address parameters, not URI parameters. This is critical information that should be Java Doc'd in the API.
The key text is all four of the following lines;
This method is functionally equivalent to:
createRequest(method, f.createAddress(from), f.createAddress(to));
Note that this implies that if either of the from or to argument is a SIP URI containing parameters, the URI must be enclosed in angle brackets. Otherwise the address will be parsed as if the parameter belongs to the address and not the URI.
I'll contact the JCP SipServlet1.1 team to see if they are willing to improve SipFactory.createAddress(String) JavaDocs in any upissue. I'll also query the restriction that prohibits the transport parameter in the URI and will post the result here.
Re: SipFactory.createAddress(String) is not parsed correctly2011-09-22T07:48:59Z in response to DiarmuidLeonardCorrection to the post above.
In comment#1, I stated
... it's the only argument I could find to support the argument that the API should accept "name-addr" form.
It should read
... it's the only argument I could find to support the argument that the API should accept unrestricted "name-addr" form.
(i.e. is not restricted to the acceptable parameter list of To/From/Contact headers)
Reason for change: The API already accepts both "addr=spec" and "name-addr" formats.
Also, can anyone comment on why String <sip:10.10.10.10:5061;transport=tls> is acceptable in WAS 8 but String sip:10.10.10.10:5061;transport=tls is not?