[asterisk-bugs] [JIRA] (ASTERISK-29194) PJSIP NAT - rtp_symmetric not working
Mark Murawski (JIRA)
noreply at issues.asterisk.org
Thu Dec 3 18:25:19 CST 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-29194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252936#comment-252936 ]
Mark Murawski commented on ASTERISK-29194:
------------------------------------------
[2020-12-03 19:18:03.778] VERBOSE[19882] pbx_variables.c: Setting global variable 'SIPDOMAIN' to '10.3.2.20'
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Call (UDP:10.3.2.1:5060) to extension '*1234' sending 100 Trying
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Method is INVITE, Response is 100 Trying
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: Splitting '10.3.2.1' into...
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: ...host '10.3.2.1' and port ''.
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: Function session_inv_on_state_changed called on event TSX_STATE
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The state change pertains to the endpoint '21005()'
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The inv session still has an invite_tsx (0x7f27d8468d28)
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: There is no transaction involved in this state change
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The current inv state is INCOMING
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Source of transaction state change is TX_MSG
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: Function session_inv_on_tsx_state_changed called on event TSX_STATE
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The state change pertains to the endpoint '21005()'
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The inv session still has an invite_tsx (0x7f27d8468d28)
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The UAS INVITE transaction involved in this state change is 0x7f27d8468d28
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The current transaction state is Proceeding
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The transaction state change event is TX_MSG
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: The current inv state is INCOMING
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Media count: 1
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Processing stream 0
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Using audio-0 for new stream name
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Using new stream 0:audio-0:audio:sendrecv (nothing)
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005 Adding position 0
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: Creating new media session
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: Setting media session as default for audio
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: Done
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_session.c: 21005: Negotiating incoming SDP media stream 0:audio-0:audio:sendrecv (nothing) using audio SDP handler
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: Splitting '192.168.50.206' into...
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: ...host '192.168.50.206' and port ''.
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: Splitting '10.13.13.38' into...
[2020-12-03 19:18:03.778] DEBUG[19882] netsock2.c: ...host '10.13.13.38' and port ''.
[2020-12-03 19:18:03.778] DEBUG[19882] res_pjsip_sdp_rtp.c: Transport transport-udp bound to 10.13.13.38: Using it for RTP media.
[2020-12-03 19:18:03.778] DEBUG[19882] rtp_engine.c: Using engine 'asterisk' for RTP instance '0x55d7279c1010'
[2020-12-03 19:18:03.778] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) RTP allocated port 16344
[2020-12-03 19:18:03.778] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE creating session 10.13.13.38:16344 (16344)
[2020-12-03 19:18:03.778] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE create
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add system candidates
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: Splitting '10.13.13.38' into...
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: ...host '10.13.13.38' and port ''.
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add candidate: 10.13.13.38:16344, 2130706431
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: Splitting '10.13.13.39' into...
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: ...host '10.13.13.39' and port ''.
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add candidate: 10.13.13.39:16344, 2130706431
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: Splitting '10.1.2.20' into...
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: ...host '10.1.2.20' and port ''.
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add candidate: 10.1.2.20:16344, 2130706431
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: Splitting '10.3.2.20' into...
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: ...host '10.3.2.20' and port ''.
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add candidate: 10.3.2.20:16344, 2130706431
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: Splitting '10.20.1.1' into...
[2020-12-03 19:18:03.779] DEBUG[19882] netsock2.c: ...host '10.20.1.1' and port ''.
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE add candidate: 10.20.1.1:16344, 2130706431
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: RTP instance '0x55d7279c1010' is setup and ready to go
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE stopped
[2020-12-03 19:18:03.779] DEBUG[19882] acl.c: Attached to given IP address
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) RTCP setup on RTP instance
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Setting tx payload type 9 based on m type on 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Setting tx payload type 0 based on m type on 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Setting tx payload type 8 based on m type on 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Setting tx payload type 18 based on m type on 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Crossover copying tx to rx payload mapping 0 (0x55d727d75818) from 0x7f27b646d340 to 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Crossover copying tx to rx payload mapping 8 (0x55d727dd73e8) from 0x7f27b646d340 to 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Crossover copying tx to rx payload mapping 9 (0x55d727a9d838) from 0x7f27b646d340 to 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Crossover copying tx to rx payload mapping 18 (0x55d727ca0e98) from 0x7f27b646d340 to 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Crossover copying tx to rx payload mapping 127 (0x55d727ca5888) from 0x7f27b646d340 to 0x7f27b646d340
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying rx payload mapping 0 (0x55d727d75818) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying rx payload mapping 8 (0x55d727dd73e8) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying rx payload mapping 9 (0x55d727a9d838) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying rx payload mapping 18 (0x55d727ca0e98) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying rx payload mapping 127 (0x55d727ca5888) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying tx payload mapping 0 (0x55d727d75818) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying tx payload mapping 8 (0x55d727dd73e8) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying tx payload mapping 9 (0x55d727a9d838) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying tx payload mapping 18 (0x55d727ca0e98) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] rtp_engine.c: Copying tx payload mapping 127 (0x55d727ca5888) from 0x7f27b646d340 to 0x55d7279c11e8
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Media stream 0:audio-0:audio:sendrecv (ulaw|alaw) handled by audio
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Done with stream 0:audio-0:audio:sendrecv (ulaw|alaw)
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Handled? yes
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Processing streams
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Processing stream 0:audio-0:audio:sendrecv (ulaw|alaw)
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005 Adding position 0
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: Using existing media_session
[2020-12-03 19:18:03.779] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) RTCP ignoring duplicate property
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Stream 0:audio-0:audio:sendrecv (ulaw|alaw) added
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Done with 0:audio-0:audio:sendrecv (ulaw|alaw)
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Adding bundle groups (if available)
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Copying connection details
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Processing media 0
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Media 0 reset
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: 21005: Method is INVITE
[2020-12-03 19:18:03.779] DEBUG[19882] chan_pjsip.c: 21005
[2020-12-03 19:18:03.779] DEBUG[19882] stasis.c: Creating topic. name: channel:1607041083.36, detail:
[2020-12-03 19:18:03.779] DEBUG[19882] stasis.c: Topic 'channel:1607041083.36': 0x55d7269dcd00 created
[2020-12-03 19:18:03.779] DEBUG[19882] stasis.c: Creating topic. name: cache:113/channel:1607041083.36, detail:
[2020-12-03 19:18:03.779] DEBUG[19882] stasis.c: Topic 'cache:113/channel:1607041083.36': 0x55d727e5cc10 created
[2020-12-03 19:18:03.779] DEBUG[19882] channel.c: Channel 0x55d727dd3d60 'PJSIP/21005-00000012' allocated
[2020-12-03 19:18:03.779] DEBUG[19882] chan_pjsip.c: PJSIP/21005-00000012
[2020-12-03 19:18:03.779] DEBUG[19882] channel.c: Added datastore to channel 'PJSIP/21005-00000012', Type: T38 framehook, UID: (null)
[2020-12-03 19:18:03.779] DEBUG[19882] channel.c: Added datastore to channel 'PJSIP/21005-00000012', Type: FEATURE, UID: (null)
[2020-12-03 19:18:03.779] DEBUG[19882] chan_pjsip.c: Started PBX on new PJSIP channel PJSIP/21005-00000012
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: PJSIP/21005-00000012
[2020-12-03 19:18:03.779] DEBUG[19882] res_pjsip_session.c: PJSIP/21005-00000012
So, I see a possible issue here:
[2020-12-03 19:18:03.778] DEBUG[19882] res_rtp_asterisk.c: (0x55d7279c1010) ICE creating session 10.13.13.38:16344 (16344)
So there's a little more to the story here. There's some other transports that I didn't think were originally related, which are:
[transport-udp]
type = transport
protocol = udp
;disable_tcp_switch = yes
bind = 10.13.13.38:5060
external_media_address = 1.2.3.4 (ie: valid public ip)
external_signaling_address = 1.2.3.4 (ie: valid public ip)
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
[transport-tcp]
type = transport
protocol = tcp
bind = 10.13.13.38:5060
external_media_address = 1.2.3.5 (ie: valid public ip)
external_signaling_address = 1.2.3.5 (ie: valid public ip)
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
I'm registered to the 21005 endpoint via the transport-udp-tun1 transport, but it's trying to use the transport-udp instead?
> PJSIP NAT - rtp_symmetric not working
> -------------------------------------
>
> Key: ASTERISK-29194
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29194
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_pjsip
> Affects Versions: 16.15.0
> Reporter: Mark Murawski
> Assignee: Unassigned
>
> In certain situations PJSIP does not respect local_net settings
> Given the following setup:
> {noformat}
> 21005 | endpoint/force_rport | yes
> 21005 | endpoint/rewrite_contact | yes
> 21005 | endpoint/rtp_symmetric | yes
> [transport-udp-lo]
> type = transport
> protocol = udp
> bind = 127.0.0.1:5060
> external_media_address = 127.0.0.1
> external_signaling_address = 127.0.0.1
> external_signaling_port = 5060
> allow_reload = yes
> tos = cs3
> cos = 3
> [transport-udp-tun0]
> type = transport
> protocol = udp
> bind = 10.1.2.20:5060
> external_media_address = 10.1.2.20
> external_signaling_address = 10.1.2.20
> external_signaling_port = 5060
> allow_reload = yes
> tos = cs3
> cos = 3
> local_net = 10.1.2.0/24
> [transport-udp-tun1]
> type = transport
> protocol = udp
> bind = 10.3.2.20:5060
> external_media_address = 10.3.2.20
> external_signaling_address = 10.3.2.20
> external_signaling_port = 5060
> allow_reload = yes
> tos = cs3
> cos = 3
> local_net = 10.3.2.0/24
> {noformat}
> And traffic coming into transport-udp-tun1
> {noformat}
> 15:36:45.656238 IP 10.3.2.1.5060 > 10.3.2.20.5060: SIP: INVITE sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> E`..B%..>...
> ...
> ...........INVITE sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.50.206;branch=z9hG4bKe661cfb7BD8F7712
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>
> CSeq: 1 INVITE
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> Contact: <sip:21005 at 192.168.50.206>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
> User-Agent: PolycomSoundPointIP-SPIP_550-UA/4.0.15.1009
> Accept-Language: en
> Supported: 100rel,replaces
> Allow-Events: conference,talk,hold
> Max-Forwards: 70
> Content-Type: application/sdp
> Content-Length: 298
> v=0
> o=- 1607027804 1607027804 IN IP4 192.168.50.206
> s=Polycom IP Phone
> c=IN IP4 192.168.50.206
> t=0 0
> a=sendrecv
> m=audio 2228 RTP/AVP 9 0 8 18 127
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:127 telephone-event/8000
> 15:36:45.657358 IP 10.3.2.20.5060 > 10.3.2.1.5060: SIP: SIP/2.0 401 Unauthorized
> E`.Ry. at .@...
> ...
> ........>"#SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP 192.168.50.206;rport=5060;received=10.3.2.1;branch=z9hG4bKe661cfb7BD8F7712
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>;tag=z9hG4bKe661cfb7BD8F7712
> CSeq: 1 INVITE
> WWW-Authenticate: Digest realm="asterisk",nonce="1607027805/57d9f055573ea588c2beb1f03c8e2bca",opaque="345e83785480fbf0",algorithm=md5,qop="auth"
> Server: Asterisk PBX 16.15.0
> Content-Length: 0
> 15:36:45.698544 IP 10.3.2.1.5060 > 10.3.2.20.5060: SIP: ACK sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> E`.GB&..>. .
> ...
> ........3j.ACK sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.50.206;branch=z9hG4bKe661cfb7BD8F7712
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>;tag=z9hG4bKe661cfb7BD8F7712
> CSeq: 1 ACK
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> Contact: <sip:21005 at 192.168.50.206>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
> User-Agent: PolycomSoundPointIP-SPIP_550-UA/4.0.15.1009
> Accept-Language: en
> Max-Forwards: 70
> Content-Length: 0
> 15:36:45.698568 IP 10.3.2.1.5060 > 10.3.2.20.5060: SIP: INVITE sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> E`..B'..>..n
> ...
> ..........6INVITE sip:*1234 at 10.3.2.20:5060;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.50.206;branch=z9hG4bK3302ce1eA5B33949
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>
> CSeq: 2 INVITE
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> Contact: <sip:21005 at 192.168.50.206>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
> User-Agent: PolycomSoundPointIP-SPIP_550-UA/4.0.15.1009
> Accept-Language: en
> Supported: 100rel,replaces
> Allow-Events: conference,talk,hold
> Authorization: Digest username="21005", realm="asterisk", nonce="1607027805/57d9f055573ea588c2beb1f03c8e2bca", qop=auth, cnonce="hTWM3tpAkuCZjNC", nc=00000001, opaque="345e83785480fbf0", uri="sip:*1234 at 10.3.2.20:5060;user=phone", response="7e4d360452dbfdf02c7297786403e104", algorithm=MD5
> Max-Forwards: 70
> Content-Type: application/sdp
> Content-Length: 298
> v=0
> o=- 1607027804 1607027804 IN IP4 192.168.50.206
> s=Polycom IP Phone
> c=IN IP4 192.168.50.206
> t=0 0
> a=sendrecv
> m=audio 2228 RTP/AVP 9 0 8 18 127
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:127 telephone-event/8000
> 15:36:45.701474 IP 10.3.2.20.5060 > 10.3.2.1.5060: SIP: SIP/2.0 100 Trying
> E`..y3 at .@...
> ...
> ...........SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.50.206;rport=5060;received=10.3.2.1;branch=z9hG4bK3302ce1eA5B33949
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>
> CSeq: 2 INVITE
> Server: Asterisk PBX 16.15.0
> Content-Length: 0
> 15:36:45.716260 IP 10.3.2.20.5060 > 10.3.2.1.5060: SIP: SIP/2.0 200 OK
> E`..y4 at .@...
> ...
> .........v.SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.50.206;rport=5060;received=10.3.2.1;branch=z9hG4bK3302ce1eA5B33949
> Call-ID: cfd9c5fd-64b01f78-fa86f683 at 192.168.50.206
> From: "21005" <sip:21005 at 10.3.2.20>;tag=9BA63BB1-914B7CEC
> To: <sip:*1234 at 10.3.2.20;user=phone>;tag=9e82c96e-4b35-4ac9-a055-21970e96c5fd
> CSeq: 2 INVITE
> Server: Asterisk PBX 16.15.0
> Contact: <sip:1.2.3.4:5060>
> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
> Supported: 100rel, timer, replaces, norefersub
> Content-Type: application/sdp
> Content-Length: 255
> v=0
> o=- 1607027804 1607027806 IN IP4 10.3.2.20
> s=Asterisk
> c=IN IP4 10.3.2.20
> t=0 0
> m=audio 16430 RTP/AVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> a=fmtp:127 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> {noformat}
> ------------------
> The following occurs:
> {noformat}
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030925, ts 006080, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030926, ts 006240, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030927, ts 006400, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030928, ts 006560, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030929, ts 006720, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030930, ts 006880, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030931, ts 007040, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030932, ts 007200, len 000160)
> Sent RTP packet to 192.168.50.206:2228 (type 00, seq 030933, ts 007360, len 000160)
> {noformat}
> Instead of sending to the expected rewrite_contact of 10.3.2.1
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list