thr3ads.net - asterisk users - [asterisk-users] Asterisk 11- Answer with [m=image 0 udptl t38] and Call Drop [Jan 2013]

If this information is useful, please help other people find it:
Share via:

Salman Zafar

2013-Jan-16 13:28 UTC

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

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*

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.

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.


*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


-- 
Regards

*Muhammad Salman Zafar*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130116/d9599336/attachment.htm>

Matthew Jordan

2013-Jan-16 14:01 UTC

head link

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

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

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

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

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