[jitsi-dev] UPDATE Request from Freeswitch returns a 501 Not Implemented, then kills the call


#1

A summary of the issue is that Freeswitch sends Jitsi an UPDATE Request. There is no method processor that appears to handle the UPDATE request, so Jitsi defaults to setting the Peer State to FAILED with a 501 Not Implemented error, but doesn't return the 501 response back to Freeswitch. Freeswitch subsequently sends me another 4 UPDATES. As a possible enhancement, I opted to explicitly handle UPDATES in the class OperationSetBasicTelephonySipImp. The enhancement does not set the Peer State to Failed, and does send back a 405 METHOD_NOT_ALLOWED. As a side point, Freeswitch completely ignores the Allow Header from which I explicitly preclude the UPDATE method and continues to send UPDATES. Is it reasonable to handle the UPDATE request in the OperationSetBasicTelephonySipImp class, or should that implementation take place elsewhere?

Thanks.

-Oren


#2

Hey Oren,

A summary of the issue is that Freeswitch sends Jitsi an UPDATE Request.
There is no method processor that appears to handle the UPDATE request,

This is correct. Unhandled methods would trigger a "501 Not
Implemented" response with no other consequences to current calls. We
actually implemented this behavior in February this year, exactly
because of a proxy that was using UPDATE requests as keep alive
messages and it did seem to resolve the problem.

so Jitsi defaults to setting the Peer State to FAILED

That part shouldn't be happening or at least not as a result of a request.

with a 501 Not Implemented error,

Hmmm ... interesting ... we generally show in the user interface only
response codes that we've received and not those that we are sending.

but doesn't return the 501 response back to Freeswitch.
Freeswitch subsequently sends me another 4 UPDATES. As a possible
enhancement, I opted to explicitly handle UPDATES in the class
OperationSetBasicTelephonySipImp. The enhancement does not set the Peer
State to Failed, and does send back a 405 METHOD_NOT_ALLOWED. As a side
point, Freeswitch completely ignores the Allow Header from which I
explicitly preclude the UPDATE method and continues to send UPDATES. Is it
reasonable to handle the UPDATE request in
the OperationSetBasicTelephonySipImp class, or should that implementation
take place elsewhere?

Well, like I said, this should already be working (even though current
code would use 501s rather than 405s). It would hence make more sense
to try and track down what's going wrong there rather than adding an
extra method handler.

Cheers,
Emil

···

On Tue, Nov 29, 2011 at 10:30 PM, Oren Forer <oren@junctionnetworks.com> wrote:


#3

Hey Emil,

Hey Oren,

A summary of the issue is that Freeswitch sends Jitsi an UPDATE Request.
There is no method processor that appears to handle the UPDATE request,

This is correct. Unhandled methods would trigger a "501 Not
Implemented" response with no other consequences to current calls. We
actually implemented this behavior in February this year, exactly
because of a proxy that was using UPDATE requests as keep alive
messages and it did seem to resolve the problem.

so Jitsi defaults to setting the Peer State to FAILED

That part shouldn't be happening or at least not as a result of a request.

Year, you're right. I don't recall how I recreated this case.

with a 501 Not Implemented error,

Hmmm ... interesting ... we generally show in the user interface only
response codes that we've received and not those that we are sending.

but doesn't return the 501 response back to Freeswitch.
Freeswitch subsequently sends me another 4 UPDATES. As a possible
enhancement, I opted to explicitly handle UPDATES in the class
OperationSetBasicTelephonySipImp. The enhancement does not set the Peer
State to Failed, and does send back a 405 METHOD_NOT_ALLOWED. As a side
point, Freeswitch completely ignores the Allow Header from which I
explicitly preclude the UPDATE method and continues to send UPDATES. Is it
reasonable to handle the UPDATE request in
the OperationSetBasicTelephonySipImp class, or should that implementation
take place elsewhere?

Well, like I said, this should already be working (even though current
code would use 501s rather than 405s). It would hence make more sense
to try and track down what's going wrong there rather than adding an
extra method handler.

I'm not sure what buggy code I discovered this behavior, but you were
right. Jitsi does not set peer state to Failed, and a 501 error does get sent back to Freeswitch.
Unfortunately, Freeswitch does send a BYE and the call gets hung up. A 405 keeps the call a live
so I think I will register for the UPDATE and send back METHOD_NOT_ALLOWED.

Thanks for your help.

···

On Nov 29, 2011, at 6:11 PM, Emil Ivov wrote:

On Tue, Nov 29, 2011 at 10:30 PM, Oren Forer <oren@junctionnetworks.com> wrote:

Cheers,
Emil


#4

Hey Oren,

<snip>

I'm not sure what buggy code I discovered this behavior, but you were
right. Jitsi does not set peer state to Failed, and a 501 error does
get sent back to Freeswitch.
Unfortunately, Freeswitch does send a BYE and the call gets hung up. A
405 keeps the call a live
so I think I will register for the UPDATE and send back METHOD_NOT_ALLOWED.

Is this their default behaviour? If so then it might be worth dropping a
note on the FreeSWITCH lists about it. There's no reason why 501 would
be interpreted as unreachability here.

Cheers,
Emil

···

On 30.11.11 19:19, Oren Forer wrote: