[asterisk-bugs] [JIRA] (ASTERISK-28864) RTP Timestamp not increasing after several transfers and codec changes

[nappsoft (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250603#comment-250603 ] 

nappsoft commented on ASTERISK-28864:
-------------------------------------

first channel:

           Name: PJSIP/Hansli-00000006
           Type: PJSIP
       UniqueID: LumiMagic-1588263466.62
       LinkedID: LumiMagic-1588263453.30
      Caller ID: ***********
 Caller ID Name: (N/A)
Connected Line ID: anonymous
Connected Line ID Name: Anonymous
Eff. Connected Line ID: anonymous
Eff. Connected Line ID Name: Anonymous
    DNID Digits: (N/A)
       Language: de
          State: Up (6)
  NativeFormats: (alaw)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin at 8000)->(alaw at 8000)
  ReadTranscode: Yes (alaw at 8000)->(slin at 8000)
 Time to Hangup: 0
   Elapsed Time: 0h0m26s
      Bridge ID: 13ef0866-941f-4a2b-b5f1-c583473574d1
 --   PBX   --
        Context: default
      Extension: 
       Priority: 1
     Call Group: 0
   Pickup Group: 0
    Application: AppDial
           Data: (Outgoing Line)
 Call Identifer: [C-00000003]
      Variables:


 -- Streams --
Name: audio
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (alaw)
    Metadata:

second channel:

 -- General --
           Name: PJSIP/A1020srvID3-00000003
           Type: PJSIP
       UniqueID: LumiMagic-1588263453.30
       LinkedID: LumiMagic-1588263453.30
      Caller ID: anonymous
 Caller ID Name: Anonymous
Connected Line ID: **************
Connected Line ID Name: (N/A)
Eff. Connected Line ID: ************
Eff. Connected Line ID Name: (N/A)
    DNID Digits: 0445405046
       Language: de
          State: Up (6)
  NativeFormats: (alaw)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin at 8000)->(alaw at 8000)
  ReadTranscode: Yes (alaw at 8000)->(slin at 8000)
 Time to Hangup: 0
   Elapsed Time: 0h1m19s
      Bridge ID: 280b9a27-2de0-4eb2-bd62-88431d0519c0
 --   PBX   --
        Context: default
      Extension: 0445405046
       Priority: 33
     Call Group: 0
   Pickup Group: 0
    Application: Queue
           Data: group16,irtwx,,,30,
 Call Identifer: [C-00000003]
      Variables:

 -- Streams --
Name: audio
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (alaw)
    Metadata:

These two chanels are bridged over two local channels where we have the translation path:

  NativeFormats: (opusnb)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin at 8000)->(opusnb at 8000)
  ReadTranscode: Yes (opusnb at 8000)->(slin at 8000)

 -- Streams --
Name: audio
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (opusnb)
    Metadata:


=> so it seems to have to do with the fact that after the transfer the local channel still uses the opusnb and alaw<->opusnb<->alaw makes something strange with the timestamps. (The funny thing is: apart from that everything, includung music on hold all transcoding paths etc. is working without any issue)

Output for f->samples and ast_format_get_sample_rate(f->subclass.format) is repeatedly the following as soon as the alaw<->alaw channels are bridged:

[Apr 30 18:20:16] DEBUG[28084][C-00000003]: translate.c:615 ast_translate: 960 8000
[Apr 30 18:20:16] DEBUG[27932][C-00000003]: translate.c:615 ast_translate: 160 8000
[Apr 30 18:20:16] DEBUG[27932][C-00000003]: translate.c:615 ast_translate: 160 8000
[Apr 30 18:20:16] DEBUG[28084][C-00000003]: translate.c:615 ast_translate: 160 8000


> RTP Timestamp not increasing after several transfers and codec changes
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-28864
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28864
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.9.0
>            Reporter: nappsoft
>            Assignee: Unassigned
>              Labels: patch
>         Attachments: ast_translate.patch
>
>
> After facing the following issue in production I was able to reproduce it in the lab:
> Our real world procedure:
> - Incoming call (G711a) going to a queue
> - pickup the channel (so not answering an INVITE, but doing a PickupChan) with a different codec (Opus in our case, didn't test with others)
> - placing the call into a queue again with an attended ast-transfer
> - the call is answered (G711a) by an agent (not with a pickup this time), using a PJSIP based softphone
> - the transfer is executed. Now both channels use G711a
> So now audio will no longer need to be transcoded. (The problem does not seem to happen when we use G711a for all clients all the time).
> What now happens is that we could observe one-way-audio or no audio at all. However this was not caused by a network issue but by wrong rtp timestamps: rtp timestamps in the outgoing stream suddenly were not increased anymore.
> I've added some logging and could observe the following behavior: the delivery time used in calc_txstamp was going back in time in res_rtp_asterisk.c. (80000ms each time).
> It seems like the problems were caused by the fact that the timestamps on rx side were lower than before after the transfer. I was able to get rid of the issue by patching translate.c
> Please note that the issue could also be influenced by the fact that we use a slightly patched version of the opus codec. However the fact that asterisk seems to struggle when f->delivery is (for whatever reason) lower than path->nextin is a problem worth looking at I guess.



--
This message was sent by Atlassian JIRA
(v6.2#6252)