Opened 14 years ago

Closed 13 years ago

#1236 closed defect (wontfix)

Video payload type issues (mostly for H.264)

Reported by: nanang Owned by: nanang
Priority: normal Milestone: Known-Issues-and-Ideas
Component: pjmedia Version: 2.0-dev-branch
Keywords: sipit28 Cc:
Backport to 1.x milestone: Backported:

Description (last modified by bennylp)

Known cases:

  1. offering multiple H.264, with PT=xx and yy, answered with single H.264 with PT=zz, our H.264 SDP negotiator deduce that "zz" match to "xx", but incoming RTP packets use "yy" instead! Note that this also happened before r3526 (permissive H.264 negotiation).
  2. receiving offer with PT=xx, answering with PT=yy, then peer refuse our RTP packets with PT=xx, peer expects our RTP packets using PT=yy instead! (fixed by #1300)

Change History (6)

comment:1 Changed 14 years ago by nanang

  • Keywords sipit28 added

comment:2 Changed 13 years ago by bennylp

  • Milestone changed from release-2.0-alpha to release-2.0-beta
  • Summary changed from Video payload type issues to Video payload type issues (mostly for H.264)

comment:3 Changed 13 years ago by nanang

  • Description modified (diff)

comment:4 Changed 13 years ago by bennylp

  • Description modified (diff)

comment:5 Changed 13 years ago by bennylp

  • Description modified (diff)

Second scenario has been fixed by #1300

comment:6 Changed 13 years ago by bennylp

  • Milestone changed from release-2.0-beta to Known-Issues-and-Ideas
  • Resolution set to wontfix
  • Status changed from new to closed

Wontfix.

For case 1, the fault is mostly in the remote/answerer side as it really should answer SDP with the same PT and must use the exactly same parameters. If app wants to be safe from this problem, it should only offer single H.264 codec.

Case 2 has been solved by #1300 as noted.

Note: See TracTickets for help on using tickets.