Re: [asterisk-users] T.38 not working - help needed with log interpretation

[Recursive]

Hello,

at first, thanks for helping!

In the meantime, I have done a lot of research and trial and error, and I could 
solve that specific problem. Obviously, the dialplan application "Answer" was 
playing a key role here. My original dialplan snippet (which produced that 
problem) was:

exten => _00., 1, NoOp()
  same => n, Set(FAXOPT(gateway)=yes)
  same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
  same => n, Hangup()

The problem vanished when I changed that to:

exten => _00., 1, NoOp()
  same => n, Answer()
  same => n, Progress()
  same => n, Set(FAXOPT(gateway)=yes)
  same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
  same => n, Hangup()

However, I got another problem then:

The fax training now went well, and a part of the fax was transmitted, i.e. 
switching from G711 to T32 now worked. But after 32 seconds (measured from the 
begin of the transmission) Asterisk claimed that there was a timeout with 
receiving an answer to a critical packet, and ended the transmission (by 
sending BYE messages to both ends).

Wireshark and SIP debug analysis have shown that this error message is 
completely humbug. I have thoroughly gone through the logs line by line more 
times that I could count, and (by following the CSeq) I every time have seen 
that the error message was relating to one or more OK messages which Asterisk 
had sent to the provider, but I swear that the provider correctly had ACKed 
every single of these OK messages. So I really can't imagine how Asterisk came 
to the idea that it hadn't received the answer. Maybe my interpretation of the 
logs is wrong, but if Wireshark's logs show an ACK for every OK, all should be 
well, shouldn't it?

Anyway, that means that I now can send an average one page fax document to fast 
endpoints which do the training quickly and provide high data rates. But if the 
endpoint is slower or if the fax document has multiple pages or a 
disadvantageous structure, it will take more than 32 seconds to transmit and 
thus will be cut by Asterisk. The receiving fax machine in this case either 
sees a part of the page or some weird random patterns.

I think that this is a bug in chan_sip which seemingly does not have the best 
reputation when it comes to T38. The erroneous behaviour has shown in every 
test I have done (4 different fax machines at the other end serviced by three 
different providers, each tested with two different SIP providers (trunks)).

At this point, I have given up chan_sip and hoped that pjsip would behave 
correctly, but what a frustration: Although spending three complete days with 
it, I even couldn't make it do the training. It always makes the SIP provider 
switch to T38 at once at the very beginning of the transmission which of course 
won't work. I think I'll open another thread about that problem; it's somehow 
off-topic here.

Regards and thank you very much,

Recursive



On 10.12.2014 11:42, Frederic Van Espen wrote:
> Hi,
> 
> On Tue, Dec 2, 2014 at 9:24 AM, Recursive  wrote:
>> - Packets 14313, 14314: The provider re-invites asterisk for T.38 (confirmed 
>> by viewing the packet's details), asterisk answers "Trying ..." to the 
>> provider
>> - Packets 14315, 14321, 14322: Asterisk re-invites the local endpoint (again 
>> confirmed by looking into the packet's details), the local endpoint answers 
>> "OK", and asterisk ACKs the OK.
>> - Packets 14323, 14329: Asterisk accepts the invitation from the provider by 
>> sending "OK" to the provider, and the provider ACKs the OK.
>> - Packets 14453, 14454 and 14649: The local endpoint again tries to 
>> re-invite asterisk for T.38 (confirmed by looking into the packet's 
>> details), Asterisk answers "Trying" and then refuses, saying "488: Not 
>> acceptable here"
>> - From then on, things go horribly wrong (probably, the local endpoint is 
>> still expecting G.711 packets, but gets T.38 packets)
>>
>> I have provided all packets which are relevant. The packet numbers are not 
>> contiguous since asterisk currently is on a test server which runs many 
>> other services (the packets of which I have filtered out).
>>
>> I didn't want to clutter this post too much, thus I have only provided an 
>> overview and not the details of each packet. Furthermore, please forgive me 
>> that it's much easier for me to read Wireshark's logs than Asterisk's logs. 
>> Of course, I will provide every log anybody trying to help out asks me for.
>>
>> But my first question is a very simple one:
>>
>> From the log above, I am quite sure that switching to T.38 is done right up 
>> to (and including) packet 14329. I think that my local endpoint then 
>> misbehaves by again re-inviting asterisk for T.38 (as all parties already 
>> have agreed upon T.38).
>>
>> Thus, is my endpoint really misbehaving, and if yes, is there anything I can 
>> do about it on Asterisk's side? Or do the SIP/T.38 state machines allow such 
>> (seemingly superfluous) re-invite, and it's Asterisk's fault to answer with 
>> 488?
> 
> - Could you 

Re: [asterisk-users] T.38 not working - help needed with log interpretation

[Larry Moore]

On 11/12/2014 4:52 PM, Recursive wrote:

Hello,

at first, thanks for helping!

In the meantime, I have done a lot of research and trial and error, and I could solve 
that specific problem. Obviously, the dialplan application "Answer" was playing 
a key role here. My original dialplan snippet (which produced that problem) was:



You may very well find getting T.38 working in your environment in a way 
you would like will consume a large amount of your time, you will also 
find yourself doing a lot of research. What you should have found out by 
now (or perhaps deduced) is that the T.38 is a standard that is varied 
thus one cannot be assured a T.38 solution will always work.



exten =>  _00., 1, NoOp()
   same =>  n, Set(FAXOPT(gateway)=yes)
   same =>  n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
   same =>  n, Hangup()

The problem vanished when I changed that to:

exten =>  _00., 1, NoOp()
   same =>  n, Answer()
   same =>  n, Progress()
   same =>  n, Set(FAXOPT(gateway)=yes)
   same =>  n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
   same =>  n, Hangup()



One may assume this is your dialplan for the outgoing connection with 
which you want T.38 to be supported.


To obtain better assistance you will need to include information such as 
what the local T.38 endpoint is and how it connects to your system. If 
it is in fact a T.38 capable endpoint then you should setting 
FAXOPT(gateway) to no. having Answer() & Progress() for an outgoing T.38 
connection doesn't seem to make sense to me!


You should also include information relating to your SIP configuration 
(with appropriate obfuscations) for the connection to peer 
27XgY8YwfI2S9NAg as well as what T.38 options you have set in the 
general section of sip.conf.


Larry.

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Passing literals with commas to subroutine [SOLVED]

[A J Stiles]

On Tuesday 09 Dec 2014, Daniel Gonzalez wrote:
> Hi,
> 
> Let's say I do:
> 
> Set(data=xxx,yyy)
> Gosub(my-sub,s,1(${data}))
> 
> My subroutine will only receive "xxx" for ARG1. How can I pass a literal
> with a comma to a single argument in a subroutine?
> 
> (The point is: when calling the subroutine I do not know if the variable
> has a comma or not.)

O.K.  I've managed to set myself up a temporary Asterisk box, so I was able to 
do some testing without risking bringing down a production server  :)  And I 
have managed to put together a solution, if you can call it that.

If you put speech marks around the argument, like so:
 Gosub(my-sub,s,1("${data}"))
then what actually comes through in ${ARG1} is
 "xxx,yyy"
(complete with the speech marks).  But at least that comma is protected.  So 
then within my-sub, you just need to evaluate ${ARG1:1:-1}, ${ARG2:1:-1} &c. 
to strip off the first and last characters  (skip one, show all but one).  


It's a bit ugly -- but so is a lot of stuff written in the Dialplan.  Just 
because a language is Turing-complete, doesn't mean any code written in it is 
going to be pretty.  But you might be able to mitigate some of the ugliness 
with comments  (introduced with a semicolon in Dialplan, because the comment 
mark is a valid "digit").

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

Thank you Joshua.

I will make the modifications this morning and give it a try.

Have a great day!

Dan



-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Joshua Colp
Sent: Wednesday, December 10, 2014 7:27 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question



>
> I translated those settings to the following for pjsip.conf...
>
> [transport1]
> type = transport
> bind = 0.0.0.0
> protocol = udp
>
> [outbound.vitelity.net]
> type = aor
> remove_existing = yes
> contact = sip:64.2.142.93@5060

This is incorrect. The contact should be:

contact = sip:64.2.142.93

It will use a default port of 5060.

I also believe I've covered your origination issue in a separate email. 
Your dial string should be:

PJSIP/800...@outbound.vitelity.net

Cheers,

--
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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

Thanks George.

I am NATed.
I did not obfuscate the 0.0.19.196.  That is really what is showing up.
The only portion that I hid is the IP address of my box.

Have a great day!

Dan


On Wed, Dec 10, 2014 at 2:03 PM, Dan Cropp 
mailto:d...@amtelco.com>> wrote:
Thanks George.

That was the ip address I was given.  Unfortunately, my contact at Vitelity is 
gone for the day so I can’t verify it with him.

I added the qualify_frequency as you suggested and it does appear that I have 
something configured incorrectly….

<--- Transmitting SIP request (483 bytes) to 
UDP:0.0.19.196:5060 --->

Well, THAT's not right.  Did you obfuscate the 0.0.19.196 or is that how it 
really is?  Are you NATed?


OPTIONS sip:64.2.142.93@5060 SIP/2.0
Via: SIP/2.0/UDP 
xxx.xxx.xx.xxx:5060;rport;branch=z9hG4bKPjcea63914-b8d1-483d-96db-11968abab704
From: 
;tag=7cfab3ba-73de-4243-9967-d1e6a5e7b0b4
To: 
Contact: 
Call-ID: 7ba766bf-363b-47d0-a388-62a58d1df88d
CSeq: 33778 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Length:  0


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Passing literals with commas to subroutine [SOLVED]

[Eric Wieling]

The easiest way is to escape the commas is with a \ (backslash). 

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of A J Stiles
Sent: Thursday, December 11, 2014 7:41 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Passing literals with commas to subroutine 
[SOLVED]

On Tuesday 09 Dec 2014, Daniel Gonzalez wrote:
> Hi,
> 
> Let's say I do:
> 
> Set(data=xxx,yyy)
> Gosub(my-sub,s,1(${data}))
> 
> My subroutine will only receive "xxx" for ARG1. How can I pass a literal
> with a comma to a single argument in a subroutine?
> 
> (The point is: when calling the subroutine I do not know if the variable
> has a comma or not.)

O.K.  I've managed to set myself up a temporary Asterisk box, so I was able to 
do some testing without risking bringing down a production server  :)  And I 
have managed to put together a solution, if you can call it that.

If you put speech marks around the argument, like so:
 Gosub(my-sub,s,1("${data}"))
then what actually comes through in ${ARG1} is
 "xxx,yyy"
(complete with the speech marks).  But at least that comma is protected.  So 
then within my-sub, you just need to evaluate ${ARG1:1:-1}, ${ARG2:1:-1} &c. 
to strip off the first and last characters  (skip one, show all but one).  


It's a bit ugly -- but so is a lot of stuff written in the Dialplan.  Just 
because a language is Turing-complete, doesn't mean any code written in it is 
going to be pretty.  But you might be able to mitigate some of the ugliness 
with comments  (introduced with a semicolon in Dialplan, because the comment 
mark is a valid "digit").

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

This fixed the problem.

Developer before me wrote some code to build up the dial string.
Always thought that string appeared off, but it worked so I left it alone.

Thanks Joshua and George for helping with this.

Have a great day!

Dan

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 8:37 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

Thank you Joshua.

I will make the modifications this morning and give it a try.

Have a great day!

Dan



-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Joshua Colp
Sent: Wednesday, December 10, 2014 7:27 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question



>
> I translated those settings to the following for pjsip.conf...
>
> [transport1]
> type = transport
> bind = 0.0.0.0
> protocol = udp
>
> [outbound.vitelity.net]
> type = aor
> remove_existing = yes
> contact = sip:64.2.142.93@5060

This is incorrect. The contact should be:

contact = sip:64.2.142.93

It will use a default port of 5060.

I also believe I've covered your origination issue in a separate email. 
Your dial string should be:

PJSIP/800...@outbound.vitelity.net

Cheers,

--
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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Finish extension (avoid dialplan to silently continue in the next priority of another extension)

[Daniel Gonzalez]

Hi,

I have run into a strange behaviour:

[ctx-test]

exten => h,1,NoOp(*** hangup ***)

exten => s,1,NoOp(*** ${EXTEN} ***)
 same => n,...
 same => n,...
 same => n,Hangup()

Strangely, the h extension continues on the priority 2 of the extension s.
Maybe this is caused by the use of same? How can I make sure that an
extension is really ending, something like:

exten => h,1,NoOp(*** hangup ***)
 same => n,RellyEndHere()

For subroutines there is the Return() application, but this can not be used
generally in contexts. Is there any application to finish processing the
extension in the context?


Thanks,

Daniel
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Finish extension (avoid dialplan to silently continue in the next priority of another extension)

[Eric Wieling]

Hangup handling in Asterisk is horrible enough to make the Buddha cry.

The (mostly working) solution I came up with was

1)  Attach a hangup handler to the source channel as soon as possible in 
the dialplan to do whatever post call work which needs to be done.

2)  Use the “g” and “F” options to Dial to play any needed intercept 
messages required after one leg of the call hangs up.

From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Daniel Gonzalez
Sent: Thursday, December 11, 2014 10:58 AM
To: Asterisk Users Mailing List
Subject: [asterisk-users] Finish extension (avoid dialplan to silently continue 
in the next priority of another extension)


Hi,

I have run into a strange behaviour:

[ctx-test]



exten => h,1,NoOp(*** hangup ***)



exten => s,1,NoOp(*** ${EXTEN} ***)

 same => n,...

 same => n,...

 same => n,Hangup()

Strangely, the h extension continues on the priority 2 of the extension s. 
Maybe this is caused by the use of same? How can I make sure that an extension 
is really ending, something like:

exten => h,1,NoOp(*** hangup ***)

 same => n,RellyEndHere()

For subroutines there is the Return() application, but this can not be used 
generally in contexts. Is there any application to finish processing the 
extension in the context?



Thanks,

Daniel
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Finish extension (avoid dialplan to silently continue in the next priority of another extension)

[Matthew Jordan]

On Thu, Dec 11, 2014 at 9:58 AM, Daniel Gonzalez  wrote:
> Hi,
>
> I have run into a strange behaviour:
>
> [ctx-test]
>
> exten => h,1,NoOp(*** hangup ***)
>
> exten => s,1,NoOp(*** ${EXTEN} ***)
>  same => n,...
>  same => n,...
>  same => n,Hangup()
>
> Strangely, the h extension continues on the priority 2 of the extension s.
> Maybe this is caused by the use of same? How can I make sure that an
> extension is really ending, something like:
>
> exten => h,1,NoOp(*** hangup ***)
>  same => n,RellyEndHere()
>
> For subroutines there is the Return() application, but this can not be used
> generally in contexts. Is there any application to finish processing the
> extension in the context?
>

Which version of Asterisk are you using?

Can you provide a log showing the channel continuing on into the s extension?

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

Ok, it didn't quite solve everything.

There is one slight issue.  When I answer the call on my cell phone, Asterisk 
sees it as answered.
I can play audio, send dtmfs, etc and hear it on my phone.
However, a short while later, Vitelity tears down that call and Asterisk is 
never notified about it.

I tell Asterisk to hang up the call (via AMI) and it is removed from Asterisk.

I gather the pjsip trace.  Then, I shut down that VM, fired up another running 
chan_sip.  Did the same behavior and gathered the sip trace.
Using chan_sip, the call worked flawlessly.


Vitelity sends Asterisk the ACK (for the answer).
Asterisk send an ACK in response.  For the sip.conf system, the ACK includes 
the Contact for the response.  For PJSIP, the Contact field is not in the ACK

Is there a setting to indicate whether the Contact field should be sent as part 
of the ACK (response to the OK)?

Have a great day!
Dan


-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 9:58 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

This fixed the problem.

Developer before me wrote some code to build up the dial string.
Always thought that string appeared off, but it worked so I left it alone.

Thanks Joshua and George for helping with this.

Have a great day!

Dan

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 8:37 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

Thank you Joshua.

I will make the modifications this morning and give it a try.

Have a great day!

Dan



-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Joshua Colp
Sent: Wednesday, December 10, 2014 7:27 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question



>
> I translated those settings to the following for pjsip.conf...
>
> [transport1]
> type = transport
> bind = 0.0.0.0
> protocol = udp
>
> [outbound.vitelity.net]
> type = aor
> remove_existing = yes
> contact = sip:64.2.142.93@5060

This is incorrect. The contact should be:

contact = sip:64.2.142.93

It will use a default port of 5060.

I also believe I've covered your origination issue in a separate email. 
Your dial string should be:

PJSIP/800...@outbound.vitelity.net

Cheers,

--
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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

I had my screenshots flipped.  Is there a way to make sure the Contact field is 
NOT included in the ACK response to the OK (for the Answer)?

PJSIP is including the Contact for the ACK response to the OK.
Contact: 

When using the chan_sip, it does not include that field in the ACK response to 
the OK.

(Been a long couple weeks)

Have a great day!

Dan

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 2:24 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

Ok, it didn't quite solve everything.

There is one slight issue.  When I answer the call on my cell phone, Asterisk 
sees it as answered.
I can play audio, send dtmfs, etc and hear it on my phone.
However, a short while later, Vitelity tears down that call and Asterisk is 
never notified about it.

I tell Asterisk to hang up the call (via AMI) and it is removed from Asterisk.

I gather the pjsip trace.  Then, I shut down that VM, fired up another running 
chan_sip.  Did the same behavior and gathered the sip trace.
Using chan_sip, the call worked flawlessly.


Vitelity sends Asterisk the ACK (for the answer).
Asterisk send an ACK in response.  For the sip.conf system, the ACK includes 
the Contact for the response.  For PJSIP, the Contact field is not in the ACK

Is there a setting to indicate whether the Contact field should be sent as part 
of the ACK (response to the OK)?

Have a great day!
Dan


-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 9:58 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

This fixed the problem.

Developer before me wrote some code to build up the dial string.
Always thought that string appeared off, but it worked so I left it alone.

Thanks Joshua and George for helping with this.

Have a great day!

Dan

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 8:37 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

Thank you Joshua.

I will make the modifications this morning and give it a try.

Have a great day!

Dan



-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Joshua Colp
Sent: Wednesday, December 10, 2014 7:27 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question



>
> I translated those settings to the following for pjsip.conf...
>
> [transport1]
> type = transport
> bind = 0.0.0.0
> protocol = udp
>
> [outbound.vitelity.net]
> type = aor
> remove_existing = yes
> contact = sip:64.2.142.93@5060

This is incorrect. The contact should be:

contact = sip:64.2.142.93

It will use a default port of 5060.

I also believe I've covered your origination issue in a separate email. 
Your dial string should be:

PJSIP/800...@outbound.vitelity.net

Cheers,

--
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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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 -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visi

Re: [asterisk-users] PJSIP configuration question

[Joshua Colp]

Dan Cropp wrote:

I had my screenshots flipped.  Is there a way to make sure the Contact field is 
NOT included in the ACK response to the OK (for the Answer)?

PJSIP is including the Contact for the ACK response to the OK.
Contact:



There is no configuration option to configure this behavior. What is the 
full SIP signaling?


--
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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

I am not sure what you mean by the ful SIP signaling?

Here is the trace for the sip.conf which works successfully.
Below that, I will include the trace for the pjsip.conf which it seems Vitelity 
isn't accepting the ACK in response to the OK

 SIP ---

<--- Transmitting SIP request (1004 bytes) to UDP:64.2.142.93:5060 --->
INVITE sip:800555@64.2.142.93 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: 
Contact: 
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
PRACK, REFER, REGISTER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Remote-Party-ID: "Dan" ;privacy=off;screen=no
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Type: application/sdp
Content-Length:   239

v=0
o=- 540555224 540555224 IN IP4 XXX.XXX.XXX.XXX
s=Asterisk
c=IN IP4 XXX.XXX.XXX.XXX
t=0 0
m=audio 10030 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (378 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: 
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0





<--- Received SIP response (844 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32312 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
 
Phone is ringing.
Next, I answer my cell phone


<--- Received SIP response (830 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32313 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<--- Transmitting SIP request (437 bytes) to UDP:64.2.142.93:5060 --->
ACK sip:1800555@64.2.142.93:5060 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj744f71bf-b90a-4e49-9dfb-42ff4aa3a641
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 ACK
Route: 
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Length:  0


<--- Received SIP response (830 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32313 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<--- Transmitting SIP request (437 bytes) to UDP:64.2.142.93:5060 --->
ACK sip:1800555@64.2.142.93:5060 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj744f71bf-b90a-4e49-9dfb-42ff4aa3a641
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 ACK
Route: 
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Length:  0


<--- Received SIP response (830 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da

Re: [asterisk-users] PJSIP configuration question

[Dan Cropp]

Ugh.

I'm having a bad day.  The two traces were swapped.

The one on Asterisk 13 is PJSIP.
The one on Asterisk 12 is using chan_sip.


-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Dan Cropp
Sent: Thursday, December 11, 2014 3:03 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] PJSIP configuration question

I am not sure what you mean by the ful SIP signaling?

Here is the trace for the sip.conf which works successfully.
Below that, I will include the trace for the pjsip.conf which it seems Vitelity 
isn't accepting the ACK in response to the OK

 SIP ---

<--- Transmitting SIP request (1004 bytes) to UDP:64.2.142.93:5060 ---> INVITE 
sip:800555@64.2.142.93 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: 
Contact: 
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
PRACK, REFER, REGISTER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Remote-Party-ID: "Dan" ;privacy=off;screen=no
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Type: application/sdp
Content-Length:   239

v=0
o=- 540555224 540555224 IN IP4 XXX.XXX.XXX.XXX s=Asterisk c=IN IP4 
XXX.XXX.XXX.XXX
t=0 0
m=audio 10030 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (378 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: 
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0





<--- Received SIP response (844 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32312 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
 
Phone is ringing.
Next, I answer my cell phone


<--- Received SIP response (830 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32313 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<--- Transmitting SIP request (437 bytes) to UDP:64.2.142.93:5060 ---> ACK 
sip:1800555@64.2.142.93:5060 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj744f71bf-b90a-4e49-9dfb-42ff4aa3a641
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 ACK
Route: 
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Length:  0


<--- Received SIP response (830 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=z9hG4bKPj61911226-4812-44da-b682-7ec02e8c821a
Record-Route: 
From: "Dan" ;tag=781b4b63-0df9-47ad-9fa1-52a8729359c8
To: ;tag=as7aad862a
Call-ID: 309ec892-56a8-46d2-95ba-a6b1d65d0c43
CSeq: 23191 INVITE
User-Agent: packetrino
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 32312 32313 IN IP4 64.2.142.192
s=session
c=IN IP4 64.2.142.192
t=0 0
m=audio 17494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<--- Transmitting SIP request (437 bytes) to UDP:64.2.142.93:5060 ---> ACK 
sip:1800555@64.2.142.93:5060 SIP/2.0
Via: SIP/2.0/UDP 
XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4b

Re: [asterisk-users] Dynamic Call parking

[Rusty Newton]

On Thu, Jul 3, 2014 at 7:49 AM, Jonas Kellens  wrote:
> Hello,
>
> I know now after some testing that there is no dynamic call parking. Also
> explains why you find no example when searching the internet : no one has a
> working example.

Sorry to bump an old thread, but I wanted to make sure a link to this
relevant issue was here for the archives:
https://issues.asterisk.org/jira/browse/ASTERISK-24596

-- 
Rusty Newton
Digium, Inc. | Community Support Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct: +1 256 428 6200

Check us out at: http://digium.com & http://asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] park()-command always parks on default 701

[Rusty Newton]

On Tue, Nov 25, 2014 at 8:27 AM, Jonas Kellens  wrote:
> Hello,
>
> I have the following in my dialplan :
>
> exten => callpark,n,Set(PARKINGDYNPOS=200-210)
> exten => callpark,n,Set(PARKINGDYNCONTEXT=parked_001)
> exten => callpark,n,Park(2s,parkinglot_001)
>
> I see on the CLI :
>
> [Nov 25 15:08:47] -- Executing [callpark@pbx-routing:10]
> Set("SIP/SipT01-000b", "PARKINGDYNPOS=200-210") in new stack
> [Nov 25 15:08:47] -- Executing [callpark@pbx-routing:11]
> Set("SIP/SipT01-000b", "PARKINGDYNCONTEXT=parked_001") in new stack
> [Nov 25 15:08:47] -- Executing [callpark@pbx-routing:12]
> Park("SIP/SipT01-000b", "5s,parkinglot_001") in new stack
> [Nov 25 15:08:47]   == Parked SIP/SipT01-000b on 701 (lot
> parkinglot_001). Will timeout back to extension [pbx-routing] s, 1 in 50
> seconds
> [Nov 25 15:08:47] -- Added extension '701' priority 1 to parked_77
>
> Why does Asterisk park on 701 ? Why not on 200 ?

I believe because you haven't set the PARKINGDYNEXTEN channel variable
or defined a PARKINGDYNCONTEXT (template parking lot) with a parkext
option defined. Therefore it defaults back to the parkext of the
default lot.

It is all sort of unclear at the moment unfortunately -
https://issues.asterisk.org/jira/browse/ASTERISK-24596

-- 
Rusty Newton
Digium, Inc. | Community Support Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct: +1 256 428 6200

Check us out at: http://digium.com & http://asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Corrupt MixMonitor recordings - .gsm format

[Stefan Viljoen]

Hi all

 

Asterisk 1.8.11.0 on Centos 6.5

 

My VOIP phones are using G729 to a G729 trunk from a vendor (Centracom,
South Africa). Unlicensed G729 codec version on server.

 

75% of my .gsm files from MixMonitor are coming up corrupted about 3 minutes
into the recording.

 

The server has been up for 7 months beforehand with no problems with
recordings to .gsm format files.

 

I noted warnings and errors in the CLI, apparently coinceding with corrupt
MixMonitor recordings:

 

format_gsm.c:65 gsm_read: Short read (13) (Resource temporarily
unavailable)!

WARNING[30727]: app_dial.c:1379 wait_for_answer: Unable to write frametype:
2

WARNING[14712]: file.c:766 ast_readaudio_callback: Failed to write frame

WARNING[2612]: file.c:766 ast_readaudio_callback: Failed to write frame

WARNING[25283]: format_gsm.c:65 gsm_read: Short read (32) (Resource
temporarily unavailable)!

WARNING[28804]: file.c:766 ast_readaudio_callback: Failed to write frame

WARNING[28804]: file.c:766 ast_readaudio_callback: Failed to write frame

 

I'm using 1.8.11.0 on 14 sites countrywide for 3 years now, recording about
80 000 .gsm recordings per day. 

 

The actual VOIP audio is fine, the callers don't have any problems actually
talking to people, it is just the recording that is corrupt, the
conversation itself is fine.

 

Only one site has started producing corrupt .gsm files since last week. I've
already replaced that server with a brand new one, reinstalled the operating
system and Asterisk, problem still persists.

 

I've extensively searched online but nobody seems to have ever experienced
massive .gsm files corruption from MixMonitor - any ideas where I can even
start to look to solve this?

 

Thank you

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users