In the short term, there is a higher priority activity, resolving the Fedora RPM packaging. There are some very minor issues I need to fix, I've been in discussions about that.

The CMake change might be a temporary setback for the Fedora RPM packaging, from my perspective, it is better to do the final Fedora fixes, leave that version running in the Fedora world and then spend some time with CMake.

I have more urgent deadlines in January but I plan to look at the Fedora RPM issue in February. I would only be able to look at the CMake change after that.

In principle, I think it is important to consider CMake compared to autotools, especially for Windows support.

On the other hand, I know there are sometimes glitches with CMake builds, the tests sometimes fail on the wrong error, for example, it gives red herrings with errors about pthreads but in fact the real error is unrelated to pthreads. I had experiences like this working with Blender builds. Once everybody knows about these glitches it is OK but people can be distracted or surprised when something like this happens.

Hi,

I found an example on how to approach creation of repro plugins to introduce new functionality, but as I compiled, enabled and loaded new plugin, I saw it being added to the very end of the RequestProcessor chain.

While running some basic SIP tests, I was unable to execute my plugin logic as INVITE never reached it due to the fact that LocationServer monkey was dropping request with 404 Not Found response.

ReproRunner.cxx:1217 | RequestProcessor chain: [StrictRouteFixup, IsTrustedNode, AmIResponsible, StaticRoute, LocationServer]
ExamplePlugin.cpp:30 | ExamplePlugin: onRequestProcessorChainPopulated called

...

ProcessorChain.cxx:95 | Chain invoking RequestProcessor: LocationServer
monkeys/LocationServer.cxx:32 | Monkey handling request: LocationServer; reqcontext = numtrans=1 final=0 req=SipReq:  INVITE [email protected] tid=PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 cseq=4318 INVITE [email protected] / 4318 from(wire)
Helper.cxx:374 | Helper::makeResponse(SipReq:  INVITE [email protected] tid=PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 cseq=4318 INVITE [email protected] / 4318 from(wire) code=404 reason=
RequestContext.cxx:941 | tid of orig req: PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1
RequestContext.cxx:976 | Ensuring orig tid matches tid of response: PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 == PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1
RequestContext.cxx:983 | Sending final response.

From docs I can see that:

LocationServer - Fetches locations from the RegistrationPersistenceManager instance (shared with the registrar) to proxy requests to.

I have disabled both Registrar and PresenceServer:

DisableRegistrar = true
EnablePresenceServer = false

but LocationServer monkey still intercepts requests before they reach my plugin.

• Is there a way to disable LocationServer monkey from config?
• Is there a way that I can add my plugin to the RequestProcessor chain BEFORE some of the system (hardcoded) processors such as LocationServer?

Nevermind, found an answer to my own question in the PyRoute plugin.

Not sure how I missed insertProcessor(...) in the ProcessorChain interface before....

Hi,

I found an example on how to approach creation of repro plugins to introduce new functionality, but as I compiled, enabled and loaded new plugin, I saw it being added to the very end of the RequestProcessor chain.

While running some basic SIP tests, I was unable to execute my plugin logic as INVITE never reached it due to the fact that LocationServer monkey was dropping request with 404 Not Found response.

ReproRunner.cxx:1217 | RequestProcessor chain: [StrictRouteFixup, IsTrustedNode, AmIResponsible, StaticRoute, LocationServer]
ExamplePlugin.cpp:30 | ExamplePlugin: onRequestProcessorChainPopulated called

...

ProcessorChain.cxx:95 | Chain invoking RequestProcessor: LocationServer
monkeys/LocationServer.cxx:32 | Monkey handling request: LocationServer; reqcontext = numtrans=1 final=0 req=SipReq:  INVITE [email protected] tid=PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 cseq=4318 INVITE [email protected] / 4318 from(wire)
Helper.cxx:374 | Helper::makeResponse(SipReq:  INVITE [email protected] tid=PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 cseq=4318 INVITE [email protected] / 4318 from(wire) code=404 reason=
RequestContext.cxx:941 | tid of orig req: PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1
RequestContext.cxx:976 | Ensuring orig tid matches tid of response: PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1 == PjJmPUk.YN4OAXO.a48A8BMau70sLfyfi1
RequestContext.cxx:983 | Sending final response.

From docs I can see that:

LocationServer - Fetches locations from the RegistrationPersistenceManager instance (shared with the registrar) to proxy requests to.

I have disabled both Registrar and PresenceServer:

DisableRegistrar = true
EnablePresenceServer = false

but LocationServer monkey still intercepts requests before they reach my plugin.

• Is there a way to disable LocationServer monkey from config?
• Is there a way that I can add my plugin to the RequestProcessor chain BEFORE some of the system (hardcoded) processors such as LocationServer?

Hi, I'm currently evaluating resip/repro as a foundation for the custom SIP routing proxy. I've been studying repro overview document to get a better idea about what comes out of the box with repro and I have a question related to the "Monkey/Baboon/Lemur" concepts:

I understand that sequential forking can be achieved using QValueTargetHandler.

My question is:

• can "Monkey", "Baboon" and "Lemur" pipe execution interleave?

The reason I'm asking this question is because I need to be able to implement a routing logic where next target may depend on the previous target response (think of a conditional fallback routing). To implement this using concepts from the above diagram, I imagine I would need to:

• first execute a Monkey that produces "target 1"
• then execute some of the Baboons to prepare/eject the request to the "target 1"
• then execute a Lemur to process the response
• then (optionally) repeat the Monkey/Baboon/Lemur cycle for the next target dynamically based on the "target 1" response until the call is connect (or max number of attempts is reached)

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

Bumps ini from 1.3.5 to 1.3.8. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/ini/commit/a2c5da86604bc2238fe393c5ff083bf23a9910eb"><code>a2c5da8</code></a> 1.3.8</li> <li><a href="https://github.com/npm/ini/commit/af5c6bb5dca6f0248c153aa87e25bddfc515ff6e"><code>af5c6bb</code></a> Do not use Object.create(null)</li> <li><a href="https://github.com/npm/ini/commit/8b648a1ac49e1b3b7686ea957e0b95e544bc6ec1"><code>8b648a1</code></a> don't test where our devdeps don't even work</li> <li><a href="https://github.com/npm/ini/commit/c74c8af35f32b801a7e82a8309eab792a95932f6"><code>c74c8af</code></a> 1.3.7</li> <li><a href="https://github.com/npm/ini/commit/024b8b55ac1c980c6225607b007714c54eb501ba"><code>024b8b5</code></a> update deps, add linting</li> <li><a href="https://github.com/npm/ini/commit/032fbaf5f0b98fce70c8cc380e0d05177a9c9073"><code>032fbaf</code></a> Use Object.create(null) to avoid default object property hazards</li> <li><a href="https://github.com/npm/ini/commit/2da90391ef70db41d10f013e3a87f9a8c5d01a72"><code>2da9039</code></a> 1.3.6</li> <li><a href="https://github.com/npm/ini/commit/cfea636f534b5ca7550d2c28b7d1a95d936d56c6"><code>cfea636</code></a> better git push script, before publish instead of after</li> <li><a href="https://github.com/npm/ini/commit/56d2805e07ccd94e2ba0984ac9240ff02d44b6f1"><code>56d2805</code></a> do not allow invalid hazardous string as section name</li> <li>See full diff in <a href="https://github.com/isaacs/ini/compare/v1.3.5...v1.3.8">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~isaacs">isaacs</a>, a new releaser for ini since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

We want my uas(sip server) have different registered behavior for some especially uac(sip client). For example: (1) No authenticate (a)uac A register to uas, (b)uas response uac sip 200 ok. (2)authenticate (a)uac B register to uas (b)uas response uac sip 401 Unauthorized (c)uac response uas register to authenticate (d)uas response uac sip 200 ok

We want uas can support (1)(2) behavior at same times.but when we call setServerAuthManager,All register will used (2) behavior.All register will used (1) behavior when not call setServerAuthManager. How can tell me,How can i do？please....

The repro proxy is a good example of how to do this. rePro will NOT challenge requests that are received from IP addresses in its ACL list. You can override the ServerAuthManager and make your own decisions on which requests to require authentication for. See ReproServerAuthManager::requiresChallenge for an example.

Scott

On Thu, Jan 7, 2021 at 10:19 AM ChuLiqiang [email protected] wrote:

We want my uas(sip server) have different registered behavior for some especially uac(sip client). For example: (1) No authenticate (a)uac A register to uas, (b)uas response uac sip 200 ok. (2)authenticate (a)uac B register to uas (b)uas response uac sip 401 Unauthorized (c)uac response uas register to authenticate (d)uas response uac sip 200 ok

We want uas can support (1)(2) behavior at same times.but when we call setServerAuthManager,All register will used (2) behavior.All register will used (1) behavior when not call setServerAuthManager. How can tell me,How can i do？please....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/resiprocate/resiprocate/issues/170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVU2UOCBQTEUNAFRAKCDS3SYXGIXANCNFSM4VZD2QTQ .