View Change

1 comment:

• Patchset:

  • Patch Set #4:

    I have the feeling this patch is going in the wrong direction. or maybe it's that other stuff is missing in osmo-mgw. See a sample of an SDP:

    """
    MDCX 1817 rtpbridge/1@mgw MGCP 1.0
    C: 10a
    I: 1654DE0D
    M: sendrecv

    v=0
    o=- 10a 23 IN IP4 127.0.0.1
    s=-
    c=IN IP4 192.168.33.2
    t=0 0
    m=audio 17076 RTP/AVP 98
    a=fmtp:98 octet-align=1
    a=rtpmap:98 AMR/8000/1
    a=ptime:20
    """

    So IIUC that means: Hey I have a peer available on 192.168.33.2:17076 which wants to talk AMR OA using Payload Type 98.

    The peer could also announce support for AMR BE in a different Payload Type if he wanted:
    """
    a=fmtp:99 octet-align=0
    a=rtpmap:99 AMR/8000/1
    """
    So my understanding is that octet_aligned information should be checked when picking up the proper Payload Type. With your patch, IIUC, you would pick the first one, regardless of the AMR OA/BE support announced by the peer?

    So ideally you should first check if the BE/OA info matches,and if not, pick one even if it doesn't match, and do "transcoding" BE<->OA.

To view, visit change 27223. To unsubscribe, or for help writing mail filters, visit settings.