| Summary: | ASTERISK-24835: Early Media Not working with Chan SIP and Asterisk 13 | ||||
| Reporter: | Andrew Nagy (tm1000) | Labels: | |||
| Date Opened: | 2015-02-26 19:59:01.000-0600 | Date Closed: | 2015-04-10 16:06:36 | ||
| Priority: | Critical | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
| Versions: | 13.1.1 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) dialplan.txt | |||
| Description: | Early media is not working in Asterisk 13 when using Chan_SIP. It works fine when using PJSIP. The reasoning appears to be that Chan_SIP is sending 180 ringing when it's told to "Progress" while PJSIP is sending 183 when it's told to progress.
I have attached inline a snipet of a chan_sip dial and a pjsip dial. You will see the differences there in. Specifically: CHAN_SIP (13): {code} -- Executing [999@from-internal:3] Progress("SIP/1002-00000085", "") in new stack <--- Transmitting (NAT) to XXX.XXX.XXX.XXX:5064 ---> SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.10.10.12:5064;branch=z9hG4bK2113418340;received=XXX.XXX.XXX.XXX;rport=5064 From: <sip:1002@my.server.net:5061>;tag=706301242 To: <sip:999@my.server.net:5061>;tag=as3db28b80 Call-ID: 2099708635-5064-5@BA.BA.BA.BC CSeq: 41 INVITE Server: FPBX-13.0.1alpha1(13.1.1) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: <sip:999@XXX.XXX.XXX.XXXX:5061> Content-Length: 0 <------------> {code} CHAN_PJSIP (13): {code} -- Executing [999@from-internal:3] Progress("PJSIP/1001-000000aa", "") in new stack <--- Transmitting SIP response (827 bytes) to UDP:XXX.XXX.XXX.XXX:5060 ---> SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.10.10.12:5060;rport=5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bK503980922 Call-ID: 70708105-5060-5@BA.BA.BA.BC From: "Andrew Nagy" <sip:1001@my.server.net>;tag=1590118380 To: <sip:999@my.server.net>;tag=AvwkMijOGvO1QXW1qDcNXl8xlBqUW.Ux CSeq: 41 INVITE Server: FPBX-13.0.1alpha1(13.1.1) Contact: <sip:XXX.XXX.XXX.XXXX:5065> Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER, REFER Content-Type: application/sdp Content-Length: 255 v=0 o=- 8004 8002 IN IP4 XXX.XXX.XXX.XXXX s=Asterisk c=IN IP4 XXX.XXX.XXX.XXXX t=0 0 m=audio 14388 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/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} CHAN_SIP(11.16.0) {code} -- Executing [999@from-internal:3] Progress("SIP/1002-00000001", "") in new stack Audio is at 12696 Adding codec 100003 (ulaw) to SDP Adding codec 100004 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP <--- Transmitting (NAT) to XXX.XXX.XXX.XXX:5064 ---> SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.10.10.12:5064;branch=z9hG4bK1753731864;received=XXX.XXX.XXX.XXX;rport=5064 From: <sip:1002@my.server.net:5061>;tag=9700035 To: <sip:999@my.server.net:5061>;tag=as5bd4933a Call-ID: 1953294974-5064-7@BA.BA.BA.BC CSeq: 61 INVITE Server: FPBX-13.0.1alpha1(13.1.1) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: <sip:999@XXX.XXX.XXX.XXXX:5061> Content-Type: application/sdp Require: timer Content-Length: 264 v=0 o=root 424885368 424885368 IN IP4 XXX.XXX.XXX.XXXX s=Asterisk PBX 11.16.0 c=IN IP4 XXX.XXX.XXX.XXXX t=0 0 m=audio 12696 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv <------------> {code} The above logs were generated from the dialplan below {code} [bad-number] include => bad-number-custom exten => _X.,1,ResetCDR() exten => _X.,n,NoCDR() exten => _X.,n,Progress exten => _X.,n,Wait(1) exten => _X.,n,Progress exten => _X.,n,Playback(silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer) exten => _X.,n,Wait(1) exten => _X.,n,Congestion(20) exten => _X.,n,Hangup {code} I have, however, attached a simplified dialplan for testing in the attachments. | ||||
| Comments: | By: Andrew Nagy (tm1000) 2015-02-26 20:24:26.469-0600 I believe I have narrowed down the offending line of code to be Asterisk Branch 13 (channels/chan_sip.c) {code} case AST_CONTROL_PROGRESS: if ((ast_channel_state(ast) != AST_STATE_UP) && !ast_test_flag(&p->flags[0], SIP_PROGRESS_SENT) && !ast_test_flag(&p->flags[0], SIP_OUTGOING)) { p->invitestate = INV_EARLY_MEDIA; /* SIP_PROG_INBAND_NEVER means sending 180 ringing in place of a 183 */ if (ast_test_flag(&p->flags[0], SIP_PROG_INBAND) != SIP_PROG_INBAND_NEVER) { transmit_provisional_response(p, "183 Session Progress", &p->initreq, TRUE); ast_set_flag(&p->flags[0], SIP_PROGRESS_SENT); } else if (ast_channel_state(ast) == AST_STATE_RING && !ast_test_flag(&p->flags[0], SIP_RINGING)) { transmit_provisional_response(p, "180 Ringing", &p->initreq, 0); ast_set_flag(&p->flags[0], SIP_RINGING); } break; } res = -1; break; {code} Asterisk Branch 11 (channels/chan_sip.c) {code} case AST_CONTROL_PROGRESS: if ((ast_channel_state(ast) != AST_STATE_UP) && !ast_test_flag(&p->flags[0], SIP_PROGRESS_SENT) && !ast_test_flag(&p->flags[0], SIP_OUTGOING)) { p->invitestate = INV_EARLY_MEDIA; transmit_provisional_response(p, "183 Session Progress", &p->initreq, TRUE); ast_set_flag(&p->flags[0], SIP_PROGRESS_SENT); break; } res = -1; break; {code} Which to me looks like I need to set "progressinband" to "yes" instead of the default "never". So I assume this was a change to Chan_SIP at some point. By: Andrew Nagy (tm1000) 2015-02-26 20:27:40.947-0600 And then I found the actual Review Board request that started all of this (https://reviewboard.asterisk.org/r/3700/diff/) ASTERISK-23972. So my question here now is, why with "defaults" does chan_sip send a 180 but pjsip sends a 183. I think they should either both send a 180 or both send a 183 when everything is defaulted to it's minimalistic state because right now you have different working characteristics between the two drivers. (one needs an option set to use early media in the dialplan, the other does not). Consistency is key! By: Kevin Harwell (kharwell) 2015-04-08 12:42:36.596-0500 Since changing the "progressinband" works I believe that should be sufficient in resolving the main issue originally reported. In order to provide consistency I've posted a question to the asterisk dev mailing list ["progressinband in chan_sip default value"|http://lists.digium.com/pipermail/asterisk-dev/2015-April/074375.html] inquiring on what people's opinion is on changing the default value for chan_sip. It is not possible, however, to provide that same consistency in res_pjsip (it does not have a "never" value). Instead a completely new option will eventually be added to res_pjsip that would add similar functionality to the "never" value found in chan_sip. By: Kevin Harwell (kharwell) 2015-04-10 16:04:35.830-0500 Ended up changing the default for "progressinband" in chan_sip to "no". This should now make the default behavior act similar to before. By: Andrew Nagy (tm1000) 2015-04-14 18:09:01.027-0500 Thanks Kevin! That will work for me. | ||||