Local direction incorrectly changed to inactive if remote answers with inactive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all!

We recently ran into a SDP negotiation bug when doing some tests with eyeBeam:

- Users A and B are having a call
- A puts the call on hold by setting the direction to sendonly, B replies with recvonly
- B also puts the call on hold, by setting the direction to inactive, A replies with inactive
- A decides to take the call out of hold and sets the direction to recvonly, B replies with inactive

At this point, the on_media_update callback is called and if the local SDP is extracted from the negotiatior it contains inactive as the direction, which is not what A sent. By checking the source, that change is coming from here: http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/sdp_neg.c#L523

While that is correct for processing an offer, it's not if an answer is being processed. As per RFC3264, sec 6.1:

"If a media stream is
   listed as recvonly in the offer, the answer MUST be marked as
   sendonly or inactive in the answer."

So looks to me that PJSIP is not doing the right thing here, since it's modifying a local SDP which was already processed and accepted, and it was also correct. The fact that the remote endpoint replied with inactive in the direction shouldn't force the local direction to be inactive, because it's an answer, not an offer.

What scenarios is this (http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/sdp_neg.c#L648) supposed to fix? Since it handles the received answer, it shouldn't set the local direction to inactive, IMHO.

I tested removing that call to update_media_direction and the issue I was seeing is now gone. I could send a patch just removing the call to that function, but I'm not 100% sure if I'm missing anything. Thoughts?


Thanks and regards,

--
Sa?l Ibarra Corretg?
AG Projects






[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux