[asterisk-users] Help migrating voicemail to database
I am in the process of configuring my systems to store voicemail in a mysql databse as opposed to on the filesystem, as it is now. My backup server is currently configured for db storage, while my production server is still using the filesystem during testing. When I record a vm message on my backup server, I am able to retrieve it, hear it, and delete it as expected. So, I believe my backup server is properly configured. However, when I move to my production server and run a script, that I wrote, to import the vm from the file system to the database, I have problems. I'm able to access the message from the voicemail system. However, when I go to listen to it, I get silence and the Asterisk server stops responding to new calls; I have to restart asterisk. The console log looks like: [Jun 14 07:30:58] -- Playing 'vm-youhave.ulaw' (language 'en') [Jun 14 07:30:59] -- Playing 'digits/1.ulaw' (language 'en') [Jun 14 07:31:00] -- Playing 'vm-INBOX.ulaw' (language 'en') [Jun 14 07:31:01] -- Playing 'vm-and.ulaw' (language 'en') [Jun 14 07:31:01] -- Playing 'vm-first.ulaw' (language 'en') voip11*CLI> voip11*CLI> The console remains responsive, but I'm unable to make any for test calls w/o a restart. The database record that results from my import script looks just like a comparable one created by recording a message from my phone, so I don't THINK it's a data issue. Also, I've been able to verify that the database does contain an actual .wav file with the correct format. Has anyone seen this before? Any suggestions would be welcome. Mike Diehl. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CallerId presence issue
Hi,
I've run into a minor snag trying to pass on CALLERID presence from one
Asterisk to another via SIP (both running 13.16.0)
I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP.
PBX_A gets PRI calls on a 4 port Digium card, and each call naturally has
its own callerid values and presence. I pass on those calls to PBX_B via
SI, and I'm trying to pass on this CALLERID info to PBX_B as well.
My relevant dialplan snippet on PBX_A is:
exten =>
1,1,Dial(SIP/pbx_b/55,,f(${CALLERID(all)})u(${CALLERID(pres)})))
*the u() value being dynamically taken from the channel itself.
On pbx_b, I have a simply verbose line like this:
exten => 55,1,Verbose(1,Presence information :
${CALLERID(num-pres)} - ${CALLERID(name-pres)} - ${CALLERPRES()})
Here is my experience with this: whenever "prohib_not_screened" (tested
via a cell phone with hidden caller id info) is sent in the u() value of
the Dial application, pbx_b always gets "allowed_not_screened" as presence
state.Short version: the callerid presence seems lost on the SIP link.
The callerid info isn't, name and number are fine.
I'm clearly missing something to pass on the callerid presence state via
the SIP link, but I can't figure out what.
Any help or hint would be appreciated.
Michael
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CallerId presence issue
Actually, a correction: the callerid isn't passed on properly either: on
SIP_B I get "Anonymous " instead of " <514-555-1234>" that my
dial app is sending.
The exact dial command that is used, once variables are evaluated, is
this:
Dial(SIP/pbx3/555,,f("" <5145551234>)u(prohib_not_screened))"
While the log value found on the other end of the sip link are evaluated,
I get this:
Callerid name: Anonymous callerid number: number: anonymous Presence
information : allowed_not_screened - allowed_not_screened -
allowed_not_screened
Somewhere in this Dial(SIP/) command callerid info is changed. An
asterisk verbose check does not show me anything that would change
callerid info.
Mike
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Mike
Sent: June 14, 2017 10:18
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: [asterisk-users] CallerId presence issue
Hi,
I've run into a minor snag trying to pass on CALLERID presence from one
Asterisk to another via SIP (both running 13.16.0)
I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP.
PBX_A gets PRI calls on a 4 port Digium card, and each call naturally has
its own callerid values and presence. I pass on those calls to PBX_B via
SI, and I'm trying to pass on this CALLERID info to PBX_B as well.
My relevant dialplan snippet on PBX_A is:
exten =>
1,1,Dial(SIP/pbx_b/55,,f(${CALLERID(all)})u(${CALLERID(pres)})))
*the u() value being dynamically taken from the channel itself.
On pbx_b, I have a simply verbose line like this:
exten => 55,1,Verbose(1,Presence information :
${CALLERID(num-pres)} - ${CALLERID(name-pres)} - ${CALLERPRES()})
Here is my experience with this: whenever "prohib_not_screened" (tested
via a cell phone with hidden caller id info) is sent in the u() value of
the Dial application, pbx_b always gets "allowed_not_screened" as presence
state.Short version: the callerid presence seems lost on the SIP link.
The callerid info isn't, name and number are fine.
I'm clearly missing something to pass on the callerid presence state via
the SIP link, but I can't figure out what.
Any help or hint would be appreciated.
Michael
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CallerId presence issue
On Wed, Jun 14, 2017 at 10:18:19AM -0400, Mike wrote:
> I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP.
> PBX_A gets PRI calls on a 4 port Digium card, and each call naturally has
> its own callerid values and presence. I pass on those calls to PBX_B via
> SI, and I'm trying to pass on this CALLERID info to PBX_B as well.
>
> My relevant dialplan snippet on PBX_A is:
> exten =>
> 1,1,Dial(SIP/pbx_b/55,,f(${CALLERID(all)})u(${CALLERID(pres)})))
...
> I'm clearly missing something to pass on the callerid presence state via
> the SIP link, but I can't figure out what.
Never heard of this method, are you sure this works for SIP, sound more
like for ISDN (look at packet captures).
But the/a standardized method is to use the P-Asserted-Identity and
Privacy headers (rfc3325). This should work if you set in the peer configs
in sip.conf on both sides:
sendrpid=pai
trustrpid=yes
Or you can do header manipulation/getting/setting manualy if desired.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] German sip dial rules
On 12.06.2017 17:00, Hans-Peter Jansen wrote: > > * zero prefix for outside calls > * zero zero or plus prefix for international calls > * handle emergency calls > > With ISDN, one was able to just forward the called number, but with sip, one > has to normalize the dialed pattern in order to match SIP (provider) > expectations... As always, the devil is in the details. > I am not sure if I have understood what your problem actually is. What I have done: 1) Download the number plan for Germany from the Bundesnetzagentur (abbreviated BA in the following text - I don't know the correct English expression) and work through it carefully to get a feeling where possible problems are. In the dial plan: 2) Check if the dial string is exactly one of the well-defined *internal* phone numbers of other users. If yes, make the connection. 3) Using Asterisk's text / regex functions, check if there are forbidden chars in the dial string (i.e. any char except 0-9, +, /, -). If yes, throw an error / deny the connection. 4) Using Asterisk's text replacement / regex functions, do further checks (e.g. + (if existent) must be the first char of the dial string), and normalize the dial string (e.g. convert + to 00, throw away / and -). Now it gets complicated. I have carefully worked through the BA plan to determine the appropriate regular expressions for the following steps. 5) Determine if the dial string is an emergency number. If yes, make the connection. For security reasons, I am doing this before the following checks; these are quite complicated any might contain errors, so I am checking for the emergency case as early as possible in the dial plan. 6) Determine if the called number is outside Germany (yes, possibly I had to use the BA plan for that seemingly easy step, but I can't remember for sure). If yes, make the connection (no further checks then because I don't have the time to study the communication authorities' number plans of all the other countries). 7) If we are still here, the called number is in Germany. Again use the BA number plan to determine what is being called. It is up to you to decide what happens if somebody (possibly accidentally) calls something like "Zeitansage" or "Sozialdienste". I have one rule / filter for every item from the list in the BA plan. This makes quite a bunch of rules, but this setup is working since nearly three years now without any issues. Regards, Binarus -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On 06/11/2017 at 06:51 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote:
>> The distributor is in res/res_pjsip/pjsip_distributor.c, the distributor
>> function being the entry point. That function returning PJ_TRUE
>> indicates to PJSIP that it has been handled and no subsequent modules
>> should be called by that running thread. The distributor itself, though,
>> ends up executing things further in a worker thread using the distribute
>> function.
>
> To be more detailed - PJSIP maintains no queue, a message comes in from
> a transport and is given to modules until one says it has handled the
> message. We place our distributor close to the transport and it puts the
> message into a queue for handling in Asterisk ensuring serialization as
> appropriate, returning that it has handled the message so no other
> modules handle it at that time. Once the message is handled from the
> queue it picks back up invoking modules at the point where the original
> thread left off. This ensures messages are handled as quickly as
> possible without blocking the transport but also provides guarantees on
> ordering and simultaneous execution. (Two messages for the same call
> will be handled in order, one at a time).
>
I added this patch to see, if really all packages are are freed after
they have been processed:
--- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.0 +0200
+++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.23300 +0200
@@ -407,6 +407,7 @@
/* We have a BYE or CANCEL request without a serializer. */
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
rdata,
PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL, NULL);
+ ast_debug(3, "PJ_TRUE 1\n");
return PJ_TRUE;
} else {
if (ast_taskprocessor_alert_get()) {
@@ -439,8 +440,8 @@
pjsip_rx_data_free_cloned(clone);
}
+ ast_debug(3, "PJ_TRUE 3 - ready\n");
ast_taskprocessor_unreference(serializer);
-
return PJ_TRUE;
}
Unfortunately, this patch crashes asterisk when debug is enabled. Is
there another way to check, if all the packages are really freed?
Thanks,
Michael
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote:
>
> I added this patch to see, if really all packages are are freed after
> they have been processed:
>
> --- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.0
> +0200
> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.23300
> +0200
> @@ -407,6 +407,7 @@
> /* We have a BYE or CANCEL request without a serializer.
> */
> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
> rdata,
> PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL,
> NULL);
> + ast_debug(3, "PJ_TRUE 1\n");
> return PJ_TRUE;
> } else {
> if (ast_taskprocessor_alert_get()) {
> @@ -439,8 +440,8 @@
> pjsip_rx_data_free_cloned(clone);
> }
>
> + ast_debug(3, "PJ_TRUE 3 - ready\n");
> ast_taskprocessor_unreference(serializer);
> -
> return PJ_TRUE;
> }
>
>
>
> Unfortunately, this patch crashes asterisk when debug is enabled. Is
> there another way to check, if all the packages are really freed?
That shouldn't cause Asterisk to crash. There's nothing built in to
specifically try to debug this kind of situation. Adding logging to try
to understand what is going on is probably the easiest way.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Snom870 FW:8.7.5.35
Does anyone on this list know how to make the Snom870 with FW:8.7.5.35 display the Caller ID in the display field while the ringing either together with, or instead of, the topmost virtual key in the info column? I realise that the purpose of having the virtual key display the caller ID so as to allow selection of which incoming call to take. But the resulting display size is so small as to make that information unusable. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CallerId presence issue
Thank you - At first glance it seems to have done the trick.
Mike
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Daniel Tryba
Sent: June 14, 2017 10:41
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] CallerId presence issue
On Wed, Jun 14, 2017 at 10:18:19AM -0400, Mike wrote:
> I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP.
> PBX_A gets PRI calls on a 4 port Digium card, and each call naturally
> has its own callerid values and presence. I pass on those calls to
> PBX_B via SI, and I'm trying to pass on this CALLERID info to PBX_B as
well.
>
> My relevant dialplan snippet on PBX_A is:
> exten =>
> 1,1,Dial(SIP/pbx_b/55,,f(${CALLERID(all)})u(${CALLERID(pres)})
> ))
...
> I'm clearly missing something to pass on the callerid presence state
> via the SIP link, but I can't figure out what.
Never heard of this method, are you sure this works for SIP, sound more
like for ISDN (look at packet captures).
But the/a standardized method is to use the P-Asserted-Identity and
Privacy headers (rfc3325). This should work if you set in the peer configs
in sip.conf on both sides:
sendrpid=pai
trustrpid=yes
Or you can do header manipulation/getting/setting manualy if desired.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at:
https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On 06/14/2017 at 05:53 PM Joshua Colp wrote:
> On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote:
>
>
>
>>
>> I added this patch to see, if really all packages are are freed after
>> they have been processed:
>>
>> --- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.0
>> +0200
>> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.23300
>> +0200
>> @@ -407,6 +407,7 @@
>> /* We have a BYE or CANCEL request without a serializer.
>> */
>> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
>> rdata,
>> PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL,
>> NULL);
>> + ast_debug(3, "PJ_TRUE 1\n");
>> return PJ_TRUE;
>> } else {
>> if (ast_taskprocessor_alert_get()) {
>> @@ -439,8 +440,8 @@
>> pjsip_rx_data_free_cloned(clone);
>> }
>>
>> + ast_debug(3, "PJ_TRUE 3 - ready\n");
>> ast_taskprocessor_unreference(serializer);
>> -
>> return PJ_TRUE;
>> }
>>
>>
>>
>> Unfortunately, this patch crashes asterisk when debug is enabled. Is
>> there another way to check, if all the packages are really freed?
>
> That shouldn't cause Asterisk to crash. There's nothing built in to
> specifically try to debug this kind of situation. Adding logging to try
> to understand what is going on is probably the easiest way.
>
Got it - I had to change the complete asterisk-packages (I'm compiling
on base of spec file) - and not just the asterisk-core.
I can now say, that asterisk / pjsip seams to work *mostly* as expected.
Just one exception - and that's the package in question, which can't be
seen in tcpdump.
I extended the above patch by adding the info at the last output:
ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata));
This gives, that for *all* received packages return PJ_TRUE is reached.
But: all packages besides of the phantom resend use the same address
rdata0x7f963c0009b8 - only the phantom resent package uses
rdata0x7f9654081e18. I think, that's the problem. But I don't know what
it means and where it comes from. Do you have an idea?
Thanks,
Michael
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote: > > I can now say, that asterisk / pjsip seams to work *mostly* as expected. > Just one exception - and that's the package in question, which can't be > seen in tcpdump. > > I extended the above patch by adding the info at the last output: > > ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata)); > > This gives, that for *all* received packages return PJ_TRUE is reached. > > But: all packages besides of the phantom resend use the same address > rdata0x7f963c0009b8 - only the phantom resent package uses > rdata0x7f9654081e18. I think, that's the problem. But I don't know what > it means and where it comes from. Do you have an idea? Not without setting up the scenario and digging deep into it. Nothing immediately springs to mind. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
On 06/14/2017 at 10:17 PM, Joshua Colp wrote: > On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote: > > > >> >> I can now say, that asterisk / pjsip seams to work *mostly* as expected. >> Just one exception - and that's the package in question, which can't be >> seen in tcpdump. >> >> I extended the above patch by adding the info at the last output: >> >> ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata)); >> >> This gives, that for *all* received packages return PJ_TRUE is reached. >> >> But: all packages besides of the phantom resend use the same address >> rdata0x7f963c0009b8 - only the phantom resent package uses >> rdata0x7f9654081e18. I think, that's the problem. But I don't know what >> it means and where it comes from. Do you have an idea? > > Not without setting up the scenario and digging deep into it. Nothing > immediately springs to mind. > After enabling pjsip specific debug log in asterisk, I can see, the following behavior: Incoming packages from network are always signaled like this (e.g.): sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=10 (rdata0x7f5f1801a758) <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 ... The path of the critical not existing package is like this and can't be seen elsewhere (there wasn't any corresponding incoming message entry before): sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=10 (rdata0x7f5f100e4c38) <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 ---> ... Normally, "Distributing rdata to modules" can be seen only if pjsip_rx_data_clone is called like in res_pjsip/pjsip_distributor.c This is really odd, because if the fax is sent locally (w/o provider) directly between the same extension, this behavior can't be seen and therefore it's working fine as expected! That's the complete critical excerpt, starting with the regular reInvite received from provider: [2017-06-15 07:43:57] DEBUG[11705]: pjproject:0 :sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=10 (rdata0x7f5f1801a758) <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 ---> INVITE sip:+49111@42.13.16.27:5061 SIP/2.0 Via: SIP/2.0/UDP 195.185.37.60;branch=z9hG4bKHeVwGavN;rport From: ;tag=72F0675F-5942027B00075955-FB9F9700 To: ;tag=f045584d-da09-4913-9b46-102361e397f2 CSeq: 10 INVITE Call-ID: 7f582402-0ce9-4a1a-87f6-b8de8b2a7bc8 Max-Forwards: 68 Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE Supported: 100rel, timer, replaces, norefersub Content-Type: application/sdp Content-Length: 265 Contact: v=0 o=- 1935061780 1935061784 IN IP4 195.185.37.60 s=- c=IN IP4 195.185.37.60 t=0 0 m=image 33818 UDPTL t38 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:1393 a=T38FaxUdpEC:t38UDPRedundancy [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:379 distributor: Searching for serializer on dialog dlg0x7f5f18034698 for Request msg INVITE/cseq=10 (rdata0x7f5f1801a758) [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:385 distributor: Found serializer pjsip/outsess/easybellPJSIP-0076 on dialog dlg0x7f5f18034698 [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:433 distributor: rdata clone: Request msg INVITE/cseq=10 (rdata0x7f5f18052b08) [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:446 distributor: PJ_TRUE 3 - ready Request msg INVITE/cseq=10 (rdata0x7f5f1801a758) [2017-06-15 07:43:57] DEBUG[25171]: pjproject:0 :sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=10 (rdata0x7f5f18052b08) [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:268 t38_initialize_session: UDPTL initialized on session for PJSIP/easybellPJSIP-0009 [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:138 t38_change_state: T.38 state changed to '2' from '0' on channel 'PJSIP/easybellPJSIP-0009' [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:673 defer_incoming_sdp_stream: Deferring incoming SDP stream on PJSIP/easybellPJSIP-0009 for peer re-invite [2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge_native_rtp.c:348 native_rtp_bridge_compatible_check: Bridge 'f8e63423-8fc7-44e4-a33d-c55b7d87d30f' can not use native RTP bridge as it was forbidden while getting details [2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:506 find_best_technology: Bridge technology native_rtp is not compatible with properties of existing bridge. [2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:496 find_best_technology: Bridge technology softmix does not have any capabilities we want. [2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:496 find_best_technology: Bridge technology holding_bridge does not have any capabilities we want. [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip/pjsip_distributor.c:785 distri
