| Summary: | ASTERISK-25676: chan_sip: Codecs on RTP instance are all offered, not combined | ||
| Reporter: | Peter Sokolov (peterdoo) | Labels: | |
| Date Opened: | 2016-01-09 17:04:49.000-0600 | Date Closed: | 2017-08-28 11:11:42 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling |
| Versions: | 13.7.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Debian 8.2 | Attachments: | ( 0) ast-13-15-1.png ( 1) ast-13-17-0.png ( 2) AST-25676-el.pcap ( 3) AST-25676-el.sip.conf ( 4) issue.pcapng ( 5) Untitled.png |
| Description: | 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@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@test.tst SIP/2.0 Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK7D8CF25D90C364B9 From: <sip:333@test.tst>;tag=A4D1A0E52D14A452 To: <sip:123@test.tst> Call-ID: 241FB38ED47A0E77@192.168.0.30 CSeq: 2573 INVITE Contact: <sip:333@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@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@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@test.tst>;tag=A4D1A0E52D14A452 t: <sip:123@test.tst> i: 241FB38ED47A0E77@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@A.A.A.A:5060> l: 0 <------------> -- Executing [123@users:1] NoOp("SIP/333-000001f3", "") in new stack -- Executing [123@users:2] NoOp("SIP/333-000001f3", "") in new stack -- Executing [123@users:3] Set("SIP/333-000001f3", "CALLERID(name)=333") in new stack -- Executing [123@users:4] Set("SIP/333-000001f3", "CALLERID(number)=333") in new stack -- Executing [123@users:5] Dial("SIP/333-000001f3", "SIP/123@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@test2.tst SIP/2.0 v: SIP/2.0/UDP A.A.A.A:5060;branch=z9hG4bK5b61c9e2 Max-Forwards: 70 f: "333" <sip:333@test2.tst>;tag=as4c31698e t: <sip:123@test2.tst> m: <sip:333@A.A.A.A:5060> i: 669e68ca24c091413a62b0e06a0c2128@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@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@test2.tst>;tag=as4c31698e To: <sip:123@test2.tst> Contact: sip:123@D.D.D.D:5060 Call-ID: 669e68ca24c091413a62b0e06a0c2128@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@test2.tst>;tag=as4c31698e To: <sip:123@test2.tst>;tag=360313ac55ed93a8b99b71 Contact: sip:123@D.D.D.D:5060 Call-ID: 669e68ca24c091413a62b0e06a0c2128@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@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@test.tst>;tag=A4D1A0E52D14A452 t: <sip:123@test.tst>;tag=as521bc73b i: 241FB38ED47A0E77@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@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@test2.tst>;tag=as4c31698e To: <sip:123@test2.tst>;tag=360313ac55ed93a8b99b71 Contact: sip:123@D.D.D.D:5060 Call-ID: 669e68ca24c091413a62b0e06a0c2128@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@D.D.D.D:5060> set_destination: Parsing <sip:123@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@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@test2.tst>;tag=as4c31698e t: <sip:123@test2.tst>;tag=360313ac55ed93a8b99b71 m: <sip:333@A.A.A.A:5060> i: 669e68ca24c091413a62b0e06a0c2128@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@test.tst>;tag=A4D1A0E52D14A452 t: <sip:123@test.tst>;tag=as521bc73b i: 241FB38ED47A0E77@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@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@172.31.1.100:5060 SIP/2.0 Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKF1AA2AEE2EEA0175 From: <sip:333@test.tst>;tag=A4D1A0E52D14A452 To: <sip:123@test.tst>;tag=as521bc73b Call-ID: 241FB38ED47A0E77@192.168.0.30 CSeq: 2573 ACK Contact: <sip:333@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} | ||
| Comments: | By: Asterisk Team (asteriskteam) 2016-01-09 17:04:50.678-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2016-01-11 18:27:17.982-0600 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Peter Sokolov (peterdoo) 2016-01-19 04:43:32.140-0600 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. By: Rusty Newton (rnewton) 2016-01-20 15:16:50.851-0600 This does look like a bug to me. Can you provide a complete call PCAP (wireshark viewable) for us to use in reproduction? By: Peter Sokolov (peterdoo) 2016-01-22 13:02:09.757-0600 I will have to see whether there is a way to make a capture, because Asterisk runs on a vserver with somehow limited network access. I am out for two weeks and can check that on return. However I am sure that you will see chan_sip adding all codecs to the RTP instance simply using a device which offers more than one codec and limiting it in Asterisk to a single codec using allow/disallow in sip.conf. You should see the following debug strings: [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 If a destination trunk/device replies with a codec not in the list of allowed ones for the call originating device, you will see that native_rtp will let it pass through without translating. My sip.conf also contains: directrtpsetup=yes Maybe you need to set it as well to be able to see the same result in your case if you do not see it without that. By: Etienne Lessard (hexanol) 2016-01-29 14:38:57.139-0600 Hello, I have the same problem and I've been able to reproduce it on both Asterisk 13.6.0 and 13.7.0. I've not tried other versions. I'm attaching a pcap (AST-25676-el.pcap) of a complete call. The scenario is the following: Alice (SIP/alice) calls Bob (SIP/bob) Bob answers Alice doesn't hear Bob (but Bob hears Alice) I've done my tests with 2 Aastra (you can see their User-Agent in the pcap). Both were configured to offer G711.A-law and G711.mu-law. I've also attached the sip.conf (AST-25676-el.sip.conf) that I used for the tests. Like Peter Sokolov described, a workaround is to configure the phone (in this case, Alice's phone) to only offer the codec that are allowed for its peer (in this case, alaw). By: Peter Sokolov (peterdoo) 2016-02-09 09:26:47.958-0600 Thank you Etienne. This coresponds to what I see here and described above (with slightly different codecs). In your case Asterisk confirms only ALAW in the OK to Alice (.36) but then passes through unmodified ULAW that is received from Bob (.37) to Alice (.36) instead of transcoding Bob's ULAW to ALAW for Alice. By: Gregory Massel (gmza) 2016-10-10 16:02:52.897-0500 I have been affected by this issue as well. I can confirm that I can replicate it with multiple codec configurations. I've replicated with the calling channel set to support PCMU, PCMA and G.729a (in that order) towards a called channel supporting only G.729a. In order to eliminate G.729a module issues, I've also replicated with the calling channel set to support PCMU, PCMA and G.722 (in that order) towards a called channel supporting only G.722. I can confirm that the issue started with Asterisk 12.x, because I have tested and replicated the problem on 12.0.0, 12.6.1, 12.8.2, 13.11.2 and 14.0.2. I can confirm that the issue does NOT occur with 11.x, because I have specifically repeated the same test with 11.21.2 and 11.23.1. The followsing shows a call trace where Asterisk >12 is actually ignoring its own SIP OK response and below is the associated OK generated by Asterisk: |Time | 169.0.72.149 | | | | 196.216.192.6 | |0.000000000| INVITE SDP (g711U g7 |SIP From: "Greg" <sip:switchpbx11a@vpbx.switchtel.co.za To:<sip:11@vpbx.switchtel.co.za | |(5062) ------------------> (5060) | |0.000078000| 401 Unauthorized |SIP Status | |(5062) <------------------ (5060) | |0.019924000| ACK | |SIP Request | |(5062) ------------------> (5060) | |0.083844000| INVITE SDP (g711U g7 |SIP From: "Greg" <sip:switchpbx11a@vpbx.switchtel.co.za To:<sip:11@vpbx.switchtel.co.za | |(5062) ------------------> (5060) | |0.084198000| 100 Trying| |SIP Status | |(5062) <------------------ (5060) | |0.132572000| 180 Ringing |SIP Status | |(5062) <------------------ (5060) | |5.668764000| 200 OK SDP (g711A te |SIP Status | |(5062) <------------------ (5060) | |5.684659000| RTP (g729) |RTP Num packets:369 Duration:7.360s SSRC:0xDD8C9F91 | |(11790) <------------------ (10936) | |5.816928000| 200 OK SDP (g711A te |SIP Status | |(5062) <------------------ (5060) | |5.904196000| ACK | |SIP Request | |(5062) ------------------> (5060) | |5.982350000| ACK | |SIP Request | |(5062) ------------------> (5060) | |6.122363000| RTP (g711A) |RTP Num packets:349 Duration:6.960s SSRC:0x20C65E9A | |(11790) ------------------> (10936) | |13.056066000| BYE | |SIP Request | |(5062) ------------------> (5060) | |13.056484000| 200 OK | |SIP Status | |(5062) <------------------ (5060) | SIP/2.0 200 OK Via: SIP/2.0/UDP 169.0.72.149:5062;branch=z9hG4bK132250816;received=169.0.72.149;rport=5062 From: "Greg" <sip:switchpbx11a@vpbx.switchtel.co.za>;tag=2814374047 To: <sip:11@vpbx.switchtel.co.za>;tag=as6c22a394 Call-ID: 1971716883@192.168.1.253 CSeq: 2 INVITE Server: SwitchTelecom Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:11@196.216.192.6:5060> Content-Type: application/sdp Content-Length: 240 v=0 o=root 612571856 612571856 IN IP4 196.216.192.6 s=Asterisk PBX 13.11.2 c=IN IP4 196.216.192.6 t=0 0 m=audio 10936 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=maxptime:150 a=sendrecv Note how, despite it only advertising a single codec - PCMA - it still transmits G.729a. By: Gregory Massel (gmza) 2016-10-10 16:05:24.949-0500 graphical call trace attached By: Gregory Massel (gmza) 2016-10-10 16:08:27.412-0500 Packet capture of the call including SIP and RTP streams and matching the provided call trace image. By: Peter Sokolov (peterdoo) 2016-10-10 17:16:23.019-0500 The issue was not visible in pre 12.x versions because those versions normally used only a subset of codecs from inbound leg for the outbound call leg. So there was no case where the called device would use codecs not negotiated with the caller. The 12.x versions use all configured codecs on the outbound leg which may include codecs not configured for the caller. In these cases Asterisk should transcode, which it does not do because the SIP/PJSIP channels inform RTP instance that all offered codecs are available and not only the combination of offered and configured ones. As people are moving towards >=12.x versions this problem will be more and more visible. By: Peter Sokolov (peterdoo) 2017-02-08 04:19:30.733-0600 I have upgraded the asterisk to version 14.2.1 using PJSIP channel. For bridging the asterisk now uses native_rtp as before, however it correctly transcodes the formats which have not been negotiated in the SDP. This means that the above mentioned problem that was there in asterisk 13.7.0 using chan_sip as well as using chan_PJSIP, is not present anymore on asterisk version 14.2.1 using PJSIP channel. By: Gregory Massel (gmza) 2017-02-08 11:54:35.713-0600 I would hazard a guess and say that this was probably solved in PJSIP as a result of the resolution to ASTERISK-26423 (which was committed to Asterisk 14.2.0). The patch committed to resolve ASTERISK-26423, however, only addresses chan_pjsip, not chan_sip. By: Gregory Massel (gmza) 2017-08-26 12:01:29.467-0500 This issue was resolved when ASTERISK-26143 was resolved. I can confirm that I've re-tested with Asterisk 13.15.1 (problematic) and Asterisk 13.17.0 (corrected) using the exact same configuration files. I have attached graphical traces of both tests. From my perspective, I'm happy for this to be closed. By: Richard Mudgett (rmudgett) 2017-08-28 11:11:42.906-0500 Closing per reporter and another user's comments. | ||
