[asterisk-users] Asterisk 11- Answer with [m=image 0 udptl t38] and Call Drop

Fri Jan 18 05:37:51 CST 2013

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 <msalman212 at 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 <mjordan at 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 at 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
***************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130118/4fad3e17/attachment.htm>