[sip-comm-dev] Exception creating media description when all video codecs disabled


#1

Hi

During the integration of MIKEY I stumbled across a NullPointerException
when being called and all video-codecs are disabled in the options.

I attached an excerpt from a session of a call from Oscar to Alice
(nightly 3076). Alice has all codecs disabled. The attached patch solved
it for me, but I'm unsure if it's right place to fix it.

Regards,
Ingo

no-videocodec-null.patch (1.09 KB)

exception.log (3.95 KB)


#2

Ingo, thank you for the report! Could you please try r7939 which seems
to solve the problem in my tests?

···

On Mon, Nov 15, 2010 at 10:41 AM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

During the integration of MIKEY I stumbled across a NullPointerException
when being called and all video-codecs are disabled in the options.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi

During the integration of MIKEY I stumbled across a NullPointerException
when being called and all video-codecs are disabled in the options.

Ingo, thank you for the report! Could you please try r7939 which seems
to solve the problem in my tests?

Sadly, I still see an exception. This time it's inside CallPeerMediaHandler.getExtensionsForType(MediaType) when called from List<RTPExtension> supportedExtensions = getExtensionsForType(mediaType); inside CallPeerMediaHandlerSipImpl.createMediaDescriptionsForAnswer

Adding a null-check after getDefaultDevice in getExtensionsForType and returning an empty list fixed it for me:
    protected List<RTPExtension> getExtensionsForType(MediaType type)
    {
        MediaDevice dev = getDefaultDevice(type);
        if(dev == null)
          return new ArrayList<RTPExtension>(0);

        return dev.getSupportedExtensions();
    }

Sorry that I don't supply a patch-file, my current local source has some other MIKEY related changes which would interfere with all the offsets. In the first report I was unsure whether to fix it where I supplied the patch or to do the null-checks inside createMediaDescriptionsForAnswer. Returning a default-device was the quick-and-dirty attempt so that I could continue on my work.

Thanks!
Ingo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

I guess I'm not testing it right because I don't get an exception.
Anyway, I committed r7947 because I expected it to fix the exception
you'd reported and the change seemed logical.

···

On Mon, Nov 22, 2010 at 1:50 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Sadly, I still see an exception. This time it's inside CallPeerMediaHandler.getExtensionsForType(MediaType) when called from List<RTPExtension> supportedExtensions = getExtensionsForType(mediaType); inside CallPeerMediaHandlerSipImpl.createMediaDescriptionsForAnswer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

I guess I'm not testing it right because I don't get an exception.
Anyway, I committed r7947 because I expected it to fix the exception
you'd reported and the change seemed logical.

Yet another option to intervene :slight_smile:
I can confirm that the current state doesn't cause an exception anymore.

Thanks,
Ingo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net