Invite without SDP

[jjwerkman]

Is there a way to configure 3CX so that it will respond with "200 OK" at a invite withoud SDP? There is a problem with transfering call's.

 

[davidbenwell]

what phones are you using?

 

[jjwerkman]

Let me explain a little bit.
My SIP provider wants to test several things before we can connect to there network. One of the tests is the following scenario:

Call scenario: PSTN 1 call 3CX ==> 3CX answer the call ==> PSTN put the call on hold and initiate another call to the PSTN 2 ==> PSTN 1 do transfer the call by hang-up. 3CX party and PSTN 2 should be connected together, connection failed.

There is an INVITE (without SDP) sending to 3CX from PSTN 1, the 3CX did not send 200 OK which caused that the other party PSTN 1 repeat sending the INVITE until timeout which cause code 487 . we see that the device 192.168.210.150 respond correctly to 3CX with 200 OK but this response is not passed thru the 3CX to the PSTN 1 party. Conclusion: 3CX should response on the INVITE with 200 OK.

 

[mixig]

We have one setup whre our providr is not sending SDP and everything is working fine. They have H323 in their network but on client side they have SIP trunk to the 3cx...

 

[lneblett]

Out of curiosity, what settings do you have set for this provider? Is support re-invite or support replaces checked? You might try these settings.

You might want to look at a wireshark capture and see the scenario play out. The implication is that the Trunking agent is taking care of the messaging handling at their end such that switching from the PSTN device # 1 and substituting PSTN device # 2 is completely transparent. If so, then one might argue, why a need for an invite if nothing has changed. I am not certain that sending an invite in this scenario is actually a valid request as a UAS is not normally allowed to send another invite until the original invite has been terminated. It can however send a re-invite or replaces or updates.

A wireshark is really needed as I get the sense that when the initial call from PSTN 1 is placed an Invite and SDP is provided and 3CX responds with an ACK; otherwise the call would never have made it through to 3CX to begin your scenario. As a result you are in a "session". I do not know what the device is with the internal IP sending the ACK (200) and if even related to the same. You indicate that PSTN continues to send an Invite, which at this point I am thinking the transfer at the Trunking agent side has already been completed, so if really PSTN #1 is still sending the Invite, the original Invite is still in play and this is not needed. It should be a re-invite. However, an Invite can be sent, and the response MAY be sent, but the key is "May".

 

[jjwerkman]

The setting 'Supports Re-Invite' was already enabled. I enabled also the Replace option now and asked the provider to test again. I'm waiting for a answer now.

Strange thing is that in my own test everything works fine. But in the tests of our provider, who needs to approve this PBX, it didn't work.
I have a PCAP file. I'm unfortunately not that good in Wireshark. Maybe you can take a look? Many thanks.

 

[lneblett]

Let's see what the provider says and then go from there. I can look at the capture, but you will likely need to guide me as to who each IP is relative to your testing, but as they are already looking at it, the need may not exist.

 

[jjwerkman]

Provider had no success with new tests and Re-Invites and Replace enabled.
Attached two ZIP files with PCAP files (PCAP files not allowed).

62.140.159.244 VoIP Provider
62.140.159.243 VoIP Provider
192.168.210.150 Phone
192.168.210.151 Phone (I think not used in this test)

 

[lneblett]

OK, I am now a little confused.

You provide files that portend to show a test run with SDP content and the other without. Just exactly what is it that the provider is claiming that results in 3CX not meeting whatever their criteria is?

I can read and interpret the files, but they are the ones indicating some issue and they should be able to point out what the issue is and what the expected response or corrective action should be.

Where the confusion lies is with the initial subject Invite without SDP, but you now have a file labeled as Invite with SDP, implying that the SDP either fixed things or is no longer an issue as the carrier could adapt or.,,,,,,,,,,both are now issues.