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
