[OpenSIPS-Users] Aliases to multiple users

[Кузьмицкий Александр]

I`m trying next routing logic:
for alias 1009 i have two subscribers 1000 and 1001

When I try dialing from 1002 to 1009 ring only one phone(first element from
table dbalias).
Config blocks:

..
modparam("alias_db", "append_branches", 1)
..
alias_db_lookup("dbaliases");
...
if($avp(s:dest)=="usrloc"){
route(3);
}
...



route[1] {

# for INVITEs enable some additional helper routes
if (subst_uri('/(sip:.*);nat=yes/\1/')){
setbflag(6);
};
if(isflagset(5)||isbflagset(6)){
route(6);
};
if(isflagset(5)){
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
};

if (is_method("INVITE")) {
t_on_branch("2");
t_on_failure("4");
t_on_reply("2");
t_on_failure("1");


}


if (!t_relay()) {
sl_reply_error();
};
exit;
}

failure_route[4]{
serialize_branches(1);
if(next_branches()){
#lookup("location", "m");
t_on_reply("2");
t_on_failure("1");
xlog("DIALING!");
t_relay();
}
}


route[3]{
if($(rU{s.len}) == 3)
{
# Group is searched on database, by using
# From username.
xlog("!");
cd_lookup("closeddial", "GroupA");
};

xlog("BRANCH=$branch");
if(!lookup("location", "m")){
switch($retcode){
case -1:
case -3:
t_newtran();
t_reply("404", "Contact Not Found");
exit;
case -2:
sl_send_reply("405", "Method Not Allowed");
exit;
}
}

setflag(2);
xlog("ROUTE 3 LOGIC");
route(1);
xlog("AFTER ROUTE 3 LOGIC");
}


route[4]{
rewritehostport("89.107.120.237");
route(1);
}


branch_route[2] {
xlog("new branch at $ru\n");
}


onreply_route[2] {
xlog("incoming reply\n");

if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])"){
force_rtp_proxy();
append_hf("P-hint: onreply_route|force_rtp_proxy \r\n");
}
if(isbflagset(6)){
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
append_hf("P-hint: Onreply-route - fixcontact \r\n");
fix_nated_contact();
}
exit;
}


I can`t find errors. Please, help.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] restore_uri error

[Jeff Pyle]

Hello,

I make use of uac_replace_from() in my scripts.  I believe that is where this 
error message is coming from:
  ERROR:uac:restore_uri: new URI shorter than old URI

Can anyone explain what this really means?  Having a new URI shorter than an 
old one really doesn't seem like an error condition to me.

I haven't changed my script in months.  This error seems to have surfaced 
somewhere around 1.6's 6590 build.


Thanks,
Jeff


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Via with "received=YYY.YYY.YYY.YYY"

[Pauba, Kevin L]

Thanks for the offer, Bogdan.  I've patched it up myself just to see that it 
works as expected.  In msg_translator.c:received_builder() I added the #ifdef 
... #else ... #endif:

#ifdef NOTDEFINED
memcpy(buf, RECEIVED, RECEIVED_LEN);
if ( (tmp=ip_addr2a(source_ip))==0)
return 0; /* error*/
tmp_len=strlen(tmp);
len=RECEIVED_LEN+tmp_len;
memcpy(buf+RECEIVED_LEN, tmp, tmp_len);
#else
len=0;
#endif

The original code was between the #ifdef and #else.  This seems to work fine 
although I welcome any suggested improvements.

I was just looking for an alternative since changing OpenSIPs code is my last 
resort.  This LB is not SIP aware and is almost more pain to work with that 
it's worth but I'm being forced into using it.

OpenSIPs has been a great addition to our platform as it's simplified many 
tasks when trying to get different SIP endpoints working together.  I'm 
thankful for it.

Keep up the good work! :)

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
Sent: Tuesday, February 16, 2010 5:29 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Via with "received=YYY.YYY.YYY.YYY"

Hi,

The received param is automatically added by OpenSIPS (as per RFC) as it 
detects a difference between the IP address in the VIA hdr (the UAC's 
IP) and the source IP at network level (the LB's IP).

There is no way to disable this (as it is standard SIP processing), but 
if something really  important for you, I can give you a patch to 
disable it.

Regards,
Bogdan

Pauba, Kevin L wrote:
> We are using a commercial load balancer in front of a pair of OpenSIPs 
> proxies (V1.6.1).
>
> The proxies add a Via header of the form:
>
> Via: SIP/2.0/UDP 
> XXX.XXX.XXX.XXX:5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bK0eB35ab4ec1c3e0e2d3
>
> ... and forward() on the request.
>
> The replies received by the proxy are then sent to YYY.YYY.YYY.YYY (the load 
> balancer) but it can't figure out where to send them (so they appear to get 
> dropped).  The replies need to get sent to XXX.XXX.XXX.XXX instead.
>
> Is there some way I can remove the "received=YYY.YYY.YYY.YYY;" portion from 
> the Via?
>
> I've tried using subst("/received=YYY\.YYY\.YYY\.YYY//") in the local_route 
> and adding the same subst() call just before the forward() but those didn't 
> work.
>
> Thanks!
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
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

[OpenSIPS-Users] Aliases to multiple users

[Кузьмицкий Александр]

Can you show litle example about using branches in this case?
I want to all calls(branches) starts dialing in parallel mode/
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Via with "received=YYY.YYY.YYY.YYY"

[Bogdan-Andrei Iancu]

Hi,

The received param is automatically added by OpenSIPS (as per RFC) as it 
detects a difference between the IP address in the VIA hdr (the UAC's 
IP) and the source IP at network level (the LB's IP).

There is no way to disable this (as it is standard SIP processing), but 
if something really  important for you, I can give you a patch to 
disable it.

Regards,
Bogdan

Pauba, Kevin L wrote:
> We are using a commercial load balancer in front of a pair of OpenSIPs 
> proxies (V1.6.1).
>
> The proxies add a Via header of the form:
>
> Via: SIP/2.0/UDP 
> XXX.XXX.XXX.XXX:5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bK0eB35ab4ec1c3e0e2d3
>
> ... and forward() on the request.
>
> The replies received by the proxy are then sent to YYY.YYY.YYY.YYY (the load 
> balancer) but it can't figure out where to send them (so they appear to get 
> dropped).  The replies need to get sent to XXX.XXX.XXX.XXX instead.
>
> Is there some way I can remove the "received=YYY.YYY.YYY.YYY;" portion from 
> the Via?
>
> I've tried using subst("/received=YYY\.YYY\.YYY\.YYY//") in the local_route 
> and adding the same subst() call just before the forward() but those didn't 
> work.
>
> Thanks!
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] registrar save "f" flag missing in current builds

[Bogdan-Andrei Iancu]

Hi Jeff,

Now, according to the new release policy,  the backport of this change 
from trunk to 1.6 is doable :) I will take care or it

Regards,
Bogdan

Jeff Pyle wrote:
> Ha!  I crack myself up.  May I request this?
>
>
> - Jeff
>
>
> On Feb 15, 2010, at 8:37 AM, Bogdan-Andrei Iancu wrote:
>
>   
>> Just checked, 1.6 does not have this addition - there was no such 
>> backport done
>>
>> Regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>> 
>>> Interesting, I really thought I had it working on 1.6...
>>>
>>> On Feb 15, 2010, at 8:25 AM, Bogdan-Andrei Iancu wrote:
>>>
>>>
>>>   
 Hi Jeff,

 The "f" flag is present only on the devel / trunk version (SVN).

 Regards,
 Bogdan

 Jeff Pyle wrote:

 
> Bogdan,
>
> I updated to 1.6 SVN 6594 tonight.  The new "f" flag for save() you wrote 
> into 6527 is no longer there.  I poked around some earlier builds and 
> they appear to be missing there as well.  Was there a problem with it?
>
>
> - Jeff
>
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Contact list in REGISTER response

[Bogdan-Andrei Iancu]

Hi,

Yes, that is the only way - if REGISTRAR module builds the reply, it 
will do it in RFC way (adding all the registered contacts) and you 
cannot change this behaviour.

Regards,
Bogdan

mayamatakeshi wrote:
>
> On Tue, Feb 16, 2010 at 12:54 AM, mayamatakeshi 
> mailto:mayamatake...@gmail.com>> wrote:
>
> Hello,
> about registration, is it possible somehow to make opensips to
> reply with a "200 OK" containing only the Contact of the
> registering UA instead of all contacts from usrloc?
>
> I'm having a problem with eyebeam. It has a bug (at least the
> version I'm testing) and it doesn't parse the Contact header
> correctly and it always gets the value of expires from the first
> contact listed.
> So in the case of a "200 OK" with a Contact like this:
>
> Contact:  
> >;expires=5;received="sip:192.168.2.5:5050
> ",  
> >;expires=40;received="sip:192.168.128.33:61717
> "
>
> it should get expires=40 but it is getting expires=5. And since
> eyebeam re-registers 5 seconds before expirations, it sends
> REGISTER immediately and this goes on in a loop till the expires
> of the first contact gets greater than 5 (when the other terminal
> re-registers).
>
>
> I have not tested yet, but I think I got it:
> I have to call the function save with the flag "r" (no Reply), compose 
> the Contact header myself and send the reply.
>
>
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to get dialed number after call start?

[Bogdan-Andrei Iancu]

Hi Alexander,

To read digits after the call started, you need an IVR (media server) - 
OpenSIPS cannot do something like that as it has no media support.

As I remember, Asterisk has a Read function for that - 
http://www.voip-info.org/wiki/view/Asterisk+cmd+Read

Regards,
Bogdan

Кузьмицкий Александр wrote:
> Hi.
> Opensips 1.6.1
> How to get entered via dialpad numbers after call start(as DTMF??)?
> I want to create call parking with asterisk and need to get requested 
> number for forwarding call to asterisk extension.
> Thx.
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Aliases to multiple users

[Bogdan-Andrei Iancu]

Hi Daniel,

actually the alias_db module (as C code) supports multiple users with 
the same alias. see:
   
http://www.opensips.org/html/docs/modules/1.6.x/alias_db.html#id228163

So, if you remove the DB constraint, it should work.

Regards,
Bogdan

Daniel Goepp wrote:
> Thanks, it helps...not the answer I was hoping for, but it helps ;)
>
> -dg
>
>
> On Mon, Feb 15, 2010 at 5:49 PM, Duane Larson  > wrote:
>
> I don't believe the Alias_DB was meant to do what you are asking. 
> You would need to use
> append_branch() along with serialize_branches() and some routing
> logic to get the funtionality you want.
>  
> Hope that helps.
>
> On Mon, Feb 15, 2010 at 7:36 PM, Daniel Goepp  > wrote:
>
> We are currently using aliases for URI dialing into our
> network, and it works great, but I have a question.  I'm not
> able to create two rows with the same username and domain
> values due to key constraints which I assume are put in there
> to match functionality in the module.  However this is kind of
> limiting as I would like to have an alias ring to multiple
> endpoints.  Is this possible?  For example, have an alias
> m...@example.com , and ring my desk phone
> 2125551...@example.com  and my
> soft client 4135551...@example.com
> ?  I'm aware that I could
> register two endpoints with the same line id, and that would
> work, but for other reasons they need to be separate
> registrations and numbers.  Ideas?
>
> Thanks.
>
> -dg
>
> ___
> Users mailing list
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> -- 
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --
>
> ___
> 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
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] B2BUA help

[opensipslist]

Hello Anca,

An ven., févr 12, 2010, opensipsl...@encambio.com schrieb:
>An ven., févr 12, 2010, Anca Vamanu schrieb:
>>It is ok to have cseq 2 on the other side if the received Invite
>>has cseq 1. The implementation uses cseq +1 on the other side :).
>>It should not be an issue.
>>
>You're right.
>
>>Only if for the authorized Invite the cseq is not 3... You
>>observed this?
>>
>[...]
>
>But it's still not working...
>
>Problem
>
>The UAC receives the 401 response from the B2B logic and produces
>the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
>the original (not B2B rewritten) RURI to calculate the MD5 string.
>
>The B2B logic then takes the new INVITE with the 'Authorization'
>header and rewrites the RURI before forwarding it to the media
>server. This rewriting procedure is the same for both the RURI
>and 'To' URI. Both are set to the  parameter of the
>B2B XML file.
>
>When the client entity (media server) gets the new INVITE message
>it rejects it because the RURI has changed thus invalidating the
>'Authorization' string. Do you understand?
>
>Solution
>
>My idea to solve this problem is when specifying a client
>destination in the B2B XML file, a client entity will be created.
>As before, the 'To' tag will be rewritten to match the 
>but the RURI should not be changed. When B2B forwards the INVITE
>message to the media server it will be accepted because the
>'Authorization' header will be correct.
>
>Do you agree, and if so what is the best way to achieve this?
>Maybe it's best to add this new logic as an option to the
> tag? That way the default behaviour would be
>to still rewrite the RURI as B2B was doing before.
>
I've looked at the code and searched for the place where the 'To'
header and RURI are independently set. It seems that some dialog
creation function of the TM module is being used, but I don't see
how to set the 'To' and RURI independently.

Have you thought about the problem I mentioned and the possible
solutions to it? I'm still stuck without a functioning B2BUA,
because the B2B logic is changing the RURI from the original
message.

Regards,
Brian

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] [IMPORTANT] Release policy - changes

[Bogdan-Andrei Iancu]

Hi,

Following the start of the work for OpenSIPS 2.0, the priorities and 
policies on releases changed.

Right now, most of development effort will be invested in the version 
2.0 code. What this means:


A) Old (existing) design

 - there will be no more major release for this design - that's it, 1.6 
is end of line

 - bug fixes will be carried on as usual

 - minor / essential  improvements / adds-on will still be done on 1.6 
branch

 - minor releases on 1.6 branch will contain not only bug fixings, but 
also the improvements and adds-on ; actually 1.6 branch and trunk will 
contain the same code - trunk will be for coding and testing, 1.6 will 
be the stable - after a change/add-on is tested on trunk, it will be 
backported to 1.6 to be part of the next minor release.



B) New (2.0) design
  
  - a complete new SVN entry will be created for the new version (we 
need to keep the current trunk as testing ground for the 1.6 branch)

  - the code already takes shape - once it will have a basic 
functionality (able to start, stop, create threads, cfg read, etc), we 
will upload the code on public SVN.

  - the first release of the 2.0 version is estimated to be done in ~ 11 
months from now. Could be sooner or later, depending on challenges and 
support (man power) we will have.


Shortly, I will upload this new releasing policy on the web site also.



Best regards,
Bogdan

-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users