- Joined
- Nov 17, 2014
- Messages
- 15
- Reaction score
- 2
Hi all,
Managing incoming video call through provider, that supports video streams, to 3CX behind NAT:
Anyone has ever faced the same situation and knows how to deal with?
Scenario:
Caller 1 is an extension of PBX A (asterisk).
It flows a video call through a SIP-trunk (provider not certified) where there's a SIP-proxy.
That call reaches the PBX B (3CX 16.8.9 behind NAT), extensions are audio only IP phones.
The problem:
The INVITE (or REINVITE) received by 3CX has in the SDP payload the media audio and video and the attribute "a=sdpmod1:yes" because there's a proxy in the path.
The 200 OK sent back from 3CX has in the SDP payload:
In our understanding, "m=video 0" means that 3CX is video capable, but doesn't want to activate the video stream.
The latter attribute in our opinion is not correct, as the 3CX is not behind a proxy.
The consequence is that the RTP flow from 3CX to SIP provider is not estabilished.
We found that a call coming directly from the CPE, without Asterisk PBX, through the same provider has the same behaviour.
No problems if the caller makes an audio only call:
In that case the INVITE has audio only media, "a=sdpmod1:yes" attribute, but 3CX replyies with 200 OK with audio only media and no "a=sdpmod1:yes" attribute.
RTP flows are regularly bi-directional.
No problems even if the PBX is direcly facing Internet, without NAT.
Any suggestion is welcome.
Regards
Carlo
Managing incoming video call through provider, that supports video streams, to 3CX behind NAT:
Anyone has ever faced the same situation and knows how to deal with?
Scenario:
Caller 1 is an extension of PBX A (asterisk).
It flows a video call through a SIP-trunk (provider not certified) where there's a SIP-proxy.
That call reaches the PBX B (3CX 16.8.9 behind NAT), extensions are audio only IP phones.
The problem:
The INVITE (or REINVITE) received by 3CX has in the SDP payload the media audio and video and the attribute "a=sdpmod1:yes" because there's a proxy in the path.
The 200 OK sent back from 3CX has in the SDP payload:
Code:
m=audio (port)...
m=video 0 ...
...
a=sdpmod1:yes
In our understanding, "m=video 0" means that 3CX is video capable, but doesn't want to activate the video stream.
The latter attribute in our opinion is not correct, as the 3CX is not behind a proxy.
The consequence is that the RTP flow from 3CX to SIP provider is not estabilished.
We found that a call coming directly from the CPE, without Asterisk PBX, through the same provider has the same behaviour.
No problems if the caller makes an audio only call:
In that case the INVITE has audio only media, "a=sdpmod1:yes" attribute, but 3CX replyies with 200 OK with audio only media and no "a=sdpmod1:yes" attribute.
RTP flows are regularly bi-directional.
No problems even if the PBX is direcly facing Internet, without NAT.
Any suggestion is welcome.
Regards
Carlo
