-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add siprec extension #4132
base: master
Are you sure you want to change the base?
Add siprec extension #4132
Conversation
I couldn't debug the Bitrise error and figure out where the issue in my code is. Please guide me to resolve the problem. |
Thank you for the submission. The support seems to be pretty basic, i.e. it allows incoming request with siprec to be accepted (instead of declined). There are a few concerns though:
|
I have added more checks based on RFC 7866 , but my code lacks appropriate comments, which I will add in the next commit. |
I added the comment. |
Just to give you a heads up, we are preparing for 2.15 release within a few weeks time, so we won't be able to merge this until then. |
pjsip/src/pjsua-lib/pjsua_call.c
Outdated
* set the number of call active streams to the number of media in the SDP offer. | ||
*/ | ||
if(options & PJSIP_INV_REQUIRE_SIPREC){ | ||
call->opt.aud_cnt = offer->media_count; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I mentioned about the patch assuming audio only. For example, if you check the example in the RFC 7866: https://www.rfc-editor.org/rfc/rfc7866.html#section-7.1.1, there are two videos and two audios in the incoming offer, so this code is obviously incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fix the issue within the next few days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved the issue
Resolved the audio count issue and added video support. Successfully tested with a video call using MicroSIP. |
In the SIPREC protocol, it is now possible to send information in the body in XML format with the Content-Type: application/rs-metadata+xml. This feature has been added. |
Just out of curiosity: Why didn't you implement this on top of PJSUA? Or do you not use PJSUA but rather pjsip? I'm asking because I implemented an SRC on top of PJSUA and a little SRS test tool as well. This also cleanly separates the different tasks and concerns of each module |
I initially tried to do the same thing, but it didn’t work. I was using OpenSIPS for the SRC, and in the INVITE message that OpenSIPS sent, there was a "Require: siprec" header, which caused a "bad extension" error since PJSIP didn’t support SIPREC. I didn’t want to make any changes in OpenSIPS. |
I see; didn't adding "siprec" with pjsip_endpt_add_capability() work for you? |
I had a Session Record Client (SRC) that utilized the SIPREC module from the OpenSIPS SIP server, and I intended to develop a Session Record Server (SRS) capable of supporting SIPREC. The goal was for the SRS to handle requests effectively. However, since PJSIP does not support the SIPREC extension, I added SIPREC extension support to PJSIP.
Senario with siprec extension:
INVITE Request
420 Bad Extension Response
Senario with siprec extension:
In the SIPREC module of PJSIP, when an INVITE is received with the header
Require: siprec
and two media attribute labels in the offer SDP, it can generate an appropriate200 OK
response that includes those two media attribute labels in the SDP answer.INVITE Request
200 OK Response