Recently updated Jigasi (and JVB + Jitsi-meet), incoming calls no longer get Answered

Hi forum,

I recently updated my all-in-one jitsi installation changing the following packages/versions:

2019-12-17 14:05:46 upgrade jitsi-meet:all 1.0.3734-1 1.0.4101-1
2019-12-17 14:05:47 upgrade jicofo:amd64 1.0-468-1 1.0-508-1
2019-12-17 14:05:52 upgrade jitsi-meet-web:all 1.0.3387-1 1.0.3729-1
2019-12-17 14:05:53 upgrade jitsi-meet-web-config:all 1.0.3387-1 1.0.3729-1
2019-12-17 14:05:54 upgrade jitsi-meet-prosody:all 1.0.3387-1 1.0.3729-1
2019-12-17 14:05:55 upgrade jitsi-videobridge:amd64 1116-1 1126-1
2019-12-17 14:06:31 upgrade jigasi:amd64 1.0-235 1.1-38-g8f3c241-1

Before the upgrade, calls in to and out of Jigasi were working fine. Now, I am able to call out from Jigasi (add meeting participant) and everything works great. However, when I attempt to dial in to a meeting room, after looking at a SIP capture, it appears as though Jigasi is not sending a 200 OK (to answer the call) and instead initiates a new INVITE back out to the peer that the incoming call came from. Not sure why, or if something fundamental changed in these version updates that I need to be aware of?

One thing that stands out when I compare Jigasi logs from when a call worked versus now when it does not, is right around the time I expect Jigasi to say its answered the call, I see these lines stand out:

2019-12-18 02:27:01.373 INFO: [58] org.jitsi.jigasi.SipGatewaySession.peerStateChanged().1204 [ctx=15766648185361042141970] SIP peer state: Connecting
2019-12-18 02:27:01.439 SEVERE: [58] impl.protocol.sip.OperationSetBasicTelephonySipImpl.processResponse().634 Received error: 491 Request Pending
2019-12-18 02:27:01.515 INFO: [58] org.jitsi.jigasi.SipGatewaySession.peerStateChanged().1204 [ctx=15766648185361042141970] SIP peer state: Failed
2019-12-18 02:27:01.930 INFO: [109] service.protocol.media.MediaHandler.registerDynamicPTsWithStream().1003 Dynamic PT map: 126=rtpmap:-1 telephone-event/8000; 111=rtpmap:-1 opus/48000/2 fmtp:useinbandfec=1;minptime=10; 103=rtpmap:-1 unknown/90000;
2019-12-18 02:27:01.932 INFO: [109] service.protocol.media.MediaHandler.registerDynamicPTsWithStream().1020 PT overrides [103->104 ]
2019-12-18 02:27:02.081 INFO: [109] service.protocol.media.CallPeerMediaHandler.start().1961 Starting
2019-12-18 02:27:02.383 INFO: [108] service.protocol.media.MediaHandler.registerDynamicPTsWithStream().1003 Dynamic PT map: 101=rtpmap:-1 telephone-event/8000; 96=rtpmap:-1 opus/48000/2 fmtp:usedtx=1; 98=rtpmap:-1 iLBC/8000; 97=rtpmap:-1 AMR-WB/16000;
2019-12-18 02:27:02.398 SEVERE: [108] impl.protocol.sip.CallPeerSipImpl.answer().1334 Failed to create an SDP description for an OK response to an INVITE request!

I dont know if these are indicators of the cause or the result, but these codecs etc are in the second INVITE jigasi is now sending in response, instead of Answering the incoming call.

Any suggestions?

For me this is the problem. Not sure what does that mean, do you have access to the sip side to check?

Yes, although this seems to be the result of the error, not the cause of the error. Jigasi rather than answering the call initiates a NEW invite back out through the proxy, and this is the response from the proxy when it does that. It shouldnt be doing that in the first place.

I just upped the log output for Jigasi and I think I’m on to something but I’m not sure how to solve it.

When I send the invite, it gets sent to jigasi_bridge@sip.realm.name.com

sip.realm.name.com happens to point to my SIP PBX platform, and it seems as though Jigasi goes “huh. That’s not my IP. I guess this request is trying to get me to be a B2BUA so I’ll re-send this INVITE out to that host.”

How do I tell Jigasi that invites to jigasi_bridge@sip.realm.name.com are actually destined for Jigasi?

An example of the log im looking at when in FINER level that made me think this:

2019-12-19 09:38:22.684 FINE: [43] impl.protocol.sip.ProtocolProviderServiceSipImpl.getIntendedDestination().2604 Returning address sbc01.pbx.domain.net./74.104.28.113:7000 for destination sip.realm.name.com
2019-12-19 09:38:22.761 FINER: [43] impl.protocol.sip.ProtocolProviderServiceSipImpl.getIntendedDestination().2567 Will use proxy address

I don’t really get what is going on.
The easiest way to test is to install Jitsi Desktop and configure it registering to your sip service and accepting calls. If that works just look in the Advanced -> Property Editor all the properties for that sip account and transfer them to jigasi config.

I’ll give that a try. It would have been something that changed in a recent change to jigasi, since it used to work just before I upgraded jigasi.

Will try the Jitsi Desktop and see how that goes - except, I doubt jitsi desktop does auto answer like jigasi does - thats really the only part thats broken here. Outgoing calls work fine.

Not sure what you mean by auto answer, but jigasi is using the same code that is in jitsi desktop. We haven’t touched sip signalling for long time, so it sound strange … if your jigasi config works with same sip server and settings upgrade should not bring any significant change.

Isn’t you incoming call comes using the already registered sip accounts? Why would the server will send an invite and jigasi will not match it to the registered account, this sounds to me as a server config issue. The server must be calling the jigasi sip account, but not sending calls as treatinig jigasi as a sip trunk.

So I’ve still been trying to figure out what is wrong with this - I’ve tried a fresh installation / config of jigasi, and it just keeps having the same problem… I’m wondering what to do next - is there a paid support option?

All I did was upgrade the jitsi DEBs to the 1.1 versions of things that had been recently published, all the rest of the configs used to work perfectly fine on the 1.0 versions.

The primary issue appears to be (from looking in the logs) that when an incoming call comes in, rather than jigasi ANSWERING the call, it decides to try to become an outbound proxy and forward the call along as though it was an outgoing call.

When an incoming call comes in this is where it seems to go sideways:

2020-01-09 14:54:44.021 FINER: [57] impl.protocol.sip.ProxyRouter.getRouterFor().144 Router for proxy: 10.220.1.171:11000/UDP
2020-01-09 14:54:44.021 FINE: [57] impl.protocol.sip.ProxyRouter.getNextHop().167 Outbound proxy mode, using proxy 10.220.1.171:11000/UDP as hop instead of an address resolved by the SIP router

And then rather than snwering the call, it tries to place a new outgoing call through my configured SIP gateway.

Would you like me to paste a full log from the point of an incoming call to where I believe Jigasi decides to start a new call instead of answering the incoming call? It seems like it attempts to generate a call OUTBOUND to the details that were in the inbound Contact: header of the original invite.

Im just very confused because all of these configs worked perfectly before the upgrade.

an update - I just downgraded from jigasi 1.1-38-g8f3c241-1 to 1.0-235 and everything works again.

I wonder how we might be able to figure out what is different between those two versions?

I will check, but as I remember there were no changes in the sip bundle for years, which makes it strange :slight_smile: can you creat a tcpdump of such a call and send it to me, or better clear jigasi logs in var/log/jitsi restart jigasi, make a problem call and send to me all the files from it, there is a pcap file in there. You can send it to damencho At jitsi dot org.

So the 1.0-235 is ed8693b and 1.1-38-g8f3c241-1 is 8f3c241.

One thing you can try setting this property net.java.sip.communicator.impl.protocol.sip .SKIP_REINVITE_ON_FOCUS_CHANGE_PROP=true, does it change anything?

These are all the latest sip changes https://github.com/jitsi/jitsi/commits/master/src/net/java/sip/communicator/impl/protocol/sip and there are no significant changes … which leaves me puzzled about this :frowning:

Hello @damencho

I am new to this but i installed the all things with latest version and facing the same issue with latest jigasi 1.1-38-g8f3c241-1. Incoming call come but it get failed.

I am using freeswitch for the calling part.

@voxter What is the best way to downgrade it because i have installed from package using apt-get install jigasi.

Thanks

What is the failure? Can you upload logs? @vishalmpai

I did apt-get remove jigasi, then:

apt-get install jigasi=1.0-235

Thats all it took.

I will try to get an A/B comparison of logs and pcaps to share with you Damien. I’ll also try the config setting you mentioned. You should try that setting as well vishalmpai.

Certainly strange!

1 Like

@damencho here is the log of jigasi and sngrep of call. Jigasi_log.txt (6.1 KB)

As @voxter posted that invite is been resend by jigasi again back to server in place further processing.

Hello @voxter

Thanks for your help i downgraded the jigasi and it’s working fine now.

@voxter are you also using freeswitch.

@vishalmpai I suspect this does not even come to our sip bundle, as UserAgent is freeswitch it may indicate a problem in jsip we use. We haven’t seen this when we were using jitsi with freeswitch and we haven’t seen this with asterisk and many other providers we were using and are still using that sip provider.

Can you send a tcpdump and the /var/log/jitsi folder content after clearing and restarting jigasi, without that there is nothing I can do.