Summary: | ASTERISK-04446: a=silenceSupp:off - - - - | ||
Reporter: | Alberto Fernandez (derkommissar) | Labels: | |
Date Opened: | 2005-06-20 18:31:17 | Date Closed: | 2011-06-07 14:10:30 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | For some equipment if this is included the call would not complete and return a 500 Internal server error (IE: Huaweii SoftX3000). I was able to modify chan_sip.c and take it off with a comment, but this affected chan_sip globally and made it incompatible with other equipment (IE: Cisco AS5350). I would like to see this parametisable in sip.conf or somewhere of that sort. ****** ADDITIONAL INFORMATION ****** with a=silenceSupp:off - - - - INVITE sip:59322580877@XXX.XXX.XXX.XXX SIP/2.0 Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX> Contact: <sip:2100014@XXX.XXX.XXX.XXX> Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX CSeq: 102 INVITE User-Agent: Asterisk PBX Date: Mon, 20 Jun 2005 17:03:20 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Content-Type: application/sdp Content-Length: 216 v=0 o=root 1474 1474 IN IP4 XXX.XXX.XXX.XXX s=session c=IN IP4 XXX.XXX.XXX.XXX t=0 0 m=audio 12774 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - --- -- Called 59322580877@XXX.XXX.XXX.XXX Wholesale*CLI> <-- SIP read from XXX.XXX.XXX.XXX:5060: SIP/2.0 100 Trying From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX> CSeq: 102 INVITE Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 Content-Length: 0 --- (7 headers 0 lines)--- <-- SIP read from XXX.XXX.XXX.XXX:5060: SIP/2.0 500 Server Internal Error From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX>;tag=e702ffa8 CSeq: 102 INVITE Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 Content-Length: 0 --- (7 headers 0 lines)--- -- Got SIP response 500 "Server Internal Error" back from XXX.XXX.XXX.XXX Transmitting (no NAT) to XXX.XXX.XXX.XXX:5060: ACK sip:59322580877@XXX.XXX.XXX.XXX SIP/2.0 Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX>;tag=e702ffa8 Contact: <sip:2100014@XXX.XXX.XXX.XXX> Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX CSeq: 102 ACK User-Agent: Asterisk PBX Content-Length: 0 ==-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- without a=silenceSupp:off - - - - INVITE sip:59322580877@XXX.XXX.XXX.XXX SIP/2.0 Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX> Contact: <sip:2100014@XXX.XXX.XXX.XXX> Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX CSeq: 102 INVITE User-Agent: Asterisk PBX Date: Mon, 20 Jun 2005 17:03:20 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Content-Type: application/sdp Content-Length: 216 v=0 o=root 1474 1474 IN IP4 XXX.XXX.XXX.XXX s=session c=IN IP4 XXX.XXX.XXX.XXX t=0 0 m=audio 12774 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 --- -- Called 59322580877@XXX.XXX.XXX.XXX Wholesale*CLI> <-- SIP read from XXX.XXX.XXX.XXX:5060: SIP/2.0 100 Trying From: "2100014" <sip:2100014@XXX.XXX.XXX.XXX>;tag=as3cadd8a0 To: <sip:59322580877@XXX.XXX.XXX.XXX> CSeq: 102 INVITE Call-ID: 3768e14e6bff4c37737911de33f51e3a@XXX.XXX.XXX.XXX Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK4a670000 Content-Length: 0 | ||
Comments: | By: Kevin P. Fleming (kpfleming) 2005-06-20 19:08:17 Asterisk's behavior is fully compliant with RFC 3108, which specifies the silenceSupp attribute and the '-' parameter values. If the other device cannot accept this SDP attribute, it is non-conformant with the RFC. |