1-way audio after re-invite

[kishanj]

Hi,

I'm able to establish a call from a SIP extension to a SIP trunk. At this point, there is 2-way audio. A few seconds after the call is established, the SIP extension modifies the SDP (connection parameters - c line) via re-invite. OXE sends a 200 OK with the SDP of the remote party but doesn't renegotiate the new SDP with the other (trunk) leg. As a result, the endpoint on the other side of the trunk continues to send RTP packets to the connection negotiated in the initial INVITE.

Can someone help me understand why OXE wouldn't re-invite the trunk leg? traced snapshot attached.

Thanks.

[frank]

Hi ..

I'm a little bit lazy here.. I can see 4 calls.. Can you make 1 trace only with 1 call ?
Thanks

[freedom]

We also had problems with one-way communications between sip device and sip trunk, but then with the call setup.
We had to change the SDP in 18x parameter to fix it.

Check the setting of 'SDP in 18x' in the sip gateway (and external sip gateway if you use this).
By default this is set to TRUE, but some applications are not able to use this.
Change it to FALSE and see if this changes anything.

[kishanj]

Hi ..

I'm a little bit lazy here.. I can see 4 calls.. Can you make 1 trace only with 1 call ?
Thanks

The very 1st call (Call-ID: 8372f800-b4e15e19-1681fc-8601a8c0@192.168.1.134) is rejected with a 422 Response.
The 2nd call (Call-ID: 840b8e80-b4e15e1a-1681fd-8601a8c0@192.168.1.134) is redirected.
You can ignore these 2 calls. Sorry about that!

The rest of the log has 2 legs of 1 call.
The 1st leg is between OXE & SIP Extension (Call-ID: b74e730-6f03a8c0-13c4-50030-1d40b8-88420b3-1d40b8)
The 2nd leg is between OXE & Sip Trunk (Call-ID: 57f4b2038ed31de2c21a38fbfcbd8af8@192.168.7.200).
OXE receives the call from SIP Extension and routes the call to the sip trunk based on the dialed number.

OXE: 192.168.7.200:5060
SIP Extension: 192.168.3.111:5060
SIP Trunk: 192.168.1.134:5068

[kishanj]

We also had problems with one-way communications between sip device and sip trunk, but then with the call setup.
We had to change the SDP in 18x parameter to fix it.

Check the setting of 'SDP in 18x' in the sip gateway (and external sip gateway if you use this).
By default this is set to TRUE, but some applications are not able to use this.
Change it to FALSE and see if this changes anything.

It is already set to FALSE.

[thanzeel]

Hi all,

I have the same issue. I have tried toggling the values but still the same behaviour. Has anyone got a solution for this.