Skip to main content

SIP RA Type - separate "100 Trying" response event

2 replies [Last post]
Joined: 2003-08-14

Open Cloud's SIP RA Type defines events for the various classes of error response, similar to what is in Mobicents' RA and the recommendation in JSR 22, ie.

javax.sip.message.Response.INFORMATIONAL // 1xx
javax.sip.message.Response.SUCCESS // 2xx
javax.sip.message.Response.REDIRECT // 3xx
javax.sip.message.Response.CLIENT_ERROR // 4xx
javax.sip.message.Response.SERVER_ERROR // 5xx
javax.sip.message.Response.GLOBAL_FAILURE // 6xx

We also added a separate event type for "100 Trying" responses

javax.sip.message.Response.TRYING // 100 only

The INFORMATIONAL event type is now used for 101-199 responses.

The reason for this is that most applications never use the 100 Trying response directly. It is only used to stop retransmits of the INVITE, and does not contain any other information. Proxies always drop 100 Trying responses - they never get forwarded. "Informational" (101-199) responses are important to applications, since they will often set up early dialogs or have SDP content.

By making "100 Trying" a separate event type, this makes it easy for the RA to filter out these responses, so they never have to enter the SLEE event router. The RA can know that no services are interested in "100 Trying" events by implementing the serviceActivated/serviceDeactivated callbacks (from JSR 240 EDR) and keeping track of the event types that services require.

If we did not have this separate event type, we would have to always fire an "INFORMATIONAL" event for "100 Trying", even though it is almost certainly not used by any application. So I think this is a simple optimization and should be part of a standard SIP RA Type.

Ben Evans
Open Cloud

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-11-02

Thanks for this information.

I think it clearly motivates the relevance of separating the 100 Trying.

I wasn't aware that "Proxies always drop 100 Trying responses - they never get forwarded".

Does this go for stateless proxies too?
Wouldn't this mean that INVITEs be inadequately retransmitted?

Joined: 2003-08-14

This doesn't apply to stateless proxies, they must forward everything.

In a chain of stateful proxies, each proxy is maintaining it's own server and client transactions, so the retransmits are hop-by-hop. Each proxies' server transaction will emit a 100 Trying upstream to quench retransmits of the INVITE, but they do not need to forward 100 Trying responses received from downstream elements.