PI10713: SIP CONTAINER SENDS 404 RESPONSES AFTER APPLICATION IS STARTED BUT BEFORE VIRTUAL HOST IS BOUND

Fixes are available

APAR status

Closed as program error.

Error description

When WebSphere Application Server is starting, users may
have endpoints sending REGISTER requests to it. When
Application Server first starts and it gets Session Initiation
Protocol (SIP) requests, at first the application is not
deployed and the container sends 500 Server Internal Error
responses.

At some point the container starts the application.  From that
point  - the container sends 404 responses to SIP requests
until this line appears in the trace log:

[1/28/14 17:31:20:394 MST] 0000000a webcontainer  I com.ibm.ws.
webcontainer.VirtualHostImpl addWebApplication SRVE0250I: Web
Module ASMCallProcessing has been bound to
default_host[*:9080,*:80,*:9443,*:15060,*:15061,*:443].

This is problematic.  RFC 3261 section 10.3 states that a 404
from a registrar means that the AoR in the To header is not
valid for the domain.  Endpoints that are sending REGISTERs to
us do not know that Application Server is in the process of
restarting.  When they get the 404, they may do something
undesirable, like force the user to reenter the AoR they are
using to register (whereas when they get a 5xx they will retry
the REGISTER again after a period of time).

Local fix

```
N/A
```

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server V8.0 and V8.5                        *
****************************************************************
* PROBLEM DESCRIPTION: 404 Session Initiation Protocol (SIP)   *
*                      response is sent for REGISTER when      *
*                      the application is in the startup       *
*                      procedure                               *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Since the SIP container is in the middle of application
startup and the virtual host isn't yet bounded, if a REGISTER
request is received, the container returns 404 response which
might confuse the endpoint side

Problem conclusion

The solution for that problem is that the error response that
will be sent in this particular case (application started but
host didn't bound) - will be determined by the value of the
existing custom property: "sip.no.route.error.code"

The fix for this APAR is currently targeted for inclusion in
fix packs 8.0.0.9 and 8.5.5.3.  Please refer to the
Recommended Updates page for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

Temporary fix

Comments

APAR Information

APAR number
PI10713
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-01-30
Closed date
2014-02-27
Last modified date
2014-02-27

APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name
WEBSPHERE APP S
Fixed component ID
5724J0800

Applicable component levels

R800 PSY
UP
R850 PSY
UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.5","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 April 2022

Tips

PI10713: SIP CONTAINER SENDS 404 RESPONSES AFTER APPLICATION IS STARTED BUT BEFORE VIRTUAL HOST IS BOUND

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R800 PSY

R850 PSY

Document Information

Share your feedback

Need support?