[SR-Users] dangers of excluding 100rel?

[Andrew Mortensen]

Can I safely strip 100rel support from INVITEs sent by callers registered to my proxy?

We're using proxy-generated 302 redirects for call forwarding in our deployment. In general this works better for us than appending branches, as we rapidly ran into branch limits when dealing with large multiple appearance lines.

However, we've run into a case where the caller, a Polycom 550, seems to get confused when a parallel forked call is redirected, 100rel is in use and the redirection target is also a multiple appearance line.

The caller is correctly responding with PRACKs to all 180s, before and after the redirection. However, hanging up the call on the caller after the redirection, but before any remote party has answered, does *not* cause the caller to send a CANCEL to tear down the call. In fact, the caller doesn't send anything at all. The remote parties continue to ring until the ring timer expires, and the proxy sends CANCELs to all callee endpoints.

That's clearly a Polycom bug, and we'll need to work with them to get it resolved.

In the meantime, I'm looking for workarounds. One quick, crude option is to strip 100rel from the Supported header in the caller's INVITE. I've tested this, and it does solve the problem, but I'm concerned about side effects. I'm aware of the value 100rel has for calls to the PSTN, but in this case the calls never leave the local network. Are there situations where 100rel is critical for a parallel forked call? 

andrew