What is possible with the cisco 8841?

Hi everyone,

I have a cisco 8841 on Asterisk 18 with Freepbx 16. I tried the patch usecallmanagernz and Chan SCCP with SCCP manager but I’m still stuck on the following features :

Conference - When I try do to a conference, the phone say “Unable to complete conference”

Do not disturb - When I active it, I have a lot of log like this :
res_pjsip/pjsip_distributor.c:676 log_failed_request: Request ‘PUBLISH’ from ‘sip:a4b2392ed5ec@172.20.10.9’ failed for ‘172.20.10.5:49305’ (callid: a4b2392e-d5ec0006-1e8fb521-517befd5@172.20.10.5) - Failed to authenticate

idivert - When I refuse a call, idivert softkeys do not refuse the call

Has anyone found a solution to these problems ?

Thank you

Use call manager works only on the sip stack and not pjsip.

Have both calls supervised at the time in question? I seem to recall there being limitations with conferencing with unsupervised calls.

You’ll need to provide more debug information, either way. See Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

Thank you for your quick responses. I reinstalled usecallmanager and try with chan_sip. The DND works but I’m still stuck with iDivert and conference.

About iDivert

[2022-08-06 03:46:59] DEBUG[21564]: acl.c:1047 ast_ouraddrfor: For destination '172.20.10.5', our source address is '172.25.0.2'.
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:3953 ast_sip_ouraddrfor: Target address 172.20.10.5:50903 is not local, substituting externaddr
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:3990 ast_sip_ouraddrfor: Setting AST_TRANSPORT_TCP with address 172.20.10.9:5160
[2022-08-06 03:46:59] DEBUG[21564]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting '172.20.10.5:50903' into...
[2022-08-06 03:46:59] DEBUG[21564]: netsock2.c:224 ast_sockaddr_split_hostport: ...host '172.20.10.5' and port '50903'.
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:9107 __sip_alloc: Allocating new SIP dialog for OutOfDialog--00fe-15d8681f-72f8b3a2@172.20.10.5 - REFER (No RTP)
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:29201 handle_incoming: **** Received REFER (9) - Command in SIP REFER
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:27361 handle_request_refer: Call OutOfDialog--00fe-15d8681f-72f8b3a2@172.20.10.5: Declined REFER, outside of dialog...
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:3814 __sip_xmit: Trying to put 'SIP/2.0 603' onto TCP socket destined for 172.20.10.5:50903
[2022-08-06 03:46:59] DEBUG[21564]: chan_sip.c:3470 sip_alreadygone: Setting SIP_ALREADYGONE on dialog OutOfDialog--00fe-15d8681f-72f8b3a2@172.20.10.5
[2022-08-06 03:46:59] DEBUG[21470]: chan_sip.c:6689 sip_pvt_dtor: Destroying SIP dialog OutOfDialog--00fe-15d8681f-72f8b3a2@172.20.10.5

And conference

[2022-08-06 02:45:01] DEBUG[18633][C-0000000a]: res_rtp_asterisk.c:5328 ast_rtp_write: (0x7f27300442c0) RTP no remote address on instance, so dropping frame
[2022-08-06 02:45:01] DEBUG[18633][C-0000000a]: res_rtp_asterisk.c:5328 ast_rtp_write: (0x7f27300442c0) RTP no remote address on instance, so dropping frame
[2022-08-06 02:45:01] DEBUG[18633][C-0000000a]: res_rtp_asterisk.c:5328 ast_rtp_write: (0x7f27300442c0) RTP no remote address on instance, so dropping frame
[2022-08-06 02:45:01] DEBUG[17633]: acl.c:1047 ast_ouraddrfor: For destination '172.20.10.5', our source address is '172.25.0.2'.
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:3953 ast_sip_ouraddrfor: Target address 172.20.10.5:50461 is not local, substituting externaddr
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:3990 ast_sip_ouraddrfor: Setting AST_TRANSPORT_TCP with address 172.20.10.9:5160
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:9107 __sip_alloc: Allocating new SIP dialog for a4b2392e-d5ec00a3-38d619b7-4857d863@172.20.10.5 - REFER (No RTP)
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:27361 handle_request_refer: Call a4b2392e-d5ec00a3-38d619b7-4857d863@172.20.10.5: Declined REFER, outside of dialog...
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:3814 __sip_xmit: Trying to put 'SIP/2.0 603' onto TCP socket destined for 172.20.10.5:50461
[2022-08-06 02:45:01] DEBUG[17633]: chan_sip.c:3470 sip_alreadygone: Setting SIP_ALREADYGONE on dialog a4b2392e-d5ec00a3-38d619b7-4857d863@172.20.10.5

I also dug all the features, park and record don’t work either

About park

[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:9514 __find_call: = Looking for  Call ID: a4b2392e-d5ec00b8-50312962-40f0ee72@172.20.10.5 (Checking From) --From tag a4b2392ed5ec055b0c6e08db-77d3726a --To-tag
[2022-08-06 04:20:35] DEBUG[21564]: acl.c:1047 ast_ouraddrfor: For destination '172.20.10.5', our source address is '172.25.0.2'.
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:3953 ast_sip_ouraddrfor: Target address 172.20.10.5:50903 is not local, substituting externaddr
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:3990 ast_sip_ouraddrfor: Setting AST_TRANSPORT_TCP with address 172.20.10.9:5160
[2022-08-06 04:20:35] DEBUG[21564]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting '172.20.10.5:50903' into...
[2022-08-06 04:20:35] DEBUG[21564]: netsock2.c:224 ast_sockaddr_split_hostport: ...host '172.20.10.5' and port '50903'.
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:9107 __sip_alloc: Allocating new SIP dialog for a4b2392e-d5ec00b8-50312962-40f0ee72@172.20.10.5 - REFER (No RTP)
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:29201 handle_incoming: **** Received REFER (9) - Command in SIP REFER
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:27361 handle_request_refer: Call a4b2392e-d5ec00b8-50312962-40f0ee72@172.20.10.5: Declined REFER, outside of dialog...
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:3814 __sip_xmit: Trying to put 'SIP/2.0 603' onto TCP socket destined for 172.20.10.5:50903
[2022-08-06 04:20:35] DEBUG[21564]: chan_sip.c:3470 sip_alreadygone: Setting SIP_ALREADYGONE on dialog a4b2392e-d5ec00b8-50312962-40f0ee72@172.20.10.5
[2022-08-06 04:20:36] DEBUG[21470]: chan_sip.c:6689 sip_pvt_dtor: Destroying SIP dialog a4b2392e-d5ec00b8-50312962-40f0ee72@172.20.10.5

And record

[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:9514 __find_call: = Looking for  Call ID: OutOfDialog--0124-4053f314-4064cf9e@172.20.10.5 (Checking From) --From tag a4b2392ed5ec05741c056259-2fabcf73 --To-tag
[2022-08-06 04:19:25] DEBUG[21564]: acl.c:1047 ast_ouraddrfor: For destination '172.20.10.5', our source address is '172.25.0.2'.
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:3953 ast_sip_ouraddrfor: Target address 172.20.10.5:50903 is not local, substituting externaddr
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:3990 ast_sip_ouraddrfor: Setting AST_TRANSPORT_TCP with address 172.20.10.9:5160
[2022-08-06 04:19:25] DEBUG[21564]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting '172.20.10.5:50903' into...
[2022-08-06 04:19:25] DEBUG[21564]: netsock2.c:224 ast_sockaddr_split_hostport: ...host '172.20.10.5' and port '50903'.
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:9107 __sip_alloc: Allocating new SIP dialog for OutOfDialog--0124-4053f314-4064cf9e@172.20.10.5 - REFER (No RTP)
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:29201 handle_incoming: **** Received REFER (9) - Command in SIP REFER
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:27361 handle_request_refer: Call OutOfDialog--0124-4053f314-4064cf9e@172.20.10.5: Declined REFER, outside of dialog...
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:3814 __sip_xmit: Trying to put 'SIP/2.0 603' onto TCP socket destined for 172.20.10.5:50903
[2022-08-06 04:19:25] DEBUG[21564]: chan_sip.c:3470 sip_alreadygone: Setting SIP_ALREADYGONE on dialog OutOfDialog--0124-4053f314-4064cf9e@172.20.10.5
[2022-08-06 04:19:25] DEBUG[21470]: chan_sip.c:6689 sip_pvt_dtor: Destroying SIP dialog OutOfDialog--0124-4053f314-4064cf9e@172.20.10.5

I didn’t understand supervised calls though. How to supervise calls ?

Thank you

I didn’t understand supervised calls though. How to supervise calls ?

Supervision refers to whether a call has been answered or not. I know this feature tends to behave differently depending on whether calls have been answered (just a limitation at the moment).

I would recommend reaching out to the actual author of these patches since this is not native mainline Asterisk functionality, so you won’t get support from the Asterisk team on these. He might be able to tell you whether it’s supposed to work and how it’s supposed to work. I don’t have any of these phones handy at the moment to do any testing myself.

https://issues.asterisk.org/jira/browse/ASTERISK-13145

https://usecallmanager.nz/patching-asterisk.html

I found my mistake, I declared the extentions wrongly in extensions.conf. You just had to put the context “[from-internal-custom]”.

[from-internal-custom]
exten => _[x]-cisco-serviceuri-.,1,Goto(${EXTEN:19},1)
...

And for those wondering, all cisco 8800 features work with the usecallmanager patch. The only flaw of this patch is that it doesn’t work with pjsip.

Thank you again for your help

Keep in mind you can never go beyond Asterisk v20 with this. Chan_sip won’t exist in v21 next year.

Yes, I seen that. This is a realy bad news.

Asterisk 18 is supported for another 3 years.

That isn’t true. V18 goes SFO in 2 years, meaning only security fixes for 1 year. V18 is half way through its lifecycle.

V20 will be the last LTS and version of Asterisk to contain chan_sip.

For those interested, I contacted the developper of usecallmanager to find out if there would be a migration to pjsip. Here is his answer:

Creating a whole new channel driver that uses PJSIP is the best option, unfortunately that is a lot of work.

The “lot of work” bit I’ve heard from him before, but “whole new channel driver”?

To me, that seems kind of pointless, given this is the SIP protocol, not the Skinny protocol, so a whole another channel driver seems rather dumb to me, personally. It should be enhancements to PJSIP, perhaps as a separate module where possible, and integrated in otherwise.

The nice thing about PJSIP is that unlike SIP, where Sangoma is not accepting features or enhancements to SIP, this could all be mainstreamed into the codebase, making it easier for people to use.

A problem with usecallmanager at present is that since it relies on patches, if you combine it with other patches to chan_sip, which have grown in number due to Sangoma’s refusal to accept them into the codebase, conflicts have grown more and more prevalent thus making a number of patches incompatible with each other without going through some kind of rebase hell. It’s really all falling apart.

It’ll definitely be a lot of work, probably a several month project, but feasible and probably inevitable at some point. The days of usecallmanager in its current form are numbered.

Let’s clear this up. Chan_SIP received updates and fixes until the first half of 2022. Things like adding UserCallManager to the mainline make no sense because A) it was never added before chan_pjsip was created. B) Since v17 (2019) chan_sip is noload on building and was slated for removal.

Adding anything like this to chan_sip in the last three years made no logical sense. Let’s be honest too, it’s been almost 10 years. The maintainer of the UseCallManager project has had ample time to deal with this and work with the dev team on issues. It would seem this project is joining the list of other Asterisk 3rd party projects that gave up the ghost after v12/v13 with the major overhauls and introduction of chan_pjsip most projects just gave up because Asterisk became “harder to do”.

Chan_SIP received updates and fixes until the first half of 2022.

chan_sip continues to receive bug fixes, even now.
New features or enhancements have not been accepted since 2021. That is what I’m referring to.

Things like adding UserCallManager to the mainline make no sense because A) it was never added before chan_pjsip was created. B) Since v17 (2019) chan_sip is noload on building and was slated for removal.

Neither of these precluded the author from getting it added to chan_sip for the longest time, really. As of this year, it’s no longer possible due to Sangoma policy, but for the previous ten years, it could have been if the author was willing to get them merged. This is stated on the issue itself. The patch author never decided to persue getting them merged.

Adding anything like this to chan_sip in the last three years made no logical sense. Let’s be honest too, it’s been almost 10 years. The maintainer of the UseCallManager project has had ample time to deal with this and work with the dev team on issues. It would seem this project is joining the list of other Asterisk 3rd party projects that gave up the ghost after v12/v13 with the major overhauls and introduction of chan_pjsip most projects just gave up because Asterisk became “harder to do”.

Exactly my point. The project had the chance to get merged, and now even that option is not available anymore. So now it has no choice but to be rewritten for PJSIP if it wants to go mainstream. At this point, it’s either going to be relegated to obsolete, outdated systems or become irrelevant.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.