Hi,
I had it in the wrong place which is why it didn't change anything, and have
worked it out using uac_replace_from.
Thanks for your assistance!
2011/4/1 Stanisław Pitucha
> On 1 April 2011 00:25, David Cunningham wrote:
> > Then I get "Done" logged, but no change in the output packet and
Well, in the mean time, you can use the following workaround: let the
phone register over tcp and perform authentication and for subsequent
calls coming from the registered endpoint (tcp/IP/port) you don't need
to authenticate the INVITE - just reuse the existing authenticated TCP
connection. Like
On 1 April 2011 00:25, David Cunningham 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 should use the uac module
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
>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 n
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, O
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 v1.
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 wrote:
> My first respons
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 rad
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 f
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 rem
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
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,
O
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 endpoi
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.
Yo
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 i
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
Subs
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 wrote:
> bump.
>
>
> On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee wrote:
>
>> Hopefully my last question:
>>
>> Using a
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
http://lists.opensips.org/cgi-bin/mailman/listinfo/u
On Thu, Mar 31, 2011 at 10:37 AM, Cindy Leung 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 transaction is over
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
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, OpenSIP
bump.
On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee 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():
>
> Contact: *sip:1
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 tell
On 31 March 2011 12:11, David Cunningham 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 to
> Asterisk, bypassing
Hello,
Thanks for the advice, although I don't think it will help my issue. The 200
OK and other packets are returned to the OpenSIPS server perfectly fine.
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 pl
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
S
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
___
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
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 va
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 the
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: ctn
32 matches
Mail list logo