On Wed, Feb 18, 2009 at 6:55 AM, Daviramos Roussenq Fortunato
daviramo...@gmail.com wrote:
How to convert SIP-T to SIP for Asterisk?
You'll need to strip out ISUP MIME body in your SIP messaging with Asterisk.
--
Raj Jain
___
-- Bandwidth
On Tue, Feb 17, 2009 at 1:06 PM, Daviramos Roussenq Fortunato
daviramo...@gmail.com wrote:
Asterisk supports SIP-T?
Nope. Here is some old discussion on this topic:
http://lists.digium.com/pipermail/asterisk-biz/2008-May/026690.html
--
Raj Jain
)
and Asterisk is ignoring that range.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
will send a SIP REFER to Caller
1 asking it to talk to Caller 3. This will cause Caller 1 to drop it's
session with Caller 2 and send a new INVITE to Caller 3. So, this is how you
do it from a SIP protocol perspective. I'm not sure to what extent Asterisk
supports this capability.
--
Raj Jain
this w/
Asterisk FXS/FXO ports but If you can make it work that way pls. let
us know.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http
control the session and considere it as a loop ? If it
is not a bug, how could I resolve this problem ?
Try setting pedantic=yes in your sip.conf.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2008
completely and it's activating T.38 stream when the remote end hasn't
asked it to do so.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http
stack (we
didn't see these issues on their SCCP phones). That said, SIP is an
open standard and I think you're leaning in the right direction if you
expect you're phones to inter-operate with things other than CUCM in
the future.
--
Raj Jain
emanate from different IP addresses.
Can you present a scenario where this will make sense (in the context where
Asterisk is anchoring the media) ?
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2008
/TCP in production environments will be - connection management and
NAT traversal. I think certain design thought needs to be put in
SIP/TCP feature design to combat these issues.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api
media expected
to flow directly between the phones as opposed to hair-pining through
Asterisk)? If so, some of the delay could be attributed to the time
spent in RE-INVITEs that happen after the call set up.
--
Raj Jain
P.S. There is the directrtpsetup= flag that can eliminate this latency
this capability as well.
Right now, I don't think there is any SIP phone out there that
supports this.
--
Raj Jain
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit
set debug' on the console or Wireshark capture can prove this.
One possibility is that the INVITEs are reaching your server but they
are being blocked by SE-Linux (ip-tables) from reaching to your
Asterisk application.
--
Raj Jain
___
-- Bandwidth
that the version in the origin field MUST
increment by one from the previous SDP.
--
Raj Jain
On Fri, Jun 6, 2008 at 9:57 AM, Edgar Barbosa [EMAIL PROTECTED] wrote:
Hi,
I'm having a problem dialing out to a particular customer via a SIP
provider.
When this customer puts the call on hold
that opens the ports dynamically depending on what's exchanged in the
signaling.
--
Raj Jain
On Tue, May 20, 2008 at 4:41 AM, Shaun Wingrin [EMAIL PROTECTED] wrote:
Please direct me to any usefull links to help secure my asterisk server
once
these ports are opened.
Thanks
Shaun
On Tue, May 20, 2008 at 7:11 AM, Tzafrir Cohen [EMAIL PROTECTED] wrote:
On Tue, May 20, 2008 at 06:46:49AM -0400, Raj Jain wrote:
One way to make the system more secure would be by not opening these ports
statically in Linux iptables. I have not tested this, but Linux iptables
have shipped
Looking at the trace, the entity sending you the INVITE is not
resubmitting INVITE with credentials after the initial INVITE was
challenged with a 401 response by Asterisk. The trace shows two
independent calls and both have the same problem.
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain
, 2008 at 4:45 PM, Raj Jain [EMAIL PROTECTED] wrote:
Looking at the trace, the entity sending you the INVITE is not
resubmitting INVITE with credentials after the initial INVITE was
challenged with a 401 response by Asterisk. The trace shows two
independent calls and both have the same
/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit
I'd concur that allowing SIP to be transported over UDP was one of the
biggest mistakes made in the initial protocol design. In addition to
the issues stated below (such as IP fragmentation and how that impacts
NAT traversal), there are other unsolvable problems w/ SIP/UDP such as
when a request
:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE
by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
efficient.
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com
.
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
to be as seamless as
possible. The person picking up the message on the answering machine
must not be able to detect a gap between the two voices. That is why
this needs to be done in one shot.
On Jan 25, 2008 11:41 AM, Don Pobanz [EMAIL PROTECTED] wrote:
From: Raj Jain - Friday, January 25, 2008 10:07 AM
I'm
' option in the Dial() application but that splits
the call as soon as it is answered, whereas, I need to split the call
after it is established based on a DTMF stimulus. Are there any other
ways of accomplishing this goal?
Any thoughts, ideas?
Thank you,
Raj Jain
mailto:rj2807 at gmail dot com
:50 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] How to check if a SIP phone
isforwardedwithout ringing it ?
9 jan 2008 kl. 02.48 skrev Raj Jain:
This issue of phone vendors not supporting OPTIONS according to RFC
3261
often comes up
not comply with RFC ?
2008/1/9, Raj Jain [EMAIL PROTECTED] :
This issue of phone vendors not supporting OPTIONS according
to RFC 3261
often comes up on this list. Like Kevin Fleming said, an
OPTIONS request is
supposed
This issue of phone vendors not supporting OPTIONS according to RFC 3261
often comes up on this list. Like Kevin Fleming said, an OPTIONS request is
supposed to be responded in the same way as an INVITE. Almost all SIP phone
vendors have construed OPTIONS as some kind of a keep-alive request,
No, that is not correct. The RTP has to be established first to flow
through
Asterisk, and only then may the RTP be renegotiated to flow direct. This
first step is NOT optional.
What about directrtpsetup=yes?
--
Raj
___
--Bandwidth and
The rtptimeout feature has a few limitations:
. It is ineffective when the RTP is not terminated on Asterisk.
. It can cause false session hangups if the remote SIP UA does not support
silence suppression
. The companion rtpholdtimeout can cause false hangups if you make incorrect
judgment on
not seen a trace yet, it'd seem like we're missing something because we're
sending back a 491.
Raj
On Dec 23, 2007 2:21 AM, Johansson Olle E [EMAIL PROTECTED] wrote:
23 dec 2007 kl. 01.45 skrev Raj Jain:
You can not do this. You can not have an INVITE that Asterisk
originated enter back
:51 PM, Raj Jain [EMAIL PROTECTED] wrote:
Olle,
You're right. I missed one thing when I concluded that this was an
INVITE glare condition, which is that when the UAC and UAS dialogs are
matched they're compared with respect to their LOCAL and REMOTE tags as
opposed to the To and From
On Dec 12, 2007 8:01 AM, equis software [EMAIL PROTECTED] wrote:
I try to configure that only registered sips can make calls.
How can I do that?
Registrations are meant for routing calls to end-points, not for accepting
calls from end-points. I don't think Asterisk supports a mechanism which
You can not do this. You can not have an INVITE that Asterisk originated
enter back into Asterisk. Technically this is not a loop, but this is an
INVITE glare and the way Asterisk is reacting is correct.
You'll need to change the Call-Id of the INVITE that goes into Asterisk (a
proxy can not do
In theory, UAs that respond to OPTIONS and INVITE differently are broken.
Below is a quote from section 11.2 of RFC 3261.
The response to an OPTIONS is constructed using the standard rules
for a SIP response as discussed in Section 8.2.6. The response code
chosen MUST be the same that
In what amount of time does 100 Trying message have to be
sent to asterisk? I see asterisk retransmitting the INVITE
message multiple times before receiving the 100 Trying message.
The INVITEs are retransmitted based on a timer T1, which starts at a default
of 500 ms and then exponentially
http://www.faqs.org/rfcs/rfc3398.html
The conversion is lossy. More than 1 SIP cause code is
mapped to a Q.931 cause code (in Asterisk at least). See
hangup_sip2cause() in chan_sip.c
True. The conversion is lossy in that respect and most of the times
semantically incorrect simply because
The only place where it is reasonable to customize is in the
specification of the channel in the configuration file.
That is where
you would customize, for example, whether DTMF is inband,
SIP INFO, or
RFC 2833, as well as what codecs will be negotiated for that
particular
in 75+ RFCs to date. The RFC 3261 alone (the largest RFC
the IETF has ever produced) which covers only the core SIP is 269 pages
long. A book that I've found particularly useful in SIP is the following:
http://www.amazon.com/SIP-Beyond-VoIP-Communications-Revolution/dp/097481300
1
Thanks,
Raj
Adrian,
You are right about last-come-last-known registration. I guess the
phone is sending multiple 180 messages. A SIP debug trace will help
identify this.
Raj
On 9/19/07, Adrian Marsh [EMAIL PROTECTED] wrote:
Hi All,
Can anyone tell me how the below can be happening?
--
On 9/11/07, Rizwan Hisham [EMAIL PROTECTED] wrote:
My requirement is to prevent registrations for aan account if that account
is already registered with a user.
That is a perfectly valid requirement. This is not a SIP protocol
issue. This is a SIP Registrar implementation/policy issue. If a SIP
Olivier,
In principle, Registration/Presence and Call-Processing are separate logical
functions but for cost or other reasons one could combine them in one
software implementation or one physical box. For most parts, Asterisk is the
Registrar in a SIP network and therefore maintains the location
Olivier,
This feature is not supported in Asterisk. I can tell this looking at the code.
If you want to test this yourself, send Asterisk a SUBSCRIBE message
with Event: reg header in it. You can either use an off-the-shelf UA
that supports RFC 3680 to do this or you can use SIPp (an open-source
180 w/ SDP is valid, although not ideal. 183 w/ SDP is a better choice for
early-media. The SIP specifications do not dictate what a UAC should do when
it receives 180 w/ SDP. It depends on the policy implemented in the UAC.
As far as Asterisk is concerned, it could treat 180 w/ SDP same as 183
A cursory interpretation of the RFC suggests that 180
Ringing is a
message designed solely to convey ringback, and that it is
the payload
of the 183 response that may be used to convey additional details
about the nature of the call's progress. Therefore, a 180
would be an
KPML is now an RFC -- http://www.ietf.org/rfc/rfc4730.txt
Asterisk doesn't support KPML today. That doesn't mean it can not be
developed if there is sufiicient interest. The true value of adding KPML
support in Asterisk is when it is acting as a 'softswitch' (call controller
without media
Olle,
Regarding project Pineapple, I'm curious why rewrite (or refactor) the SIP
stack instead of using an open-source one. Did your research show that there
is nothing viable out there that'll fit well w/in Asterisk? OpenPBX
community is talking about using Sofia-SIP stack, for instance.
Raj
Olle,
It depends on how strictly the UA adheres to the offer/answer model. The
issue would be that a RE-INVITE from Asterisk will have the version
number incremented by more than one, which will break the following rule.
Quoting from RFC 3264 Section 8:
When issuing an offer that modifies
I found a subtle difference between the two traces you sent (the call that
works and the call that gets dropped). This may or may not be what's causing
the problem.
The call that gets dropped had a retransmission of INVITE from UAC to
UAS (and therefore retransmission of 200 OK from UAS to UAC).
OPTIONS/200 messages looks correct. Yes, Asterisk requires the From:
header field to contain a valid extension to respond with a 200 to a OPTIONS
request (else it'll respond with a 404).
Raj
On 3/28/07, Steve Edwards [EMAIL PROTECTED] wrote:
I'm (still) trying to get my Asterisk box talking
One potential reason could be that the ACK request being sent to
Asterisk is malformed. Notice branch=0 in the top Via. This should start
with z9hG4bK magic cookie since the INVITE was an RFC 3261 transaction.
While branch=0 is valid in RFC 2543, I don't think an INVITE can start-off
as RFC 3261
52 matches
Mail list logo
