[Home]

Summary:ASTERISK-07884: SPA942 g726 call problems
Reporter:alric (alric)Labels:
Date Opened:2006-10-05 17:09:55Date Closed:2006-10-13 15:56:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) g726_call_problem.txt
( 1) g726_call_problems_full_debug.txt
Description:I have a Cisco 7960 set to use ulaw only, and a SPA-942 set to use g726-32 only, and in asterisk allowed the codecs g726 and g726aal2.  If I call from the SPA942 to the 7960, the call completes and works just fine.  If I call from the 7960 to the SPA942, the SPA replies back with a 488 "Not acceptable here".  Attached is the sip debug from this call.  The first part of the attachment is the successful call, the last part is the failure.  Showed this to jsmith and he said it looked like there was an SDP problem somewhere.  
Comments:By: Leif Madsen (lmadsen) 2006-10-05 17:27:37

Can you attach this as a .txt file and not .rtf?
By: Serge Vecher (serge-v) 2006-10-06 09:01:27

check the second line in this SDP ... I think that's where the problem is...

v=0
=root 28500 28500 IN IP4 10.10.15.192
s=session
c=IN IP4 10.10.15.192
t=0 0
m=audio 15052 RTP/AVP 111 112 101
a=rtpmap:111 G726-32/8000
a=ptime:20
a=rtpmap:112 AAL2-G726-32/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=sendrecv
By: Serge Vecher (serge-v) 2006-10-06 09:03:40

we need to see the debug output also, which is missing:

Can you please enable the 'debug' option for console in logger.conf and rerun the trace again?
By: alric (alric) 2006-10-06 17:05:08

That should be it.
By: alric (alric) 2006-10-06 17:06:02

Oh, and some other information I didn't think about before.  101 is the extension/username of the 7960, 300 is the extension/username of the SPA-942.
By: gowen72 (gowen72) 2006-10-06 20:00:26

The second trace shows that the "owner" portion of the SDP is fine:

v=0
o=root 28500 28500 IN IP4 10.10.15.192
s=session
c=IN IP4 10.10.15.192
t=0 0
m=audio 14254 RTP/AVP 111 112 101
a=rtpmap:111 G726-32/8000
a=ptime:20
a=rtpmap:112 AAL2-G726-32/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=sendrecv


However this SDP is not valid according to RFC2327 (SDP: Session Description Protocol).  The RFC describes "ptime" is a media-level description and as such applies to whole media stream (ie the m= line) and as such you must only have one ptime attribute per m= line.

This could be causing the phone to reject the call - it certainly is causing Aastra phones to reject calls from Asterisk 1.4 !


For further information on per-codec packetization, you should look at "Codec specific parameters in SDP" (draft-xu-mmusic-sdp-codec-param-01).
By: Serge Vecher (serge-v) 2006-10-09 10:48:55

alric: the changes that gowen72 refers to were made by the packetization patch (ASTERISK-5026). If you are able to downgrade a trunk revision prior to 43243 and check out if the problem disappears -- that would be great.
By: Serge Vecher (serge-v) 2006-10-12 14:29:31

actually, the one ptime attribute per media session problem was just addressed addressed by kpfleming in r44971 of 1.4 branch (http://lists.digium.com/pipermail/svn-commits/2006-October/017694.html). Please test and report back if that resolves the issue!
By: gowen72 (gowen72) 2006-10-12 15:11:04

This fix works resolves the problem with Aastra phones, but I can't comment on the original issue.
By: alric (alric) 2006-10-13 15:45:59

Checked out latest 1.4-branch and the problem is gone.  Thanks guys.
By: Serge Vecher (serge-v) 2006-10-13 15:56:48

thanks for reporting back!