[asterisk-users] file command with alaw file
This may be totally irrelevant and it may send you down the wrong track, but I thought I would mention it: There is a bug which can prevent recent versions of asterisk from creating proper headers in WAV files. The bug shows up on Solaris systems but Linux is theoretically not immune to it. If you are creating raw ulaw or alaw files you should probably not expect any headers when things are working normally. But if you are creating wav files (which can contain alaw or ulaw data) and you find a bunch of null characters (0x0) in the header, then you may have hit the bug. See: https://issues.asterisk.org/view.php?id=16610 I did check content of two alaw files (using a hex editor) generated from two aboves cases. For the one fromo CentOS 5.2, beginning bytes look likes : RIFF1^0.WAVEfmt at @...fact.^0.data.^0... and the one from CentOS 5.5 ..RQVTVXEMBAX It seem like the first one have some information about file format, which make our convert tool works correctly, and which the second one doesnt have. -- _ -- 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] problem with trustrpid
I am trying to figure out the behavior of trustrpid Basically its not behaving the way I expected it to or maybe I am missing a configuration option or something else. When a call from a phone is sent to the * box it has the following sip headers: From: From Phone sip:1001 at 10.0.0.29;tag=4bf4bb4e11e92476. Remote-Party-ID: Cloutier sip:5147714203 at 10.0.0.29;privacy=off;screen=no;party=calling;id-type=subscriber;screen=yes. And when the second leg of the call from the * box to our voip provider is setup the call has the following sip headers: From: From Phone sip:5147714203 at 10.0.0.24;tag=as73d69a8f. Remote-Party-ID: From Phone sip:5147714203 at 10.0.0.24;privacy=off;screen=no. Shouldnt the Remote-Party-ID stay what I origionally set it to? in sip.conf for the phone I have set trustrpid=yes and for our provider I have sendrpid=yes I am using asterisk 1.6.0.10 Thanks Alot Jesse Cloutier I had a similar situation in which playing with trustrpid did not seem to have any effect. The solution was to use the I option to Dial. (that is an upper case i). In the end I could not say whether or not trustpid is broken because it is not entirely clear what it is supposed to do. -crjw -- _ -- 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] CONNECTEDLINE(), progressinband=no and 183 before 180 (with latest trunk)
I don't expect my SIP provider to provide useful Remote-Party-ID information.
Therefore, I am using CONNECTEDLINE(num)=xxx AND CONNECTEDLINE(name)=yyy to
populate remote party information from a local database.
I am also using the I (upper case i) option for Dial.
Generally I like to see to see the remote party name appear on the phone's
display as soon as a call is dialed... even if the the remote party is BUSY.
I ran into a problem where the Remote-Party-ID does not get displayed on the
caller's phone until the remote phone is answered.
I finally tracked this down to several things:
a) My SIP provider sends 183 Session Progress and inband ringback prior to
sending a 180 Ringing.
b) The default sip.conf file that ships with asterisk suggests using
progressinband=no for polycom phones.
c) The progessinband=no setting prevents the 180 Ringing from being
forwarded to the phone if it is received after the 183 Session Progress.
d) Called-Parity-ID appears to be only sent to the phone with 180 Ringing and
200 OK responses.
# this the sequence of events that transpire:
-caller places call
-asterisk receives 183 Trying from SIP provider and forwards it to the
caller's phone
-asterisk receives inband ringback from SIP provider and forwards it to the
phone (RTP)
-asterisk receives 180 Ringing from SIP provider but does not forward it to
the phone.
-asterisk continues to receive more inband ringback from SIP provider and it
continues to forward it to the phone (RTP)
-remote party answers the phone
-asterisk receives 200 OK from SIP provider; asterisk inserts
Called-Party-ID and then forwards it to the calling phone.
-the display on the caller's phone is finally updated; ringback stops and
someone at the other end says hello.
There are two workarounds which will make the Called-Party-ID show up on the
phone before the call is answered:
i) Use progressinband=never even though the default sip.conf file recommends
against it.
The recommendation is presumably based on some old bugs in the Polycom phones
that no longer exists.
I am using recent Polycom firmware and did not notice any bugs.
Note however that the the display on the phone won't be updated if the remote
phone is BUSY, which in my case is not ideal.
ii) Use the r option to Dial. e.g. Dial(SIP/${ext...@x,300,Ir);
This has the advantage of updating the phone very quickly without waiting for
any respones from the SIP provider.
This may have side effects: ringback could hypothetically be produced when it
shouldn't be.
Questions:
Is there a reason why Remote-Party-ID is not sent to the phone as part of the
183 Trying message?
Could this be a configurable option?
Should the example sip.conf file continue to recommend progressinband=no for
Polycom phones?
-crjw--
_
-- 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
