[OpenSIPS-Users] Opposite of fix_nated_contact?
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 the docs, this is the opposite of fix_nated_contact. Thanks for any advice. -- David Cunningham, Voisonics http://voisonics.com/ US toll-free: +1 888 842 2720 UK: +44 (0) 20 3298 1642 Australia: +61 (0) 2 8063 9019 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] media-relay exception
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: ctnetlink v0.90: registering with nfnetlink. To be honest, I have no clue about what could be going wrong there, but its definitely related to how OpenVZ deals with resources sharing among containers. Unfortunately I have my hands full now and can't start trying to fix this. Nevertheless, I'd like to thank you for confirming the issue, I'll keep it in mind and its also some other users might find useful if the run into the same issue. Kind regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opposite of fix_nated_contact?
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 second, call record_route() in OpenSIPs script before sending out the INVITE. The endpoint will then send in-dialog messages (BYE, re-INVITE) to OpenSIPs. Hope thsi can help you. Regards, Federico 2011/3/31 David Cunningham dcunning...@voisonics.com: 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 the docs, this is the opposite of fix_nated_contact. Thanks for any advice. -- David Cunningham, Voisonics http://voisonics.com/ US toll-free: +1 888 842 2720 UK: +44 (0) 20 3298 1642 Australia: +61 (0) 2 8063 9019 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 value. INVITE #1 gets challenged. INVITE #2 accepted. CANCEL is sent, but CSeq is the same as the one in INVITE #1. It is ok (RFC compliant) for the Cseq in CANCEL to be the same as the Cseq in INVITE: RFC 3261 - section 9.1: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. Regards, -- Anca Vamanu OpenSIPS Developer It is less than ideal for us to contact their support and we'd like to get it fixed asap. I've tried subst(), remove_hf and append_hf to play with CSeq with no luck. Any suggestions? Thanks! Cinthi ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dedicated Presence Service
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
Re: [OpenSIPS-Users] Dedicated Presence Service
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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dedicated Presence Service
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 Sent: Thursday, March 31, 2011 12:12 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Dedicated Presence Service 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opposite of fix_nated_contact?
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 to Asterisk, bypassing OpenSIPS. Most phones take the address from the From header - you might want to change that instead. To do this, look at the uac module. -- KTHXBYE, Stanisław Pitucha ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inconsistence nathelper behavior
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 me if the RTPProxy error comes from an rtpproxy_offer function or rtpproxy_answer? Regards, Razvan On 03/30/2011 01:40 AM, Leon Li wrote: Hi Razvan, I've turned on DBUG, although not many output in syslog. Mar 29 22:12:05 /usr/sbin/opensips[9336]: INVITE Received - RURI=sip:x Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New RURI= *Mar 29 22:12:05 /usr/sbin/opensips[9336]: ERROR:nathelper:force_rtp_proxy: Unable to parse body* Mar 29 22:12:05 /usr/sbin/opensips[9336]: new branch at sip:xx@192.168.1.112:19463;user=phone Mar 29 22:12:05 /usr/sbin/opensips[9321]: incoming reply Mar 29 22:12:05 /usr/sbin/opensips[9325]: incoming reply Mar 29 22:12:07 /usr/sbin/opensips[9323]: incoming reply *Mar 29 22:12:07 /usr/sbin/opensips[9323]: ERROR:nathelper:force_rtp_proxy_body: incorrect port 0 in reply from rtp*proxy *Mar 29 22:12:07 rtpproxy[11501]: INFO:handle_command: lookup request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@Public IP, tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;1/1219087299;1 not found* Mar 29 22:12:07 /usr/sbin/opensips[9323]: ACC: transaction answered: timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@202.158.207.34;code=200;reason=OK Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA - RURI=sip:xx;user=phone;nat=yes F=sip:xx T=sip:@202.158.196.132 C=null Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged: timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@202.158.207.34;code=200;reason=OK Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: empty or bad first line Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: bad message Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:parse_msg: message= Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:receive_msg: parse_msg failed *Mar 29 22:12:34 rtpproxy[11501]: INFO:handle_command: delete request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@202.158.207.34, tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483/1219087299 not found* However, a successful call (i.e. from NATed to public) has much more output, like below. Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;1 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 64286 created, tag 1615321429;1 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with *Public IP of ADSL*:45020 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;2 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 37262 created, tag 1615321429;2 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with *Public IP of ADSL*:23420 BTW, I am running opensips v1.6.2 and rtpproxy version /usr/bin/rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications Thanks, Leon *From:*users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Razvan Crainea *Sent:* Friday, 25 March 2011 8:25 PM *To:* users@lists.opensips.org *Subject:* Re: [OpenSIPS-Users] inconsistence nathelper behavior Hi Leon, You should run rtpproxy with '-d DBUG'. You can find the logs in /var/log/syslog. Regards, Razvan On 03/25/2011 06:58 AM, Leon Li wrote: Thanks Razvan for your reply, Could you kindly instruct me how to turn on debug level for rtpproxy? Regards, Leon *From:*users-boun...@lists.opensips.org mailto:users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Razvan Crainea *Sent:* Friday, 25 March 2011 1:07 AM *To:* OpenSIPS users mailling list *Subject:* Re: [OpenSIPS-Users] inconsistence nathelper behavior Hello Leon, As you can see, OpenSIPS receives an invalid port from RTPProxy, so the problem seems to be there. Can you please set a lower debug level for
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
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():
Contact: *sip:15552345678@1.1.1.1, *sip:15552345678@1.1.1.1;q=1,
sip:2215552345678@2.2.2.2;q=0.9, sip:5552345678@3.3.3.3;q=0.85,
sip:15552345678@5.5.5.5;q=0.8, sip:sip:4415552345678@4.4.4.4;q=0.75
Is there a way to prevent do_routing from adding that entry and/or remove
it after it has been added? OR is there a way to add a q-value to that
instance?
Thanks,
Ryan
On Tue, Mar 29, 2011 at 10:51 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
Nevermind on that issue; I neglected to notice that I had to create the
branch with append_branch() before setting anything.
Thanks for the help.
Ryan
On Tue, Mar 29, 2011 at 9:52 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected
destinations, you can just call use_next_gw and add the uri in RURI to a
destination string ( because use_next_gw sets the RURI to the destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519
).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) =
$var(ds) + , + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination
set is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run
into a couple issues. I'm using the drouting module to do lookups.
Essentially, a dialed number could have potentially several routes, I
want
to return a 300 with these routes in the Contact header. Please tell me
if
this is foolish and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination
set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2* After
3, ds is Contact: *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3* After 4, ds is Contact: *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5,
ds is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3, sip:15552345678@5.5.5.5 mailto:
sip%3A15552345678@5.5.5.5, *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*
It seems that append_branch() deletes the first entry in the
destination set before adding the
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Thanks. On Mar 31, 2011, at 5:03 AM, Anca Vamanu wrote: 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 value. INVITE #1 gets challenged. INVITE #2 accepted. CANCEL is sent, but CSeq is the same as the one in INVITE #1. It is ok (RFC compliant) for the Cseq in CANCEL to be the same as the Cseq in INVITE: RFC 3261 - section 9.1: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. Regards, -- Anca Vamanu OpenSIPS Developer It is less than ideal for us to contact their support and we'd like to get it fixed asap. I've tried subst(), remove_hf and append_hf to play with CSeq with no luck. Any suggestions? Thanks! Cinthi ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 the transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Thanks. On Mar 31, 2011, at 5:03 AM, Anca Vamanu wrote: 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 value. INVITE #1 gets challenged. INVITE #2 accepted. CANCEL is sent, but CSeq is the same as the one in INVITE #1. It is ok (RFC compliant) for the Cseq in CANCEL to be the same as the Cseq in INVITE: RFC 3261 - section 9.1: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. Regards, -- Anca Vamanu OpenSIPS Developer It is less than ideal for us to contact their support and we'd like to get it fixed asap. I've tried subst(), remove_hf and append_hf to play with CSeq with no luck. Any suggestions? Thanks! Cinthi ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dedicated Presence Service
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/users
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
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:
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:15552345678@1.1.1.1, *sip:15552345678@1.1.1.1;q=1,
sip:2215552345678@2.2.2.2;q=0.9, sip:5552345678@3.3.3.3;q=0.85,
sip:15552345678@5.5.5.5;q=0.8, sip:sip:4415552345678@4.4.4.4;q=0.75
Is there a way to prevent do_routing from adding that entry and/or remove
it after it has been added? OR is there a way to add a q-value to that
instance?
Thanks,
Ryan
On Tue, Mar 29, 2011 at 10:51 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
Nevermind on that issue; I neglected to notice that I had to create the
branch with append_branch() before setting anything.
Thanks for the help.
Ryan
On Tue, Mar 29, 2011 at 9:52 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch
assigment [0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch
assigment [0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected
destinations, you can just call use_next_gw and add the uri in RURI to a
destination string ( because use_next_gw sets the RURI to the
destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519
).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) =
$var(ds) + , + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination
set is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run
into a couple issues. I'm using the drouting module to do lookups.
Essentially, a dialed number could have potentially several routes, I
want
to return a 300 with these routes in the Contact header. Please tell me
if
this is foolish and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) ==
2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2*
After 3, ds is Contact: *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3* After 4, ds is Contact: *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5,
ds is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3,
Re: [OpenSIPS-Users] Proxying Presence?
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 Subscribe and Publish messages on the server - see this tutorial: http://www.opensips.org/Resources/PresenceServer. Also in the default script you have the lines for the presence server, just uncomment those and comment some other lines - follow the indications in the commentaries. If you want to implement end-to-end presence, then you have to forward the Subscribe to the other client - just call lookup() and t_relay() for it. Regards, -- Anca Vamanu OpenSIPS Developer On 03/29/2011 06:02 PM, Stephen Bowman wrote: Need some guidance on how presence should be configured. Our setup consists of two SIP registrars with opensips in between them (mainly for codec manipulation purposes). I'm trying to get presence to work. I see SUBSCRIBE messages coming from both SIP registrars, but I don't see that they are proxied or routed to the other SIP registrar. Example: foo.com-- opensips-- bar.com In opensips, I'm seeing a SUBSCRIBE from us...@foo.com to us...@bar.com. But opensips doesn't forward it on to bar.com to get a response. Is this the correct way to approach this? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas o...@voipembedded.com wrote: 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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 remove all the sensitive info from the trace. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 2:19 PM, Daniel Goepp d...@goepp.net wrote: 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 On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas o...@voipembedded.com wrote: 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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq. Exactly! You broke the CSeq between caller and callee. A proxy should never do that! Even if you fix somehow your CANCEL issue, calls will never complete. The 200ok will have a different CSeq then the initial INVITE (for the caller) and it will be discarded (by the caller). Also, BYE will not work. You have bigger issues here then just a CANCEL. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 from. 2.2.2.2 is our proxy, and 3.3.3.3 is another openSIPS server acting as a redirect server. Thanks -dg On Thu, Mar 31, 2011 at 11:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 remove all the sensitive info from the trace. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 2:19 PM, Daniel Goepp d...@goepp.net wrote: 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 On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas o...@voipembedded.com wrote: 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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 transaction is over at this point. 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and send back 180. Phone now sends out a CANCEL, but the CSeq is not the same as INVITE #2. As far as I can tell, everything else (ruri, call-id...) is the same except for CSeq.
Re: [OpenSIPS-Users] Wana replace Asterisk with OpenSIPS in OpenBTS Project
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 radios when in a call or not) is to have a handset having a home radio register some unique identifier to a SIP server (like Asterisk or OpenSIPS). When a handset moves to a different radio that second radio will send its signalling and media, when in a call, to the first radio, perhaps using a proprietary signalling protocol. For additional handsets and radios the complexty increases, but the basics remain the same. The radios, which I assume are either your OpenBTS or some GSM network part behind the BTS, will need to find some way to spread the load of the initial registrations, otherwise your primary radio will have to handle a lot of traffic, but that and much, much more is up to you to solve (it is one of those classic things left to the implementor). I have NO personal knowledge of how to implement DECT or GSM side of things and have only seen finished implementations of products, like the one you're describing, talking to services I am responsible for. -- Andreas Sikkema ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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 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 from. 2.2.2.2 is our proxy, and 3.3.3.3 is another openSIPS server acting as a redirect server. Thanks -dg On Thu, Mar 31, 2011 at 11:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 remove all the sensitive info from the trace. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 2:19 PM, Daniel Goepp d...@goepp.net wrote: 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 On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas o...@voipembedded.com wrote: 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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it by incrementing it's CSeq for it? Thanks -dg On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas o...@voipembedded.com wrote: 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
Re: [OpenSIPS-Users] inconsistence nathelper behavior
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.6.2. Regards, Leon From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, 1 April 2011 12:18 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior 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 me if the RTPProxy error comes from an rtpproxy_offer function or rtpproxy_answer? Regards, Razvan On 03/30/2011 01:40 AM, Leon Li wrote: Hi Razvan, I've turned on DBUG, although not many output in syslog. Mar 29 22:12:05 /usr/sbin/opensips[9336]: INVITE Received - RURI=sip:x Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New RURI= Mar 29 22:12:05 /usr/sbin/opensips[9336]: ERROR:nathelper:force_rtp_proxy: Unable to parse body Mar 29 22:12:05 /usr/sbin/opensips[9336]: new branch at sip:xx@192.168.1.112:19463;user=phone Mar 29 22:12:05 /usr/sbin/opensips[9321]: incoming reply Mar 29 22:12:05 /usr/sbin/opensips[9325]: incoming reply Mar 29 22:12:07 /usr/sbin/opensips[9323]: incoming reply Mar 29 22:12:07 /usr/sbin/opensips[9323]: ERROR:nathelper:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 22:12:07 rtpproxy[11501]: INFO:handle_command: lookup request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@Public IP, tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;1/1219087299;1 not found Mar 29 22:12:07 /usr/sbin/opensips[9323]: ACC: transaction answered: timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77df f783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf 9eca@;code=200;reason=OK mailto:timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b 7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a 7d0-22cf9eca@202.158.207.34;code=200;reason=OK Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA - RURI=sip:xx;user=phone;nat=yes F=sip:xx T=sip:@202.158.196.132 C=null Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged: timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff78 3a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9ec a@4;code=200;reason=OK mailto:timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2 -77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0 -22cf9eca@202.158.207.34;code=200;reason=OK Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: empty or bad first line Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: bad message Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:parse_msg: message= Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:receive_msg: parse_msg failed Mar 29 22:12:34 rtpproxy[11501]: INFO:handle_command: delete request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@ mailto:9332ee00-d9215935-5a7d0-22cf9eca@202.158.207.34 , tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483/1219087299 not found However, a successful call (i.e. from NATed to public) has much more output, like below. Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;1 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 64286 created, tag 1615321429;1 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with Public IP of ADSL:45020 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;2 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 37262 created, tag 1615321429;2 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with Public IP of ADSL:23420 BTW, I am running opensips v1.6.2 and rtpproxy version /usr/bin/rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications Thanks, Leon From:
Re: [OpenSIPS-Users] Need ideas to tamper with CSeq
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, Ovidiu Sas o...@voipembedded.com wrote: 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 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 from. 2.2.2.2 is our proxy, and 3.3.3.3 is another openSIPS server acting as a redirect server. Thanks -dg On Thu, Mar 31, 2011 at 11:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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 remove all the sensitive info from the trace. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 2:19 PM, Daniel Goepp d...@goepp.net wrote: 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 On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas o...@voipembedded.com wrote: 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, Ovidiu Sas On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp d...@goepp.net wrote: 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 endpoint manufacture, but you know what that process is like I'm sure ;) -dg On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas o...@voipembedded.com wrote: 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. You could try to intercept the CANCEL when it hits the main route, replace the CSeq and the forward the CANCEL back to yourself and it may work. This is ugly and it needs to be properly implemented as it may break good clients. The proper solution here would be to add a new server in front of the GW, a server that will be able to handle the two INVITEs (with and without auth header) with the same CSeq number. One solution would be an opensips server configured in b2b mode. This should give you a clean implementation and no hacks in the config. Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp d...@goepp.net wrote: 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 is necessary, and one of the great things about OpenSIPS is how flexible and powerful it is. The only problem here is the CANCEL, all other signaling including the BYE appear to work fine with this phone. Calls complete and end just fine in all other cases. I agree that perhaps a proxy shouldn't have to do this, it is not an absolute in the real world that it would never have to. So this comes back to the initial question, and regardless of best practice, is there a way when OpenSIPS receives a CANCEL to help it
Re: [OpenSIPS-Users] inconsistence nathelper behavior
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 need to fix your script and properly invoke the rtpproxy functions for INVITE/200ok or 200ok/ACK. Maybe it's time to upgrade and use rtpproxy_offer/answer functions (see example in README file): http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id292912 Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 7:11 PM, Leon Li leon...@aarnet.edu.au wrote: 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.6.2. Regards, Leon From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, 1 April 2011 12:18 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior 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 me if the RTPProxy error comes from an rtpproxy_offer function or rtpproxy_answer? Regards, Razvan On 03/30/2011 01:40 AM, Leon Li wrote: Hi Razvan, I’ve turned on DBUG, although not many output in syslog. Mar 29 22:12:05 /usr/sbin/opensips[9336]: INVITE Received - RURI=sip:x Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New RURI= Mar 29 22:12:05 /usr/sbin/opensips[9336]: ERROR:nathelper:force_rtp_proxy: Unable to parse body Mar 29 22:12:05 /usr/sbin/opensips[9336]: new branch at sip:xx@192.168.1.112:19463;user=phone Mar 29 22:12:05 /usr/sbin/opensips[9321]: incoming reply Mar 29 22:12:05 /usr/sbin/opensips[9325]: incoming reply Mar 29 22:12:07 /usr/sbin/opensips[9323]: incoming reply Mar 29 22:12:07 /usr/sbin/opensips[9323]: ERROR:nathelper:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 22:12:07 rtpproxy[11501]: INFO:handle_command: lookup request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@Public IP, tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;1/1219087299;1 not found Mar 29 22:12:07 /usr/sbin/opensips[9323]: ACC: transaction answered: timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@;code=200;reason=OK Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA - RURI=sip:xx;user=phone;nat=yes F=sip:xx T=sip:@202.158.196.132 C=null Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged: timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@4;code=200;reason=OK Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: empty or bad first line Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: bad message Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:parse_msg: message= Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:receive_msg: parse_msg failed Mar 29 22:12:34 rtpproxy[11501]: INFO:handle_command: delete request failed: session 9332ee00-d9215935-5a7d0-22cf9eca@, tags 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483/1219087299 not found However, a successful call (i.e. from NATed to public) has much more output, like below. Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;1 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 64286 created, tag 1615321429;1 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with Public IP of ADSL:45020 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;2 requested, type strong Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port 37262 created, tag 1615321429;2 Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's address with Public IP of ADSL:23420 BTW, I am running opensips v1.6.2 and rtpproxy version /usr/bin/rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for
Re: [OpenSIPS-Users] Opposite of fix_nated_contact?
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 Foo is
still mentioned. Can anyone help?
Thanks,
2011/3/31 Stanisław Pitucha virap...@gmail.com
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
to
Asterisk, bypassing OpenSIPS.
Most phones take the address from the From header - you might want
to change that instead. To do this, look at the uac module.
--
KTHXBYE,
Stanisław Pitucha
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
David Cunningham, Voisonics
http://voisonics.com/
US toll-free: +1 888 842 2720
UK: +44 (0) 20 3298 1642
Australia: +61 (0) 2 8063 9019
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opposite of fix_nated_contact?
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 should use the uac module and uac_replace_from(somebody, sip:number@host); Otherwise, you're in a world of pain to get all the rewriting correct in both ways (answers, subsequent requests, detecting direction, etc.) -- KTHXBYE, Stanisław Pitucha ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
