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

Matthew Jordan mjordan at digium.com
Wed Jan 16 08:01:31 CST 2013


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





More information about the asterisk-users mailing list