[asterisk-bugs] [JIRA] (ASTERISK-25676) native_rtp Lets through Codec not in the Allowed List instead of Transcoding
Peter Sokolov (JIRA)
noreply at issues.asterisk.org
Tue Jan 19 04:43:33 CST 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-25676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Sokolov updated ASTERISK-25676:
-------------------------------------
Comment: was deleted
(was: I think that I was able to find the cause for the problem.
When chan_sip receives the first INVITE, it simply copies all the codecs from the SDP offer to the ast_rtp_codecs structure of the call originating SIP device (the one read by: ast_rtp_instance_get_codecs(instance1)). It does not respect allow/disallow from sip.conf while building this structure, even though it logs a bit later: "We're settling with these formats: (g722)". Here is an example for the peer with allow=g722 in sip.conf:
{code}
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: chan_sip.c:10496 process_sdp: Processing media-level (audio) SDP a=ptime:30... OK.
Capabilities: us - (g722), peer - audio=(ulaw|g726|alaw|g722|ilbc)/video=(nothing)/text=(nothing), combined - (g722)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: res_rtp_asterisk.c:4833 ast_rtp_remote_address_set: Setting RTCP address on RTP instance '0x20400b8'
Peer audio RTP is at port 83.59.72.142:7086
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 0 (0x1b379b0) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 2 (0x20e8b60) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 8 (0x1b37cd0) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 9 (0x1b37d10) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 97 (0x1d52c90) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 101 (0x21152b0) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: rtp_engine.c:633 ast_rtp_codecs_payloads_copy: Copying payload 102 (0x1d58480) from 0x7f4e30cdd470 to 0x2040280
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: res_rtp_asterisk.c:4740 ast_rtp_prop_set: Ignoring duplicate RTCP property on RTP instance '0x20400b8'
[Jan 18 23:41:52] DEBUG[9196][C-00000006]: chan_sip.c:10790 process_sdp: We're settling with these formats: (g722)
{code}
The RTP layer however uses that structure to check whether a codec is allowed or not for a peer (rtp_engine.c / ast_rtp_codecs_find_payload_code):
{code}
/* If the payload coming in is not one of the negotiated ones then send it to the core, this will cause formats to change and the bridge to break */
if (ast_rtp_codecs_find_payload_code(ast_rtp_instance_get_codecs(instance1), bridged_payload) == -1) {
ast_debug(1, "Unsupported payload type received \n");
return -1;
}
{code}
ast_rtp_codecs_find_payload_code returns as valid all codecs present in the structure ast_rtp_codecs of the call originating SIP device. And that one contains all codecs from the offer instead of those limited by allow/disallow from sip.conf. This causes that while the native_rtp is active, packets are let through without transcoding them for some formats that are not in the list of allowed codecs for that SIP peer.
I can see two possible solutions:
a) On INVITE only copy allowed codecs from SDP offer to the ast_rtp_codecs structure of the call originating SIP device. The same way as the message "We're settling with these formats: (g722)" is constructed.
or
b) In ast_rtp_codecs_find_payload_code check whether the codec is in the list of allowed ones for the SIP device before returning it as a valid one. This might be tricky as the RTP layer might not have the access to the channel layer where this information is present.
The option a) would probably be the better one. If there is a reason for the not allowed codecs for a peer to be in that list, then an additional flag, marking the codec as allowed and evaluated in the ast_rtp_codecs_find_payload_code would be necessary.)
> native_rtp Lets through Codec not in the Allowed List instead of Transcoding
> ----------------------------------------------------------------------------
>
> Key: ASTERISK-25676
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-25676
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Affects Versions: 13.7.0
> Environment: Debian 8.2
> Reporter: Peter Sokolov
> Assignee: Unassigned
>
> The call originating SIP device only has g722 in the list of allowed codecs and directmedia=no set in its configuration. On a call to SIP destination that replies with alaw (183 and OK), Asterisk 13 will correctly transcode alaw to g722 during the early media, however as soon as the connection is established (OK) and the bridge switches to native_rtp, it will simply let through the alaw packets even though alaw is not in the list of allowed codecs for the originating SIP device. As this device does not expect alaw (not indicated in the OK SDP), the voice cannot be understood.
> To reproduce, configure like below. 333 is a SIP phone (FritzBox in my case) that supports g722 and alaw. OutTrunk is a SIP trunk provider that does not support g722 for calls out of its network (it replies with alaw only in 183 and OK SDP). At least one peer has to be set to directmedia=no in a way that RTP always flows via Asterisk.
> Make a call from peer 333 to a number that is routed through OutTrunk. When OutTrunk sends 183 with only alaw in SDP, you will see that Asterisk sends 183 with g722 in SDP to peer 333 and will transcode the alaw early media to g722. As soon as the connection is established and OutTrunk sends OK with only alaw in SDP, you will see that Asterisk sends OK with g722 in SDP to peer 333, however native_rtp bridge will let through the alaw media to the peer 333 even though alaw is neither in the list of allowed codecs for the peer 333 nor in the OK reply sent by Asterisk to peer 333.
> {code}
> sip.conf:
> [333]
> type=friend
> context=users
> subscribecontext=users
> secret=donttell
> language=de
> mailbox=333 at default
> host=dynamic
> dtmfmode=rfc2833
> defaultuser=333
> callerid=333 <00333>
> restrictcid=no
> fromdomain=test.tst
> directmedia=no
> nat=no
> insecure=port
> call-limit=5
> allowsubscribe=yes
> disallow=all
> allow=g722
> [OutTrunk]
> type=peer
> fromdomain=test2.tst
> defaultuser=user1
> secret=donttell
> host=test2.tst
> context=users
> directmedia=yes
> qualify=no
> insecure=port,invite
> promiscredir=no
> dtmfmode=rfc2833
> nat=no
> disallow=all
> allow=g722,alaw
> callgroup=1
> t38pt_udptl=no
> t38pt_rtp=no
> t38pt_tcp=no
> extensions.conf:
> [users]
> exten => 123,1,NoOp
> exten => 123,n,Set(CALLERID(number)=00333)
> exten => 123,n,Set(CALLERID(name)=${CALLERID(number):2})
> exten => 123,n,Set(CALLERID(number)=${CALLERID(number):2})
> exten => 123,n,Dial(SIP/${EXTEN}@OutTrunk,60,)
> exten => 123,n,Hangup
> {code}
> Here is the log where "Sent RTP P2P packet" forwarding the alaw packet without transcoding can be seen:
> {code}
> <--- SIP read from UDP:X.X.X.X:5060 --->
> INVITE sip:123 at test.tst SIP/2.0
> Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK7D8CF25D90C364B9
> From: <sip:333 at test.tst>;tag=A4D1A0E52D14A452
> To: <sip:123 at test.tst>
> Call-ID: 241FB38ED47A0E77 at 192.168.0.30
> CSeq: 2573 INVITE
> Contact: <sip:333 at X.X.X.X;uniq=C09040DC74C0F2A9D6039136CB478>
> Max-Forwards: 70
> Expires: 120
> User-Agent: AVM FRITZ!Box 7330 107.06.30 (Jul 10 2015)
> Supported: 100rel,replaces
> Allow-Events: telephone-event,refer
> Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
> Content-Type: application/sdp
> Accept: application/sdp, multipart/mixed
> Accept-Encoding: identity
> Content-Length: 433
> v=0
> o=user 9081636 9081636 IN IP4 X.X.X.X
> s=call
> c=IN IP4 X.X.X.X
> t=0 0
> m=audio 7078 RTP/AVP 9 8 0 2 102 100 99 97 120 121 101
> a=sendrecv
> a=rtpmap:2 G726-32/8000
> a=rtpmap:102 G726-32/8000
> a=rtpmap:100 G726-40/8000
> a=rtpmap:99 G726-24/8000
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=30
> a=rtpmap:120 PCMA/16000
> a=rtpmap:121 PCMU/16000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtcp:7079
> a=ptime:30
> <------------->
> --- (18 headers 19 lines) ---
> Sending to X.X.X.X:5060 (no NAT)
> Using INVITE request as basis request - 241FB38ED47A0E77 at 192.168.0.30
> Found peer '333' for '333' from X.X.X.X:5060
> == Using SIP RTP CoS mark 5
> Found RTP audio format 9
> Found RTP audio format 8
> Found RTP audio format 0
> Found RTP audio format 2
> Found RTP audio format 102
> Found RTP audio format 100
> Found RTP audio format 99
> Found RTP audio format 97
> Found RTP audio format 120
> Found RTP audio format 121
> Found RTP audio format 101
> Found audio description format G726-32 for ID 2
> Found audio description format G726-32 for ID 102
> Found unknown media description format G726-40 for ID 100
> Found unknown media description format G726-24 for ID 99
> Found audio description format iLBC for ID 97
> Found unknown media description format PCMA for ID 120
> Found unknown media description format PCMU for ID 121
> Found audio description format telephone-event for ID 101
> Capabilities: us - (g722), peer - audio=(ulaw|g726|alaw|g722|ilbc)/video=(nothing)/text=(nothing), combined - (g722)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port X.X.X.X:7078
> Looking for 123 in users (domain test.tst)
> sip_route_dump: route/path hop: <sip:333 at X.X.X.X;uniq=C09040DC74C0F2A9D6039136CB478>
> <--- Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 100 Trying
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK7D8CF25D90C364B9;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=A4D1A0E52D14A452
> t: <sip:123 at test.tst>
> i: 241FB38ED47A0E77 at 192.168.0.30
> CSeq: 2573 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> l: 0
> <------------>
> -- Executing [123 at users:1] NoOp("SIP/333-000001f3", "") in new stack
> -- Executing [123 at users:2] NoOp("SIP/333-000001f3", "") in new stack
> -- Executing [123 at users:3] Set("SIP/333-000001f3", "CALLERID(name)=333") in new stack
> -- Executing [123 at users:4] Set("SIP/333-000001f3", "CALLERID(number)=333") in new stack
> -- Executing [123 at users:5] Dial("SIP/333-000001f3", "SIP/123 at OutTrunk,60,") in new stack
> == Using SIP RTP CoS mark 5
> Audio is at 12608
> Adding codec g722 to SDP
> Adding codec alaw to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (no NAT) to D.D.D.D:5060:
> INVITE sip:123 at test2.tst SIP/2.0
> v: SIP/2.0/UDP A.A.A.A:5060;branch=z9hG4bK5b61c9e2
> Max-Forwards: 70
> f: "333" <sip:333 at test2.tst>;tag=as4c31698e
> t: <sip:123 at test2.tst>
> m: <sip:333 at A.A.A.A:5060>
> i: 669e68ca24c091413a62b0e06a0c2128 at test2.tst
> CSeq: 102 INVITE
> User-Agent: Asterisk
> Date: Sat, 09 Jan 2016 21:27:20 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> c: application/sdp
> l: 279
> v=0
> o=root 1956784559 1956784559 IN IP4 A.A.A.A
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 A.A.A.A
> t=0 0
> m=audio 12608 RTP/AVP 9 8 101
> a=rtpmap:9 G722/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> ---
> -- Called SIP/123 at OutTrunk
> <--- SIP read from UDP:D.D.D.D:5060 --->
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 172.31.1.100:5060;branch=z9hG4bK5b61c9e2
> From: "333" <sip:333 at test2.tst>;tag=as4c31698e
> To: <sip:123 at test2.tst>
> Contact: sip:123 at D.D.D.D:5060
> Call-ID: 669e68ca24c091413a62b0e06a0c2128 at test2.tst
> CSeq: 102 INVITE
> Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
> Content-Length: 0
> <------------->
> --- (10 headers 0 lines) ---
> <--- SIP read from UDP:D.D.D.D:5060 --->
> SIP/2.0 183 Session progress
> Via: SIP/2.0/UDP 172.31.1.100:5060;branch=z9hG4bK5b61c9e2
> From: "333" <sip:333 at test2.tst>;tag=as4c31698e
> To: <sip:123 at test2.tst>;tag=360313ac55ed93a8b99b71
> Contact: sip:123 at D.D.D.D:5060
> Call-ID: 669e68ca24c091413a62b0e06a0c2128 at test2.tst
> CSeq: 102 INVITE
> Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
> Content-Type: application/sdp
> Content-Length: 212
> v=0
> o=CARRIER 1452374900 1452374900 IN IP4 G.G.G.G
> s=SIP Call
> c=IN IP4 G.G.G.G
> t=0 0
> m=audio 26660 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=ptime:20
> a=sendrecv
> <------------->
> --- (11 headers 10 lines) ---
> sip_route_dump: route/path hop: <sip:123 at D.D.D.D:5060>
> Found RTP audio format 8
> Found RTP audio format 101
> Found audio description format PCMA for ID 8
> Found audio description format telephone-event for ID 101
> Capabilities: us - (g722|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port G.G.G.G:26660
> -- SIP/OutTrunk-000001f4 is making progress passing it to SIP/333-000001f3
> Audio is at 17508
> Adding codec g722 to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> <--- Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 183 Session Progress
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK7D8CF25D90C364B9;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=A4D1A0E52D14A452
> t: <sip:123 at test.tst>;tag=as521bc73b
> i: 241FB38ED47A0E77 at 192.168.0.30
> CSeq: 2573 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> c: application/sdp
> l: 253
> v=0
> o=root 486862468 486862468 IN IP4 A.A.A.A
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 A.A.A.A
> t=0 0
> m=audio 17508 RTP/AVP 9 101
> a=rtpmap:9 G722/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> <------------>
> > 0x27e1720 -- Probation passed - setting RTP source address to G.G.G.G:26660
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026726, ts 3738337846, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007407, ts 000120, len 000160)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026727, ts 3738338006, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007408, ts 000280, len 000160)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026728, ts 3738338166, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007409, ts 000440, len 000160)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026729, ts 3738338326, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007410, ts 000600, len 000160)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026730, ts 3738338486, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007411, ts 000760, len 000160)
> > 0x253cd30 -- Probation passed - setting RTP source address to X.X.X.X:7078
> Got RTP packet from X.X.X.X:7078 (type 09, seq 000001, ts 000240, len 000160)
> Sent RTP packet to G.G.G.G:26660 (type 08, seq 049922, ts 000152, len 000160)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026731, ts 3738338646, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007412, ts 000920, len 000160)
> Got RTP packet from X.X.X.X:7078 (type 09, seq 000002, ts 000480, len 000240)
> Sent RTP packet to G.G.G.G:26660 (type 08, seq 049923, ts 000392, len 000240)
> Got RTP packet from G.G.G.G:26660 (type 08, seq 026732, ts 3738338806, len 000160)
> Sent RTP packet to X.X.X.X:7078 (type 09, seq 007413, ts 001080, len 000160)
> <--- SIP read from UDP:D.D.D.D:5060 --->
> SIP/2.0 200 Ok
> Via: SIP/2.0/UDP 172.31.1.100:5060;branch=z9hG4bK5b61c9e2
> From: "333" <sip:333 at test2.tst>;tag=as4c31698e
> To: <sip:123 at test2.tst>;tag=360313ac55ed93a8b99b71
> Contact: sip:123 at D.D.D.D:5060
> Call-ID: 669e68ca24c091413a62b0e06a0c2128 at test2.tst
> CSeq: 102 INVITE
> Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
> Content-Type: application/sdp
> Content-Length: 212
> v=0
> o=CARRIER 1452374913 1452374913 IN IP4 G.G.G.G
> s=SIP Call
> c=IN IP4 G.G.G.G
> t=0 0
> m=audio 26660 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=ptime:20
> a=sendrecv
> <------------->
> --- (11 headers 10 lines) ---
> Found RTP audio format 8
> Found RTP audio format 101
> Found audio description format PCMA for ID 8
> Found audio description format telephone-event for ID 101
> Capabilities: us - (g722|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port G.G.G.G:26660
> sip_route_dump: route/path hop: <sip:123 at D.D.D.D:5060>
> set_destination: Parsing <sip:123 at D.D.D.D:5060> for address/port to send to
> set_destination: set destination to D.D.D.D:5060
> Transmitting (no NAT) to D.D.D.D:5060:
> ACK sip:123 at D.D.D.D:5060 SIP/2.0
> v: SIP/2.0/UDP A.A.A.A:5060;branch=z9hG4bK0442d057
> Max-Forwards: 70
> f: "333" <sip:333 at test2.tst>;tag=as4c31698e
> t: <sip:123 at test2.tst>;tag=360313ac55ed93a8b99b71
> m: <sip:333 at A.A.A.A:5060>
> i: 669e68ca24c091413a62b0e06a0c2128 at test2.tst
> CSeq: 102 ACK
> User-Agent: Asterisk
> l: 0
> ---
> -- SIP/OutTrunk-000001f4 answered SIP/333-000001f3
> Audio is at 17508
> Adding codec g722 to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> <--- Reliably Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 200 OK
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK7D8CF25D90C364B9;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=A4D1A0E52D14A452
> t: <sip:123 at test.tst>;tag=as521bc73b
> i: 241FB38ED47A0E77 at 192.168.0.30
> CSeq: 2573 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> c: application/sdp
> l: 253
> v=0
> o=root 486862468 486862468 IN IP4 A.A.A.A
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 A.A.A.A
> t=0 0
> m=audio 17508 RTP/AVP 9 101
> a=rtpmap:9 G722/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> <------------>
> -- Channel SIP/OutTrunk-000001f4 joined 'simple_bridge' basic-bridge <94935aef-db90-4ff7-ac85-60d04663af6d>
> -- Channel SIP/333-000001f3 joined 'simple_bridge' basic-bridge <94935aef-db90-4ff7-ac85-60d04663af6d>
> > Bridge 94935aef-db90-4ff7-ac85-60d04663af6d: switching from simple_bridge technology to native_rtp
> > Locally RTP bridged 'SIP/333-000001f3' and 'SIP/OutTrunk-000001f4' in stack
> > Locally RTP bridged 'SIP/333-000001f3' and 'SIP/OutTrunk-000001f4' in stack
> > 0x27e1720 -- Probation passed - setting RTP source address to G.G.G.G:26660
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> <--- SIP read from UDP:X.X.X.X:5060 --->
> ACK sip:123 at 172.31.1.100:5060 SIP/2.0
> Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKF1AA2AEE2EEA0175
> From: <sip:333 at test.tst>;tag=A4D1A0E52D14A452
> To: <sip:123 at test.tst>;tag=as521bc73b
> Call-ID: 241FB38ED47A0E77 at 192.168.0.30
> CSeq: 2573 ACK
> Contact: <sip:333 at X.X.X.X;uniq=C09040DC74C0F2A9D6039136CB478>
> Max-Forwards: 70
> User-Agent: AVM FRITZ!Box 7330 107.06.30 (Jul 10 2015)
> Content-Length: 0
> <------------->
> --- (10 headers 0 lines) ---
> Got RTP packet from X.X.X.X:7078 (type 09, seq 000409, ts 098160, len 000240)
> Sent RTP packet to G.G.G.G:26660 (type 08, seq 050330, ts 098072, len 000240)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Got RTP packet from X.X.X.X:7078 (type 09, seq 000410, ts 098560, len 000400)
> Sent RTP packet to G.G.G.G:26660 (type 08, seq 050331, ts 098472, len 000400)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> Got RTP packet from X.X.X.X:7078 (type 09, seq 000411, ts 098800, len 000240)
> Sent RTP packet to G.G.G.G:26660 (type 08, seq 050332, ts 098712, len 000240)
> Sent RTP P2P packet to X.X.X.X:7078 (type 08, len 000160)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list