Out of curiosity, based on the feedback in this bug; is this something that's being fixed? I notice this bug was for 1.6.4, but my experience is in 1.7.1. so I want to make sure if this was fixed, I report a new bug for 1.7.1Hi Bogdan,
This bug fix requires further work in tm module, in
It was not fixed. It is the same bug.
Regards,
Ovidiu Sas
On Thu, Dec 15, 2011 at 3:20 PM, Logan voipmas...@me.com wrote:
Out of curiosity, based on the feedback in this bug; is this something
that's being fixed? I notice this bug was for 1.6.4, but my experience is in
1.7.1. so I want to
Yes, indeed. Thanks for pointing out.
Regards,
Ovidiu Sas
On Mon, Dec 12, 2011 at 1:26 AM, Ryan Bullock rrb3...@gmail.com wrote:
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@voipembedded.com wrote:
Yeah, it's the first request after the modified INVITE that is
malformed (I
I added the log and everything looks fine. It's only adding the PAI to the initial invite which is what I want. The odd thing is there are no issues with the invites, it just looks like the Cancel messages that are being mangled. I posted a separate issue to the list prior to this report but no
Yeah, it's the first request after the modified INVITE that is
malformed (I reproduced this running a snapshot from trunk). Please
open a bug report.
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On Fri, Dec 9, 2011 at 1:52 PM, Logan voipmas...@me.com wrote:
I added
Hello list this is the second odd thing I've seen with b2bua in opensips 1.7.1 It looks like the b2bua module is mangling the cancel message and is ripping out the callid when sending upstream:U 2011/12/07 20:15:05.895915 192.168.1.143:5060 - 192.168.1.145:5090
CANCEL
Are you trying to perform any msg manipulations during b2b scenarios?
Also, keep in mind that the b2b server functionality must be kept
isolated from the proxy server functionality (proxy mode is not
compatible with b2b mode).
Regards,
Ovidiu Sas
-- VoIP Embedded, Inc.http://www.voipembedded.com
I'm storing some $vars in route[0] prior to calling b2b_init_request("top hiding");Then in my local route Im appending a P-Asserted-Identity header.I can't use the custom_headers modparam because it's going to preserve the PAI as it comes in. Most of the time it's not present, or is in the wrong
You need to be careful when you alter requests in B2B mode (the
received INVITE and the sent INVITE belong to different transactions).
Make sure that you have something valid in those vars before applying
any changes to the outgoing message.
Regards,
Ovidiu Sas
On Wed, Dec 7, 2011 at 4:49 PM,
This is the extent of my local route. If the $var is not present, I do not add it. Do you see any issue with what I'm doing here?local_route {#xlog("L_INFO","* IN LOCAL ROUTE \n");if (is_method("INVITE")) {if($var(pai_userpart)) {
Add a log and print out what are you adding before adding it and you
will see if it's good or not.
On Wed, Dec 7, 2011 at 5:13 PM, Logan voipmas...@me.com wrote:
This is the extent of my local route. If the $var is not present, I do not
add it. Do you see any issue with what I'm doing here?
12 matches
Mail list logo
