No luck so far, should I consider it a bug in Asterisk 11 as I have tried different version of Asterisk 11 as well. Carrier sends BYE with service not implemented where as asterisk advertise udptl in SDP for Answer. I do not want it to be advertised by Asterisk 11 in Answer() as I am not using it(udptl, fax etc) in any case.
On Thu, Jan 17, 2013 at 11:15 AM, Salman Zafar <msalman...@gmail.com> wrote: > Thanks Jordan, for having a look at this matter. > > Yes, that is what Asterisk 11 is sending. Here are complete sip debugs > from Asterisk attached. Please refer to IP mapping from OP to have a better > understanding. > > Is there any way of getting it off from SIP parser on compile time as I am > not using this feature and do not intend to use in future. > > > > On Wed, Jan 16, 2013 at 7:01 PM, Matthew Jordan <mjor...@digium.com>wrote: > >> On 01/16/2013 07:28 AM, Salman Zafar wrote: >> > Hello All, >> > I am having a bit peculiar problem with Asterisk 11 for a >> > carrier. This carrier shares quite some information in SDP header, which >> > should not be the problem, however what happen is as follow: >> > >> > >> > Carrier----> (INVITE) -> *SIP Proxy -> Asterisk 11 -> Answer()* -> right >> > after answering call drops... Carrier send a BYE with (cause 79: service >> > or option not implemented). >> > >> > *NOTE: Please refer to complete SIP traces attached. * >> > * >> > * >> > *Also Note:* >> > _Carrier_: 62.61.147.214 >> > _Proxy_: 77.X.X.X:5060 >> > _Asterisk11_: 77.X.X.X:5080 >> > >> > *_Here is Invite SDP from Carrier -> Proxy -> Asterisk 11_* >> > >> > INVITE sip:69609000@77.X.X.X SIP/2.0 >> > v=0 >> > o=AudiocodesGW 1638819008 1638818710 IN IP4 62.61.147.214 >> > s=Phone-Call >> > c=IN IP4 77.X.X.X >> > t=0 0 >> > m=audio 53372 RTP/AVP 8 118 18 >> > a=rtpmap:8 PCMA/8000 >> > a=rtpmap:118 PCMA/8000 >> > a=gpmd:118 vbd=yes >> > a=rtpmap:18 G729/8000 >> > a=fmtp:18 annexb=no >> > a=ptime:20 >> > a=sendrecv >> > a=rtcp:53373 IN IP4 77.X.X.X >> > m=image 56854 udptl t38 >> > a=T38FaxVersion:0 >> > a=T38MaxBitRate:14400 >> > a=T38FaxMaxBuffer:1024 >> > a=T38FaxMaxDatagram:122 >> > a=T38FaxRateManagement:transferredTCF >> > a=T38FaxUdpEC:t38UDPRedundancy >> > >> > /*_SDP:After Answered by Asterisk 11_*/ >> > v=0 >> > o=root 164966782 164966782 IN IP4 77.X.X.X >> > s=Asterisk v11.0.1 >> > c=IN IP4 77.X.X.X >> > t=0 0 >> > m=audio 12636 RTP/AVP 18 8 >> > a=rtpmap:18 G729/8000 >> > a=fmtp:18 annexb=no >> > a=rtpmap:8 PCMA/8000 >> > a=ptime:20 >> > a=sendrecv >> > *_m=image 0 udptl t38_* >> >> >> The appropriate way for Asterisk to indicate that it does not support a >> media stream is to set the port number to 0. We have to inform the >> offerer that we don't support the media stream; removing it from the SDP >> completely is not allowed. >> >> Per RFC 3264, section 6: >> >> " An offered stream MAY be rejected in the answer, for any reason. If >> a stream is rejected, the offerer and answerer MUST NOT generate >> media (or RTCP packets) for that stream. To reject an offered >> stream, the port number in the corresponding stream in the answer >> MUST be set to zero. " >> >> > I have tired by disabling/unloading fax modules as *I am not using* them >> > but no results. Secondly, also tried tweaking of udptl ever-odd nothing >> > worked. >> >> You've configured your system to not support fax correctly. Asterisk is >> rejecting the offered image stream accordingly. >> >> > The same carrier works for Asterisk 1.6.X and the only difference I have >> > notice so far is the above underlined line in Answered SDP -> m=image 0 >> > udptl t38. I think if I some how do not advertise udptl here i would be >> > able to avoid this scenario. I have tried multiple ways to strip off SDP >> > from incoming INVITE at SIP Proxy level but it is not SDP wise enough. >> > >> >> I'm not sure what 1.6.x is sending. It's possible that it just >> completely removed the stream from the SDP answer, which is wrong. >> >> Section 6 again: >> >> "For each "m=" line in the offer, there MUST be a corresponding "m=" >> line in the answer." >> >> > *Note:* >> > >> > In Asterisk 1.6 => WARNING[32671]: chan_sip.c:8833 process_sdp: >> > Unsupported SDP media type in offer: image 59978 udptl t38 >> > In Asterisk 11 => WARNING[18748][C-0000002f]: chan_sip.c:10277 >> > process_sdp: Failed to initialize UDPTL, declining image stream >> > >> > >> >> An initial glance at this makes me think your carrier is doing something >> wrong. Just to check, however, is the SDP answer you pasted the entire >> SDP that Asterisk 11 responds with? Specifically, are there no format >> attributes for the image stream in the SDP that Asterisk responds with? >> >> -- >> Matthew Jordan >> Digium, Inc. | Engineering Manager >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at: http://digium.com & http://asterisk.org >> >> >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > > -- > Regards > > ************************** > Muhammad Salman > *************************** > > -- Regards ************************** Muhammad Salman ***************************
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users