[PJSIP] - Without video but with audio

Asterisk Asterisk SIP
1

Hi,

PBX - 35.X.X.X (Private Google Cloud 10.142.0.7)
GDS3710 (intercom) - IP NAT for tunnel IPSEC 172.16.40.5 or 172.16.100.5 (other GDS)
GSC3570 (monitor video) - IP NAT for tunnel IPSEC 100.64.9.91

The PBX is in the cloud and joins the remote offices through an IPsec tunnel by policy. The PBX only knows the NAT IPs of the tunnels on each remote end (attach diagram).Network diagram

We have a problem with the video of a grandstream GSC3570 that goes through asterisk.

The audio is correct, but there is no video and it is because in the CONTACT and in SDP c= the private LAN IP appears instead of the NAT IP.

PJSIP:

Templates:

[tp-udp-internas]
type = transport
protocol = udp
bind = 0.0.0.0:5090
tos = af31

[internas-udp](!)
type = endpoint
transport = tp-udp-internas
context = dp_internas
allow = !all,ulaw,alaw,g722,h264
direct_media = no
trust_id_outbound = yes
device_state_busy_at = 1
dtmf_mode = rfc4733
send_pai = yes
send_rpid = yes
language = es
tos_audio = ef
tos_video = af41

[sig](!)
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
rtp_timeout = 60
rtp_timeout_hold = 60
rtp_keepalive = 90

Endpoint:

[7103](internas-udp,sig)
auth = 7103-auth
aors = 7103
context = dp_intercom_ops01
callerid = GSC3570 OPS.01 <7103>
mailboxes = 7103@buzones

RTP

; Audio GDS3710
       > 0x7f720c0a8720 -- Strict RTP learning after remote address set to: 192.168.2.4:5004
       > 0x7f720c0a8720 -- Strict RTP qualifying stream type: audio
       > 0x7f720c0a8720 -- Strict RTP switching source address to 172.16.40.5:5004
       > 0x7f720c0a8720 -- Strict RTP learning complete - Locking on source address 172.16.40.5:5004
; Video GDS3710	   
       > 0x7f720c0dae10 -- Strict RTP learning after remote address set to: 192.168.2.4:5006
       > 0x7f720c0dae10 -- Strict RTP qualifying stream type: video
       > 0x7f720c0dae10 -- Strict RTP switching source address to 172.16.40.5:5006
       > 0x7f720c0dae10 -- Strict RTP learning complete - Locking on source address 172.16.40.5:5006	   

; Audio GSC3570
       > 0x7f71f81175f0 -- Strict RTP learning after remote address set to: 10.4.1.12:5004
       > 0x7f71f81175f0 -- Strict RTP qualifying stream type: audio
       > 0x7f71f81175f0 -- Strict RTP switching source address to 100.64.9.91:5004	   
       > 0x7f71f81175f0 -- Strict RTP learning complete - Locking on source address 100.64.9.91:5004	   

; Video
       > 0x7f71f8032270 -- Strict RTP learning after remote address set to: 10.4.1.12:5006
	   ¿?¿?¿?¿?

If you notice, the GSC for audio does the opposite as it does for video.

For audio, the flow correctly changes from the Private LAN IP 10.4.1.12 to the NAT IP 100.64.9.91 (rewrite_contact).

For the video it does not do the NAT (rewrite) and the PBX does not know the route to the Private IP 10.4.1.12 (since it is not in its route table) and the video is lost.

Capture SIP

          100.64.9.91:5060              10.142.0.7:5090  |Via: SIP/2.0/UDP 10.4.1.12:5060;branch=z9hG4bK1426364600;rport
          ----------+---------          ----------+---------|From: "7103" <sip:7103@10.142.0.7:5090>;tag=1845701404
  16:10:09.018038   |        INVITE (SDP)         |         |To: <sip:150@10.142.0.7:5090>
        +0.147644   | --------------------------> |         |Call-ID: 83632918-5060-37@BA.E.B.BC
  16:10:09.165682   |             ACK             |         |CSeq: 360 INVITE
        +0.154707   | --------------------------> |         |Contact: "7103" <sip:7103@10.4.1.12:5060>
  16:10:09.320389   |        INVITE (SDP)         |         |Max-Forwards: 70
        +0.452393   | --------------------------> |         |User-Agent: Grandstream GSC3570 1.0.7.5
  16:10:09.772782   |             ACK             |         |Privacy: none
                    | --------------------------> |         |P-Preferred-Identity: "7103" <sip:7103@10.142.0.7:5090>
                    |                             |         |P-Access-Network-Info: IEEE-EUI-48;eui-48-addr=D8-B3-70-54-F5-41
                    |                             |         |P-Emergency-Info: IEEE-EUI-48;eui-48-addr=C0-74-AD-DF-83-50
                    |                             |         |Supported: replaces, path
                    |                             |         |Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
                    |                             |         |Content-Type: application/sdp
                    |                             |         |Accept: application/sdp, application/dtmf-relay
                    |                             |         |Content-Length:   668
                    |                             |         |
                    |                             |         |v=0
                    |                             |         |o=7103 8000 8000 IN IP4 10.4.1.12
                    |                             |         |s=SIP Call
                    |                             |         |c=IN IP4 10.4.1.12
                    |                             |         |t=0 0
                    |                             |         |m=audio 5004 RTP/AVP 9 8 0 101
                    |                             |         |a=sendrecv
                    |                             |         |a=rtpmap:9 G722/8000
                    |                             |         |a=ptime:20
                    |                             |         |a=rtpmap:8 PCMA/8000
                    |                             |         |a=rtpmap:0 PCMU/8000
                    |                             |         |a=rtpmap:101 telephone-event/8000
                    |                             |         |a=fmtp:101 0-15
                    |                             |         |m=video 5006 RTP/AVP 99 100 101 34 100
                    |                             |         |b=AS:2048
                    |                             |         |a=sendrecv
                    |                             |         |a=rtpmap:99 H264/90000
                    |                             |         |a=fmtp:99 profile-level-id=42801F; packetization-mode=1
                    |                             |         |a=rtpmap:100 H264/90000
                    |                             |         |a=fmtp:100 profile-level-id=4D001F; packetization-mode=1
                    |                             |         |a=rtpmap:101 H264/90000
                    |                             |         |a=fmtp:101 profile-level-id=64001F; packetization-mode=1
                    |                             |         |a=rtpmap:34 H263/90000
                    |                             |         |a=fmtp:34 CIF=2; QCIF=2

How can I force the CONTACT or SDP field in Asterisk to the NAT IP? 100.64.9.91

Thanks!
Regards,

2

By setting signalling and media addresses on the transport, and excluding the local networks. This is the same as the, very common, case of Asterisk behind NAT accessing a SIP provider.

3

Hi,

Thanks for your reply. But this is not the typical case of NAT.

I do not need signalling and media addresses in transport.

The IPsec tunnel is established and there is direct connectivity to IPsec Private IP and IP NAT remote sites.

Therefore, as in the thread, the audio does it well and rewrites the address in the contact and the RTP does the “switching” to the correct IP.

Regards,

4

I’m assuming that the audio is working because the remote end is applying a symmetric media work around, but that requires media to flow from Asterisk.

Normally there is no NAT on tunnels, so they are treated as part of the local network, but you explicitly mentioned NAT.

5

Since the audio works, I suppose it will be a symmetric media problem with the video and it seems like a problem with the grandstream. Thanks for the help, I’ll keep checking.

6

Symmetric media is a work around for inadequate NAT handling. Properly configure for operation behind NAT, Asterisk should not need to rely on the other side assuming symmetric media.

7

Option en GSC - Use NAT IP.

Thanks.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.