EiSl 1972 | 14 Sep 18:48 2010
Picon

How to obey the ptime-value in SDP-Answer for RTP-stream?

Hello all,

I've the situation that some SIP-endpoints do require an explicit payload for the stream (this probably due to badly implemented jitter-buffer ...).
My observation is that the ptime value (e.g. "a=ptime:40") seems to be ignored by PJMedia.

Next scenario is valid in my situation:
PJSIP  <---> 'Weird' SIP-endpoint
  <--- INVITE w/h SDP
  ---> TRYING
  ---> RINGING
  ---> 200-OK with SDP (with G711u+a, telephone event, no ptime)
  <--- ACK with SDP (selecting G.711-aLaw and includes a=ptime:40)

Now I see PJSIP receives a RTP-stream with 40ms payload, but PJSIP itself is sending with 20ms payload.

I've already tried some options which I found during a search, but they all failed or had side effects.

Question:
How do I make PJSIP/PJMedia obey the ptime value in the SDP-Answer?

With regards,
Eize

<div><p>Hello all,<br><br>I've the situation that some SIP-endpoints do require an explicit payload for the stream (this probably due to badly implemented jitter-buffer ...).<br>My observation is that the ptime value (e.g. "a=ptime:40") seems to be ignored by PJMedia.<br><br>Next scenario is valid in my situation:<br><span>PJSIP&nbsp; &lt;---&gt; 'Weird' SIP-endpoint</span><br><span>&nbsp; &lt;--- INVITE w/h SDP</span><br><span>&nbsp; ---&gt; TRYING</span><br><span>&nbsp; ---&gt; RINGING</span><br><span>&nbsp; ---&gt; 200-OK with SDP (with G711u+a, telephone event, no ptime)</span><br><span>&nbsp; &lt;--- ACK with SDP (selecting G.711-aLaw and includes a=ptime:40)</span><br><br>Now I see PJSIP receives a RTP-stream with 40ms payload, but PJSIP itself is sending with 20ms payload.<br><br>I've already tried some options which I found during a search, but they all failed or had side effects.<br><br>Question:<br>How do I make PJSIP/PJMedia obey the ptime value in the SDP-Answer?<br><br>With regards,<br>Eize<br><br></p></div>
EiSl 1972 | 15 Sep 11:38 2010
Picon

Re: How to obey the ptime-value in SDP-Answer for RTP-stream?

Hello all,

A short update:
I've introduced a patch which seems to work OK for me. Any "ptime" attribute in the remote SDP is now applied to the stream encoder. To have a good 30ms payload (and other payloads), the media_cfg.audio_frame_ptime should be set to 10. Using the default of 20 will give an unstable packet time (when using null-audio device)

One comment...
While I was investigating, I got the feeling that the "ptime" is just ignored. It is parsed from the SDP and stored, but it seems never been applied. What IS applied is the more exotical "maxptime".
Is there a reason why "ptime" is ignored? Did I overlooked something?
I've introduced my patch at the same location as where the "maxptime" is applied to the encoder settings.

The patch (applied on 1.5.5 release)

<at> session.c (pjmedia-tree ) pjmedia_stream_info_from_sdp(...) around line 530

    ...

    ...

    /* Get local fmtp for our decoder. */

    parse_fmtp(pool, local_m, si->fmt.pt, &si->param->setting.dec_fmtp);

+

+    /* Get the remote ptime for our encoder. */

+    attr = pjmedia_sdp_attr_find2(rem_m->attr_count, rem_m->attr,

+                          "ptime", NULL);

+    if (attr) {

+      pj_str_t tmp_val = attr->value;

+

+      pj_strltrim(&tmp_val);

+        si->param->setting.frm_per_pkt = (pj_uint8_t)(pj_strtoul(&tmp_val) / si->param->info.frm_ptime);

+

+        if ( si->param->setting.frm_per_pkt == 0 )

+        {

+            si->param->setting.frm_per_pkt = 1;

+        }

+    }

 

    /* Get remote maxptime for our encoder. */

    attr = pjmedia_sdp_attr_find2(rem_m->attr_count, rem_m->attr,

                          "maxptime", NULL);

    ...

    ...


With regards,
Eize

<div>
<p>Hello all,<br><br>A short update: <br>I've introduced a patch which seems to work OK for me. Any "ptime" attribute in the remote SDP is now applied to the stream encoder. To have a good 30ms payload (and other payloads), the media_cfg.audio_frame_ptime should be set to 10. Using the default of 20 will give an unstable packet time (when using null-audio device)<br><br>One comment...<br>While I was investigating, I got the feeling that the "ptime" is just ignored. It is parsed from the SDP and stored, but it seems never been applied. What IS applied is the more exotical "maxptime".<br>
Is there a reason why "ptime" is ignored? Did I overlooked something?<br>I've introduced my patch at the same location as where the "maxptime" is applied to the encoder settings.<br><br>The patch (applied on 1.5.5 release)<br><br> <at> session.c (pjmedia-tree ) pjmedia_stream_info_from_sdp(...) around line 530<br></p>
<p class="MsoNormal"><span lang="NL">&nbsp;</span><span>&nbsp;&nbsp; <span>...</span></span></p>
<p class="MsoNormal"><span><span>&nbsp;&nbsp;&nbsp; ...<br></span></span></p>
<p class="MsoNormal"><span><span>&nbsp;&nbsp;&nbsp; /* Get local fmtp for our decoder. </span></span><span lang="NL">*/</span></p>

<p class="MsoNormal"><span lang="NL">&nbsp;&nbsp;&nbsp;
parse_fmtp(pool, local_m, si-&gt;<a href="http://fmt.pt">fmt.pt</a>,
&amp;si-&gt;param-&gt;setting.dec_fmtp);</span></p>

<p class="MsoNormal"><span lang="NL">+ <br></span></p>

<p class="MsoNormal"><span>+&nbsp; &nbsp; <span>/* Get the remote ptime for our
encoder. </span></span><span lang="NL">*/</span></p>

<p class="MsoNormal"><span lang="NL">+ &nbsp;&nbsp; </span><span>attr =
pjmedia_sdp_attr_find2(rem_m-&gt;attr_count, rem_m-&gt;attr,</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; <span>"ptime"</span>, NULL);</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;
<span>if</span> (attr) {</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pj_str_t tmp_val = attr-&gt;value;</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span> <br></span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pj_strltrim(&amp;tmp_val);</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
si-&gt;param-&gt;setting.frm_per_pkt = (pj_uint8_t)(pj_strtoul(&amp;tmp_val) /
si-&gt;param-&gt;info.frm_ptime);</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span> <br></span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="IT">if</span><span lang="IT"> (
si-&gt;param-&gt;setting.frm_per_pkt == 0 )</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span lang="IT">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span lang="IT">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
si-&gt;param-&gt;setting.frm_per_pkt = 1;</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span lang="IT">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span>}</span></p>

<p class="MsoNormal"><span lang="NL">+</span><span>&nbsp;&nbsp;&nbsp;
}</span><span></span></p>

<p class="MsoNormal"><span>&nbsp;</span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp; <span>/* Get
remote maxptime for our encoder. */</span></span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp; attr =
pjmedia_sdp_attr_find2(rem_m-&gt;attr_count, rem_m-&gt;attr,</span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; <span>"maxptime"</span>, NULL);</span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp; ...</span></p>
<p class="MsoNormal">
<span>&nbsp;&nbsp;&nbsp; ...<br></span></p>

<br>With regards,<br>Eize<br><br>
</div>
Nanang Izzuddin | 22 Sep 10:50 2010

Re: How to obey the ptime-value in SDP-Answer for RTP-stream?

Hi,

Just created ticket #1133 and checked in the patch to SVN trunk. Thanks!

A bit modification: rounding up the frm_per_pkt when "ptime" value is
not multiple of frm_ptime (speex codec recommends this, RFC 5574
Section 5.6).

Btw, could you describe more regarding "unstable packet time" when
sending 30ms payload length on audio_frame_ptime=20ms, as we used to
use 30ms iLBC payload length on audio_frame_ptime 20ms without
problem.

BR,
nanang

On Wed, Sep 15, 2010 at 4:38 PM, EiSl 1972 <eisl1972 <at> gmail.com> wrote:
> Hello all,
>
> A short update:
> I've introduced a patch which seems to work OK for me. Any "ptime" attribute
> in the remote SDP is now applied to the stream encoder. To have a good 30ms
> payload (and other payloads), the media_cfg.audio_frame_ptime should be set
> to 10. Using the default of 20 will give an unstable packet time (when using
> null-audio device)
>
> One comment...
> While I was investigating, I got the feeling that the "ptime" is just
> ignored. It is parsed from the SDP and stored, but it seems never been
> applied. What IS applied is the more exotical "maxptime".
> Is there a reason why "ptime" is ignored? Did I overlooked something?
> I've introduced my patch at the same location as where the "maxptime" is
> applied to the encoder settings.
>
> The patch (applied on 1.5.5 release)
>
>  <at> session.c (pjmedia-tree ) pjmedia_stream_info_from_sdp(...) around line 530
>
>     ...
>
>     ...
>
>     /* Get local fmtp for our decoder. */
>
>     parse_fmtp(pool, local_m, si->fmt.pt, &si->param->setting.dec_fmtp);
>
> +
>
> +    /* Get the remote ptime for our encoder. */
>
> +    attr = pjmedia_sdp_attr_find2(rem_m->attr_count, rem_m->attr,
>
> +                          "ptime", NULL);
>
> +    if (attr) {
>
> +      pj_str_t tmp_val = attr->value;
>
> +
>
> +      pj_strltrim(&tmp_val);
>
> +        si->param->setting.frm_per_pkt = (pj_uint8_t)(pj_strtoul(&tmp_val)
> / si->param->info.frm_ptime);
>
> +
>
> +        if ( si->param->setting.frm_per_pkt == 0 )
>
> +        {
>
> +            si->param->setting.frm_per_pkt = 1;
>
> +        }
>
> +    }
>
>
>
>     /* Get remote maxptime for our encoder. */
>
>     attr = pjmedia_sdp_attr_find2(rem_m->attr_count, rem_m->attr,
>
>                           "maxptime", NULL);
>
>     ...
>
>     ...
>
> With regards,
> Eize
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip <at> lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>

EiSl 1972 | 23 Sep 11:48 2010
Picon

Re: How to obey the ptime-value in SDP-Answer for RTP-stream?

Hello Nanang,

I did not have the capture files anymore, so I re-tested it for you.

Find attached a ZIP-file with two capture files where the SDP-Answer goes for G.711-30ms.
One capture is made with cfg->media_cfg.audio_frame_ptime = 20 (showing 'inconsistent' timing) and one capture with cfg->media_cfg.audio_frame_ptime = 10.

With regards,
Eize

Attachment (Captures_Ticket_1133.zip): application/zip, 3724 bytes
<div><p>Hello Nanang,<br><br>I did not have the capture files anymore, so I re-tested it for you.<br><br>Find attached a ZIP-file with two capture files where the SDP-Answer goes for G.711-30ms.<br>One capture is made with cfg-&gt;media_cfg.audio_frame_ptime = 20 (showing 'inconsistent' timing) and one capture with cfg-&gt;media_cfg.audio_frame_ptime = 10.<br><br>With regards,<br>Eize<br><br></p></div>
Nanang Izzuddin | 23 Sep 12:59 2010

Re: How to obey the ptime-value in SDP-Answer for RTP-stream?

Hi Eize,

Thanks for the captures, I got your point.

I guess it is understandable, on null-audio device the
audio_frame_ptime represents the clock tick interval. Depending on the
application need, it can be either harmful or not. Was worrying if the
inconsistency was in RTP timestamp.

BR,
nanang

On Thu, Sep 23, 2010 at 4:48 PM, EiSl 1972 <eisl1972 <at> gmail.com> wrote:
> Hello Nanang,
>
> I did not have the capture files anymore, so I re-tested it for you.
>
> Find attached a ZIP-file with two capture files where the SDP-Answer goes
> for G.711-30ms.
> One capture is made with cfg->media_cfg.audio_frame_ptime = 20 (showing
> 'inconsistent' timing) and one capture with cfg->media_cfg.audio_frame_ptime
> = 10.
>
> With regards,
> Eize


Gmane