search

mondain / red5phone

Automatically exported from code.google.com/p/red5phone
1 stars 1 forks source link

Failed to Negotiated Audio Codec #135

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. red5phone can't negotiate audio codec when received next remoteSdp:

SipUserAgent - onCallAccepted -> remoteSdp = v=0
o=tb640 5 1 IN IP4 62.117.120.101
s=-
c=IN IP4 62.117.120.98
t=0 0
m=audio 20520 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=nortpproxy:yes

2. I have next error:
Error handling a new incoming message
java.lang.NullPointerException
        at org.red5.server.webapp.sip.SdpUtils.getNegotiatedAudioCodec(SdpUtils.java:32)
        at org.red5.server.webapp.sip.SIPUserAgent.onCallAccepted(SIPUserAgent.java:645)
        at org.zoolu.sip.call.Call.onDlgInviteSuccessResponse(Call.java:260)
        at org.zoolu.sip.dialog.InviteDialog.onTransSuccessResponse(InviteDialog.java:651)
        at org.zoolu.sip.dialog.ExtendedInviteDialog.onTransSuccessResponse(ExtendedInviteDialog.java:302)
        at org.zoolu.sip.transaction.InviteTransactionClient.onReceivedMessage(InviteTransactionClient.java:130)
        at org.zoolu.sip.provider.SipProvider.processReceivedMessage(SipProvider.java:1090)
        at org.zoolu.sip.provider.SipProvider.onReceivedMessage(SipProvider.java:1248)
        at org.zoolu.sip.provider.UdpTransport.onReceivedPacket(UdpTransport.java:111)
        at org.zoolu.net.UdpProvider.run(UdpProvider.java:174)

Why red5phone search needed codec in "a=rtpmap..." (not in "m=audio 20520 
RTP/AVP 18 101")?

Original issue reported on code.google.com by dlsergey...@gmail.com on 21 Dec 2010 at 10:42

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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: