Open GoogleCodeExporter opened 9 years ago
a=rtpmap is not mandatory for a static payload. So I think the logic here
should be changed.
The following is extracted from RFC4566:
Although an RTP profile may make static assignments of payload
type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload
type 0, so there is no need for an "a=rtpmap:" attribute, and
the media for such a stream sent to UDP port 49232 can be
specified as:
m=audio 49232 RTP/AVP 0
Original comment by zhangjun...@gmail.com
on 10 Jun 2011 at 8:49
It seems you know much more about SIP than me. Would you like me to add you as
a contributor to make the changes. I spent very little time on the project and
I have moved on to the red5-smartphone which uses the SIP library from SUN
instead of mJSIP used by Red5phone
Original comment by olajide....@gmail.com
on 12 Jun 2011 at 2:54
I'm flattered:)
It's good to have the chance to work with you genius guys. While as I have
normal work, so can't commit you the date for the change. Sorry about that.
Also I'm not good at OO language, but I'll send out the code to you for review
before put it in.
Original comment by zhangjun...@gmail.com
on 13 Jun 2011 at 3:06
That will be nice. Thank you for the kind words. It is the Red5 team that are
the genius guys. I am simply standing on their shoulders :-)
Original comment by olajide....@gmail.com
on 14 Jun 2011 at 11:17
To fix the bug, I add some logic in makeMediaPayloadsNegotiation. In order to
fix the problem w/o changing the existing logic in the same time, I used a
awkward way:-
Before do the codec negotiation,
if the codec is in the format list of remote SDP, and there's no "a=rtpmap"
attribute for such codec as it's static payload, and the codec is supported by
red5phone, then I populate the "a=rtpmap" attribute for such codec in remote
SDP manually based on what in the local profile of supported codec list. Please
refer to line #432~#480 of the attached file.
BTW, I found another two issues in SdpUtils.java.
1. In the very beginning of makeMediaPayloadsNegotiation, remote SDP's origin
and session name are used to populate newSdp. I don't understand why use the
info in remote SDP instead of local SDP.
Based on that logic, when red5phone sends a 200 OK INVITE to the sip UA, the IP
in "o="attribute of SDP will be the IP address of the far side. i.e. what's in
SDP of INVITE sent from sip UA.
The same thing applies to session name in SDP.
That looks strange. So in the attached file, I changed the logic to use what in
local.
2. In completeSdpNegotiation, I don't know the reason why add the local
attributes which are not in the negotiation list.
For example, if the far side sends a codec list PCMU, PCMA, GSM. The codec
negotiation result will be PCMU, PCMA. With the logic, the SDP answer sent from
red5 will be:-
m=audio xxxx RTP/AVP 8 0
a=ftpmap:8 ....
a=ftpmap:0 ....
a=ftpmap:18 ....
a=ftpmap:111 ....
I don't think that make sense. So in the attached file, I commented out that
section.
Anyway, with the new logic I changed, I can make a call from flash to sip UA,
and from sip UA to flash. And both scenarios have no problem with voice path.
You can search for "JJZ" for the places I changed.
Any question please let me know.
Original comment by zhangjun...@gmail.com
on 20 Jun 2011 at 2:34
Attachments:
Original issue reported on code.google.com by
dlsergey...@gmail.com
on 21 Dec 2010 at 10:42