[Home]

Summary:ASTERISK-08013: SIP paketization
Reporter:Arthur (reest)Labels:
Date Opened:2006-10-26 02:12:01Date Closed:2006-11-03 17:29:33.000-0600
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:for correct SIP paketization for remote size ,  send time paket

chan_sip.c:5770

>        if (fmt.cur_ms && (fmt.cur_ms < *min_packet_size))
>               *min_packet_size = fmt.cur_ms;

+        ast_build_string(a_buf, a_size, "a=ptime:%d\r\n", fmt.cur_ms);
>


****** ADDITIONAL INFORMATION ******

Remote size don`t correct accept  codec paketization. We need send " a=ptime: 80 "  for remote size.
Comments:By: Serge Vecher (serge-v) 2006-10-26 10:49:14

As per bug guidelines, you need to attach a SIP debug trace illustrating the problem. Please do the following:
1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.
 i.e. asterisk -Tvvvvvdddddgc | tee /tmp/sipdebug.txt
By: Olle Johansson (oej) 2006-10-26 10:54:18

...or please explain with a bit more lines, cause I have a problem understanding what you mean with your proposed change. Thank you!
By: Joseph Yannaccone (jyannaccone) 2006-10-26 19:57:27

I believe what the requestor is asking for is that chan_sip include an a=ptime:[payload_size] attribute in the session description to inform a peer of the RTP payload size (measured in samples) that it intends to use.

It is briefly mentioned on page 25 of RFC 4566 - SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt).

The absence of this attribute causes problems with some SIP clients when Asterisk is configured to use an RTP payload size that is not equal to the client's default payload size.

For example:

I have a test setup with Asterisk 1.4.0 beta 3 and two softphones (eyebeam).

Asterisk is configured as follows:

=====

sip.conf

[general]
packetization=60  ; put 60 samples in each RTP packet

[user1]
type=friend
secret=xxxxxx
host=dynamic
nat=yes
disallow=all
allow=g729
canreinvite=no
context=default

[user2]
type=friend
secret=xxxxxx
host=dynamic
nat=yes
disallow=all
allow=g729
canreinvite=no
context=default

=====

extensions.conf

[default]
exten => 101,1,Dial(SIP/user1)
exten => 201,1,Dial(SIP/user2)

=====

When a call is placed between the two users (i.e. the eyebeam softphones), chan_sip puts 60 1ms samples in each RTP packet that is sends to each user.  However, the default payload size for the eyebeam softphone (when using the G.729 codec) is 20 1ms samples.  The softphone codec does not expect to receive 60 samples per RTP packet because there was no attribute in the SDP message to tell it to use anything other than the default.  The result is that audio steam  is degraded (with a repeating clicking sound occurring in the background) throughout the call as the softphone's codec attempts to process an incoming RTP stream that does not conform to its expectation.

This would not occur if chan_sip included the a=ptime:60 attribute in the SDP message to inform the softphone's codec that it will be sending 60 samples per RTP packet.  The value for the a=ptime attribute should be equal to the number of samples set for the peer/user by the packetization parameter in sip.conf.

I hope this is helpful (and not too confusing).
By: dea (dea) 2006-10-26 22:29:33

jyannaccone-
Just before beta1 optional packetization was added to a number of channels,
including sip.  Packetization can be set on a per codec basis:
allow=ulaw:60,g729:80

H323 will maintain the per codec settings, while SIP with support
for only a single ptime element in the SDP has to use only one
value for all codecs, but this not likely to be a major problem,
especially if documented.

OEJ-
The code around 5770 is where SB and I originally had added the
"a=ptime: " element to the SDP.  Which was wrong and added multiple
instances of a=ptime:XX to the SDP.

Kevin moved the insertion of the a=ptime attribute outside of the
loop that inserts available codecs into the SDP, with the new code
being around line 6161.

I suspect, but will need to test it, that the code is fine and
a configuration tweak will help reest.

Reest-
Which codecs are you using reest and can you provide the user/peer
settings for your remote site?


By: Olle Johansson (oej) 2006-10-27 00:53:34

Isn't packetization per codec a different thing that is specified in the RTP avp profile for the codec? When I looked into this, there was many different ways of doing it.

I think we need to investigate and make sure that we do it according to each RTP avp profile.
By: dea (dea) 2006-10-27 01:08:39

That's more than possible, and might be something SB and I missed when
looking through the RFCs to see how to handle this.

I'll also look into it.
By: dea (dea) 2006-10-27 11:05:56

I think I see reest's problem more clearly now, and he is correct that
1.4b3 is not including the a=ptime:  attribute in the SDP.

I'll see if I can get a patch out today to fix it.
By: dea (dea) 2006-10-27 16:26:28

OK, the issue is that there is a check in add_codec_to_sdp to see if the
codec being added has a packetization lower than other codec that have
been added already:

       if (fmt.cur_ms && (fmt.cur_ms < *min_packet_size))
               *min_packet_size = fmt.cur_ms;

There's an issue with this.
1.  We initialize min_audio_packet_size and min_video_packet_size to zero
   so the test never passes, and the decision to add a=ptime: at line 6161
   will always fail.

If we were to initialize min_*_packet_size to sane values, we would still have
a problem.  In a case were we only allow a single codec, and it is not less
than the 'sane' default, the 'sane' default overrides our desired packetization.

I think the best way to handle this is to check to see if min_packet_size is
set to zero in add_codec_to_sdp and if it is, assign the value of the current
codec's packetization setting to it.

So around line 5770 the code might look like this:
       if (fmt.cur_ms && (fmt.cur_ms < *min_packet_size))
               *min_packet_size = fmt.cur_ms;

       /* Our first codec packetization processed cannot be less than zero */
       if (!(*min_packet_size) && fmt.cur_ms)
               *min_packet_size = fmt.cur_ms;

Disclaimer on file
By: dea (dea) 2006-10-31 11:38:51.000-0600

Has anyone with commit access had a chance to look at this?  It is a trivial
think-o, with a simple fix.
By: jmls (jmls) 2006-11-02 14:32:46.000-0600

there, you're back top of the list :)
By: Steve Murphy (murf) 2006-11-03 17:15:30.000-0600

OK, I'll do it!
By: Steve Murphy (murf) 2006-11-03 17:28:24.000-0600

This bug fixed in the 1.4 branch via 47176.
This bug fixed in the trunk via 47178.
By: Steve Murphy (murf) 2006-11-03 17:29:32.000-0600

Done! Let me know if there's any problems!