| Summary: | ASTERISK-25656: 183 is missing codec mappings with Chan SIP and Asterisk 13 when transcoding required - REINVITE occuring when it shouldn't, also missing codec mappings. | ||||
| Reporter: | Peter Sokolov (peterdoo) | Labels: | |||
| Date Opened: | 2016-01-03 13:45:14.000-0600 | Date Closed: | |||
| Priority: | Major | Regression? | |||
| Status: | Open/New | Components: | Bridges/bridge_native_rtp Channels/chan_sip/General Codecs/General | ||
| Versions: | 13.7.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Debian 8.2 | Attachments: | ( 0) asterisk-25656-failing.pcap ( 1) asterisk-25656-failing-full.txt ( 2) asterisk-25656-failing-msgs.txt ( 3) asterisk-25656-working.pcap ( 4) asterisk-25656-working-full.txt ( 5) asterisk-25656-working-msgs.txt | ||
| Description: | When the only way to establish the communication between two SIP devices is recoding, the 183 reply does not contain any voice codecs, causing the calling device to cancel the call, making it impossible to establish a call between the two devices.
In the following example the originating SIP device (333@test.tst) has only configured allow=g722 in sip.conf. The destination device has configured allow=g722,alaw, but replies with 183 containing alaw only. Asterisk 13.7.0-rc2 sends the 183 to the originating device, indicating no voice codecs at all, although it is capable to translate from alaw to g722. The originating device cancels the call. No "Adding codec" is visible in the SIP log between receiving the 183 and sending 183. {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=z9hG4bKB37C778E1ADC60AE From: <sip:333@test.tst>;tag=8AF3B60254E4CDF1 To: <sip:123@test.tst> Call-ID: 2C3F4CB345A924C9@192.168.0.30 CSeq: 3394 INVITE Contact: <sip:333@X.X.X.X:5060;uniq=C465CA211E8EEE061CD248D47C840> Max-Forwards: 70 Expires: 120 User-Agent: AVM FRITZ!Box 7490 113.06.50 (Dec 4 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: 431 v=0 o=user 16478182 16478182 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 101 97 120 121 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:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:120 PCMA/16000 a=rtpmap:121 PCMU/16000 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 - 2C3F4CB345A924C9@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 101 Found RTP audio format 97 Found RTP audio format 120 Found RTP audio format 121 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 telephone-event for ID 101 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 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:5060;uniq=C465CA211E8EEE061CD248D47C840> <--- 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=z9hG4bKB37C778E1ADC60AE;received=X.X.X.X f: <sip:333@test.tst>;tag=8AF3B60254E4CDF1 t: <sip:123@test.tst> i: 2C3F4CB345A924C9@192.168.0.30 CSeq: 3394 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-000000af", "") in new stack -- Executing [123@users:2] Set("SIP/333-000000af", "CALLERID(number)=00333") in new stack -- Executing [123@users:3] Set("SIP/333-000000af", "CALLERID(name)=333") in new stack -- Executing [123@users:4] Set("SIP/333-000000af", "CALLERID(number)=333") in new stack -- Executing [123@users:5] Dial("SIP/333-000000af", "SIP/123@OutTrunk,60,") in new stack == Using SIP RTP CoS mark 5 Audio is at 17520 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=z9hG4bK57ab5e3d Max-Forwards: 70 f: "333" <sip:333@test2.tst>;tag=as0b8f7499 t: <sip:123@test2.tst> m: <sip:333@A.A.A.A:5060> i: 7d2574bb50b5acc455fb91ff6859d6a9@test2.tst CSeq: 102 INVITE User-Agent: Asterisk Date: Sun, 03 Jan 2016 17:11:35 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE k: replaces, timer c: application/sdp l: 278 v=0 o=root 1839661651 1839661651 IN IP4 X.X.X.X s=Asterisk PBX 13.7.0-rc2 c=IN IP4 X.X.X.X t=0 0 m=audio 7078 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=z9hG4bK57ab5e3d From: "333" <sip:333@test2.tst>;tag=as0b8f7499 To: <sip:123@test2.tst> Contact: sip:123@D.D.D.D:5060 Call-ID: 7d2574bb50b5acc455fb91ff6859d6a9@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=z9hG4bK57ab5e3d From: "333" <sip:333@test2.tst>;tag=as0b8f7499 To: <sip:123@test2.tst>;tag=3a0313ac55f03691abedc0 Contact: sip:123@D.D.D.D:5060 Call-ID: 7d2574bb50b5acc455fb91ff6859d6a9@test2.tst CSeq: 102 INVITE Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE Content-Type: application/sdp Content-Length: 210 v=0 o=CARRIER 1451841145 1451841145 IN IP4 D.D.D.D s=SIP Call c=IN IP4 D.D.D.D t=0 0 m=audio 36114 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:0000038659207726@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 D.D.D.D:36114 -- SIP/OutTrunk-000000b0 is making progress passing it to SIP/333-000000af Audio is at 10768 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=z9hG4bKB37C778E1ADC60AE;received=X.X.X.X f: <sip:333@test.tst>;tag=8AF3B60254E4CDF1 t: <sip:123@test.tst>;tag=as60d85cd4 i: 2C3F4CB345A924C9@192.168.0.30 CSeq: 3394 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: 203 v=0 o=root 2018919976 2018919976 IN IP4 D.D.D.D s=Asterisk PBX 13.7.0-rc2 c=IN IP4 D.D.D.D t=0 0 m=audio 36114 RTP/AVP 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv <------------> <--- SIP read from UDP:X.X.X.X:5060 ---> CANCEL sip:123@test.tst SIP/2.0 Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKB37C778E1ADC60AE From: <sip:333@test.tst>;tag=8AF3B60254E4CDF1 To: <sip:123@test.tst> Call-ID: 2C3F4CB345A924C9@192.168.0.30 CSeq: 3394 CANCEL Reason: SIP; cause=488; text="SDP problem" Max-Forwards: 70 User-Agent: AVM FRITZ!Box 7490 113.06.50 (Dec 4 2015) Supported: 100rel,replaces Allow-Events: telephone-event,refer Content-Length: 0 {code} Modifying the codecs to allow=g722,alaw for the originating device in sip.conf causes Asterisk to indicate both codecs (g722 and alaw) in 183 and it happily translates received alaw early media to g722 and sends it to the originating device. Two "Adding codec" are visible in the SIP log between receiving the 183 and sending 183. So adding a codec which would not need translation, but is not used in that call at all, causes Asterisk to add also the codec that needs translation to SDP in 183. {code} 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 D.D.D.D:11742 -- SIP/OutTrunk-000000b0 is making progress passing it to SIP/333-000000af Audio is at 11122 Adding codec g722 to SDP Adding codec alaw 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=z9hG4bK4BDDDB221D20FE39;received=X.X.X.X f: <sip:333@test.tst>;tag=804A2A9B6FD4EF6D t: <sip:123@test.tst>;tag=as01c742c2 i: 6ED3E4C17715F952@192.168.0.30 CSeq: 3394 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: 203 v=0 o=root 2040737164 2040737164 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 36114 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 {code} | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-01-03 13:45:15.795-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-04 08:46:33.917-0600 By recoding it seems you mean transcoding? To keep things simple - please attach the configuration files (dialplan, sip.conf, etc) and steps necessary to reproduce the issue. Please include any relevant details, such as the model/firmware/software versions of the device endpoints. By: Peter Sokolov (peterdoo) 2016-01-05 11:24:49.609-0600 Yes, I mean transcoding from alaw to g722. Asterisk 13 seems to like to transcode as often as possible even if both SIP endpoints support exactly the same codecs. Previous Asterisk versions passed RTP without transcoding directly peer-to-peer almost always when possible. The problem described here however occurs in the case when transcoding from alaw to g722 is really required. 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 SDP). It seems to be important that both peers are set to directmedia=yes in a way that in the case of both supporting the same codec, RTP flows directly between them. Make a call from peer 333 to a number that is routed through OutTrunk. When OutTrunk sends 183 with only alaw in SDP, you should see that Asterisk sends 183 without voice codecs in SDP to peer 333. My SIP device cancels the call in that case. Maybe some devices will not cancel the call, but the will not get information about the codec for early media, which certainly is not correct. Just extending the config of the peer 333 to allow=g722,alaw will cause the Asterisk to include both codecs (g722 and alaw) in the SDP of 183. It will also translate received alaw early media from the peer OutTrunk to g722 and send it to peer 333. Asterisk versions before 13 in that case did not intend to pass early media through Asterisk and did let alaw early media flow directly from peer OutTrunk to peer 333 without transcoding to g722 (this unnecessary transcoding is however not the problem I am reporting here). {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=yes 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} By: Rusty Newton (rnewton) 2016-01-21 15:54:31.624-0600 Hmm. Using your configs and another Asterisk system for the trunk I can reproduce something very close to this but not exactly. It includes some very strange behavior. It would be really helpful if you could attach a pcap showing the complete scenario. By: Rusty Newton (rnewton) 2016-01-21 18:41:44.739-0600 So, pretty sure this is a bug. Using the same configuration as [~peterdoo] and substituting another Asterisk system for the ITSP - I get similar but different behavior. In my case the 183's go through fine, but Asterisk attempts to RE-INVITE when it should not. On top of that the RE-INVITE contains no codec mappings. So, as expected things die. I'm attaching files prefixed asterisk-25656-* , for the failing scenario and working scenario. If I add alaw to peer 333 as [~peterdoo] described then it seems to work as expected with transcoding taking place. By: Rusty Newton (rnewton) 2016-01-22 08:45:28.035-0600 Found that something very similar happens with res_pjsip. I'm currently trying to pick it apart. I'll create a new issue for the res_pjsip side of things since it fails a little differently. Will link it when I'm done. By: Peter Sokolov (peterdoo) 2016-01-22 12:32:56.644-0600 My sip.conf also contains directrtpsetup=yes Maybe that makes it behave differently in your case. | ||||