[Spce-user] Ptime issues

[qabane me]

Will the snippet Jon gave you now be sufficient?

On Fri, May 31, 2019 at 8:19 PM qabane me <qabaneitsolutions at gmail.com>
wrote:

> Hi Andrew
>
> I will reproduce the scenario and get the logs. There is no peering
> failover involved - the call is routed out through only one possible peer.
>
> ptime is set on domain or subscriber and you are calling out via a peer
> that has “unchanged” ptime right?- yes that is correct
>
> e repeated the test also in this setup and see that requested ptime is
> being send to subscriber, the log shows “Enabling transcoding engine” -
> that is where the difference seems to lie - the requested ptime to the
> subscriber has indeed changed to 20, but we do not get "enabling
> transcoding engine" in the log.
>
> But let me try to get the log and take it from there!
>
> Regards
> Theo
>
> On Fri, May 31, 2019 at 6:26 PM <apogrebennyk at sipwise.com> wrote:
>
>> Hi,
>> can’t reproduce your problem. I checked on-net calls and calls to peer
>> and with all possible combinations of options it does the right thing. In
>> your particular scenario, ptime is set on domain or subscriber and you are
>> calling out via a peer that has “unchanged” ptime right? We repeated the
>> test also in this setup and see that requested ptime is being send to
>> subscriber, the log shows “Enabling transcoding engine”
>>
>> Granted, I tested with latest version and not mr6.5.3, but the changes in
>> rtpengine.cfg are minimal and should be non-relevant between the two
>> versions. Also Richard confirmed that rtpengine does what it is supposed to
>> do when invoked with correct parameters using our test. So kindly asking
>> you to share some more information, such as rtp.log with verbose
>> (ngcp-loglevel rtpengine --set-verbose) and exact test scenario if this is
>> not what I understood. Also, is there any peering failover involved or the
>> call is routed out via the first available peer successfully?
>>
>> Regards,
>> Andrew
>> On 31. May 2019, 14:20 +0300, qabane me , wrote:
>>
>> Hi
>>
>> Ok we did a little more digging with the help of Jon. It looks like this
>> is indeed a bug? When the ptime is set to anything except "leave unchanged"
>> on the peer side, and then we force the ptime to 20 on the subcriber side,
>> it works. The log will show "Enabling transcoding engine".
>>
>> However, when the peer side has "leave unchanged" and the subscriber is
>> forced to 20, the log does not show that. So it looks like in that case it
>> does not invoke the transcoding engine. From what I understand from the
>> manual it should though.
>>
>> I hope that helps?
>>
>> On Thu, May 23, 2019 at 8:18 PM qabane me <qabaneitsolutions at gmail.com>
>> wrote:
>>
>> Hi
>>
>> ok I got it to work with changing the ptime to the subscriber. So while
>> the peer sends ptime 60, sipwise now has ptime 20 in the invite to the
>> subscriber. However, it would appear that even though it states ptime 20,
>> it is in actual fact still ptime 60 as the underlying subscriber, in this
>> case Freeswitch, states that it is receiving it in ptime 60.
>>
>> How do I check this?
>>
>> On Thu, May 23, 2019 at 10:27 AM qabane me <qabaneitsolutions at gmail.com>
>> wrote:
>>
>> Hi
>>
>> I have been playing with repacketisation. I could not get it to work on
>> 6.4 and have now upgraded to 6.5.3 but it's not working on that either. Or
>> I am misunderstanding it of course.
>>
>> If I understand it correctly, if I set a ptime of 20 for a subscriber,
>> sipwise should always send a ptime of 20 to subscriber, regardless of what
>> it receives from the peer. This is the part that is important for us as we
>> have subcribers who cannot handle a ptime of 60 and we have peers who use
>> that ptime.
>>
>> When we set ptime on a peer level, it does appear to do it correctly. So
>> when we as a test force the ptime to a peer to 60 and leave it unchanged on
>> a subscriber level, this is what happens.
>>
>> Subsribers >>>ptime 20>>>>sipwise
>> sipwise >>>ptime 60>>>> peer
>> sipwise<<<<<ptime 60 <<<<peer
>> subscriber<<<<ptime 60<<<sipwise
>>
>> That looks correct as per our configuration in that case.
>>
>> However when we leave the peer ptime unchanged and force the ptime on a
>> subscriber to 20, this is what happens:
>>
>> subscriber >>>> sipwise ptime 20
>> sipwise >>>> peer ptime 20
>> sipwise <<<ptime 60 <<<<peer
>> subscriber<<<<<ptime 60 <<<<sipwise
>>
>> My understanding is that on the leg to the subscriber it should use ptime
>> 20 in this case as we specifically configured the subscriber as such?
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20190531/b3309222/attachment-0001.html>