Hi all,
We have an Asterisk server sending INVITEs via OpenSIPS with a Contact:
sip:1234@123.456.789.012 header where 123.456.789.012 is the Asterisk
server IP. I want the INVITE's Contact as it leaves OpenSIPS to say the
OpenSIPS IP address instead.
How can I do this? From my understanding of
On 30/3/11 7:03 PM, n...@uni-petrol.com wrote:
And I confirm that media-relay run well on openvz host (not virtual
environment).
Good to know!
I found interesting thing when media-relay fail in openvz virtual
environment on openvz host in dmesg appear this string:
Mar 30 20:41:46 kernel:
Hi,
I guess that what you want is that the endpoint receiving the INVITE
sends the 200 OK reply and the subsequent in-dialog messages to
OpenSIPs
For the first point you need to do nothing as the reply should be sent
to the address in the topmost Via header (in this case OpenSIPs'
address). For
On 03/31/2011 03:21 AM, Cindy Leung wrote:
I know I'm doing something bad here. However, we are having a problem with one
of the SIP phones that we support. When it sends out an INVITE and then
CANCEL, the CANCEL is not being forwarded. We are suspecting that it is caused
by a wrong CSeq
Anyone who could give a helping hand here?
Regards,
Paris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
to do what?
s
Il 31/03/2011 11:07, Paris Stamatopoulos ha scritto:
Anyone who could give a helping hand here?
Regards,
Paris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Well it's a huge email I've sent a few days ago, (which I removed from the
reply in order for the mail to be sent since it is kind of huge) :)
Regards,
Paris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Stefano Pisani
On 31 March 2011 12:11, David Cunningham dcunning...@voisonics.com wrote:
The problem is that the destination phone is showing the call with the
Asterisk IP address in it's history, and so if the user chooses to place a
return call to that address (eg returning a missed call) it goes directly
Hello Leon,
As you can see, OpenSIPS is unable to parse the SDP body. Please make
sure that your INVITE message has SDP body. If it does and you still
have the problem, a capture of the initial INVITE would be very useful.
There are no debug messages of RTPProxy, only INFOs. Can you please
bump.
On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee thriller...@gmail.com wrote:
Hopefully my last question:
Using append_branch() and $branch allows me to add all destinations as
branches with q-values. However, I am unable to remove/edit the initial
entry in $ds as set by do_routing():
I guess I wasn't being clear enough in the call flow. I assume the CSeq in the
CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe the transaction is over at this point.
2. Phone sends out INVITE #2 with auth,
What are you trying to do exactly?
s
Il 31/03/2011 16:37, Cindy Leung ha scritto:
I guess I wasn't being clear enough in the call flow. I assume the CSeq in the
CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe
On Thu, Mar 31, 2011 at 10:37 AM, Cindy Leung cinthia...@gmail.com wrote:
I guess I wasn't being clear enough in the call flow. I assume the CSeq in
the CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe the
Hi Paris,
Can you please also get a message trace with a Notify to see exactly
what happens with it?
Regards,
--
Anca Vamanu
OpenSIPS Developer
___
Users mailing list
Users@lists.opensips.org
I was able to manipulate $ru as set by do_routing() to get the behavior I'm
looking for. It's not very clean, but it's functional.
On Thu, Mar 31, 2011 at 9:00 AM, thrillerbee thriller...@gmail.com wrote:
bump.
On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee thriller...@gmail.comwrote:
Hi Stephen,
It depends on the type of presence you want ( depending also on what I
supported by you phones). If the phones are able to send Publish
messages ( if they support Presence Agent), then you can configure the
presence server feature in OpenSIPS. Then you will have to handle the
I don't mean to step on Cinthia's toe here, but I would like to add a little
to her comments / questions in response some follow ups here. The problem
being presented has been acknowledged as a bad device, in violation of the
RFC. And although it's not popular to work around issues, sometimes it
I assume that this is a hack because the GW is not able to properly
handle the second INVITE (with auth header) that has the same Cseq as
the initial INVITE (despite the fact that those two INVITEs are on
different branch-es). As a workaround, the CSeq was probably tempered
in the local_route.
Thanks for the feedback Ovidiu.
The GW appears to handle the INVITEs fine, which is how the transaction CSeq
gets updated to 2. The problem occurs when we get the CANCEL, which has a
CSeq of 1, not 2. We will investigate some of the ideas you propose here.
We have opened a ticket with the
Based on how the problem was described here, the issue is with how
opensips was configured: the second INVITE sent by opensips should
have the same CSeq as the initial INVITE (assuming that you perform
uac authentication in opensips).
Are you performing uac authentication in opensips?
Regards,
It has more to do with what OpenSIPS is receiving, not sending. We get the
first INVITE from the endpoint, challenge it, then get another INVITE from
the endpoint, and it is incrementing the CSeq on the second INVITE. We have
no control over what the endpoint does with Cseq, unfortunately.
-dg
Are you saying that the caller is sending an INVITE with CSeq 1, get's
challenged, sends back an authenticated INVITE with CSeq 2 and when
the call is aborted, the client that generated the second INVITE with
Cseq 2 is sending a CANCEL with CSeq 1?
Can you post a trace of such scenario?
You can
My first response to this got rejected as I was just over the body size
limit for the forum. I'm posting as an attachment this time:
You are exactly correct in your read back ;) Here is a trace, I think I
removed everything. 1.1.1.1 is my office, where both number and
are registered
On 3/29/11 1:34 PM, ALICOMPUTECH wrote:
I need to know the handoff and/or handover support in OpenSIPS as i am a
newbie to this wonderful open source solution.
What I've seen DECT based networks (which from a SIP point of view work
more or less the same as GSM with handsets moving between
The sequence is totally broken.
You can try to modify the Cseq and loop the CANCEL but the proper
thing to do here is to get a fix from the SIP UA manufacturer or get
rid of the phone and use a good one.
Regards,
Ovidiu Sas
On Thu, Mar 31, 2011 at 4:10 PM, Daniel Goepp d...@goepp.net wrote:
My
Hi Razvan,
The call was initialled from CUCM (public side), which always does late
offer, so there is no SDP body in the first INVITE. The SDP was created
in the 200 OK by the Callee (private side). Anyway we can parse this
one?
The function used is force_rtp_proxy() as I am still on
Thanks Ovidiu,
Yeah, that is pretty much the conclusion we had come to regarding the
endpoint...we were just hoping I guess to have a fix and not have to wait
for the vendor to fix the phone, which will likely take quite some time.
Oh well, that's life :(
-dg
On Thu, Mar 31, 2011 at 3:22 PM,
From the log that you previously posted, you are invoking
force_rtp_proxy on the INVITE, and the INVITE has no SDP (and there
you have your first error log).
Then you got a reply and you are trying to invoke force_rtp_proxy with
incorrect parameters maybe and there you have the second error.
You
Thanks for the suggestion. It looks like textops should be able to do
something similar, but my subst isn't actually having any effect on the
packet sent out. For example if I have:
if( subst('/Foo/Bar/ig') ) {
xlog( Done );
}
Then I get Done logged, but no change in the output packet and
On 1 April 2011 00:25, David Cunningham dcunning...@voisonics.com wrote:
Then I get Done logged, but no change in the output packet and Foo is
still mentioned. Can anyone help?
Are you sure you're doing it on the right packet, before you send it out, etc.?
Also, to change From headers you
30 matches
Mail list logo
