Re: [OpenSIPS-Users] B2B module and CANCEL

2011-06-14 Thread Denis Putyato
Hello Anca

 

I opened bug report on bug tracker 

Thank you for help

 

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Anca Vamanu
Sent: Tuesday, June 14, 2011 4:25 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] B2B module and CANCEL

 

Hi Denis,

Sorry, I have to make a correction - I forgot that the fix that is committed on 
svn is partial and works only if body lumps are applied. So your case will 
still not work
 and needs another fix. I suggest you to open a bug report in svn. 

Regards,
Anca

On 06/14/2011 02:35 PM, Anca Vamanu wrote: 

Hi Denis,

We hit this problem also some time ago, it was indeed a bug when applying lumps 
in local_route. We were just waiting for the fix to get enough testing. It is 
stable now. I have just committed the fix in tm module in both trunk and 1.6. 
Please upgrade and check.

Regards,
Anca

On 06/14/2011 06:57 AM, Denis Putyato wrote: 

Hello

 

I found that this problem appears when I use append_hf() to add some header in 
local route of the proxy1 before sending INVITE to proxy2. Without this adding 
problem disappears.

 

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Denis Putyato
Sent: Friday, June 10, 2011 5:52 PM
To: 'OpenSIPS users mailling list'
Subject: [OpenSIPS-Users] B2B module and CANCEL

 

Hello!

 

I have a such problem opensips1.6.4-2

 

There are two proxies of version 1.6.4.-2 which has been installed on the same 
server.

 

One proxy (proxy1) using B2B “top hiding” and located in /usr/local/sbc and 
using one signaling port 

Another proxy (proxy2) is just SIP proxy and located in 
/usr/local/opensips1.6.4/ and using another signaling port

 

Both proxies using the same ip address of the server

 

Call flow:

 

some UA – proxy1 – proxy2 – some gateway

 

When UA generate CANCEL then proxy1 does some strange things with FROM or TO 
uri headers (you can see it in attachment).  Because of this proxy2 cannot 
parse CANCEL properly and transaction in proxy2 cannot be canceled.

 

Thank you for any help.

 

 

 

 

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


Re: [OpenSIPS-Users] B2B module and CANCEL

2011-06-14 Thread Anca Vamanu

Hi Denis,

Sorry, I have to make a correction - I forgot that the fix that is 
committed on svn is partial and works only if body lumps are applied. So 
your case will still not work

 and needs another fix. I suggest you to open a bug report in svn.

Regards,
Anca

On 06/14/2011 02:35 PM, Anca Vamanu wrote:

Hi Denis,

We hit this problem also some time ago, it was indeed a bug when 
applying lumps in local_route. We were just waiting for the fix to get 
enough testing. It is stable now. I have just committed the fix in tm 
module in both trunk and 1.6. Please upgrade and check.


Regards,
Anca

On 06/14/2011 06:57 AM, Denis Putyato wrote:


Hello

I found that this problem appears when I use append_hf() to add some 
header in local route of the proxy1 before sending INVITE to proxy2. 
Without this adding problem disappears.


*From:*users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Denis Putyato

*Sent:* Friday, June 10, 2011 5:52 PM
*To:* 'OpenSIPS users mailling list'
*Subject:* [OpenSIPS-Users] B2B module and CANCEL

Hello!

I have a such problem opensips1.6.4-2

There are two proxies of version 1.6.4.-2 which has been installed on 
the same server.


One proxy (proxy1) using B2B “top hiding” and located in 
/usr/local/sbc and using one signaling port


Another proxy (proxy2) is just SIP proxy and located in 
/usr/local/opensips1.6.4/ and using another signaling port


Both proxies using the same ip address of the server

Call flow:

some UA – proxy1 – proxy2 – some gateway

When UA generate CANCEL then proxy1 does some strange things with 
FROM or TO uri headers (you can see it in attachment).  Because of 
this proxy2 cannot parse CANCEL properly and transaction in proxy2 
cannot be canceled.


Thank you for any help.



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


Re: [OpenSIPS-Users] B2B module and CANCEL

2011-06-14 Thread Anca Vamanu

Hi Denis,

We hit this problem also some time ago, it was indeed a bug when 
applying lumps in local_route. We were just waiting for the fix to get 
enough testing. It is stable now. I have just committed the fix in tm 
module in both trunk and 1.6. Please upgrade and check.


Regards,
Anca

On 06/14/2011 06:57 AM, Denis Putyato wrote:


Hello

I found that this problem appears when I use append_hf() to add some 
header in local route of the proxy1 before sending INVITE to proxy2. 
Without this adding problem disappears.


*From:*users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Denis Putyato

*Sent:* Friday, June 10, 2011 5:52 PM
*To:* 'OpenSIPS users mailling list'
*Subject:* [OpenSIPS-Users] B2B module and CANCEL

Hello!

I have a such problem opensips1.6.4-2

There are two proxies of version 1.6.4.-2 which has been installed on 
the same server.


One proxy (proxy1) using B2B “top hiding” and located in 
/usr/local/sbc and using one signaling port


Another proxy (proxy2) is just SIP proxy and located in 
/usr/local/opensips1.6.4/ and using another signaling port


Both proxies using the same ip address of the server

Call flow:

some UA – proxy1 – proxy2 – some gateway

When UA generate CANCEL then proxy1 does some strange things with FROM 
or TO uri headers (you can see it in attachment).  Because of this 
proxy2 cannot parse CANCEL properly and transaction in proxy2 cannot 
be canceled.


Thank you for any help.


___
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] B2B module and CANCEL

2011-06-13 Thread Denis Putyato
Hello

 

I found that this problem appears when I use append_hf() to add some header in 
local route of the proxy1 before sending INVITE to proxy2. Without this adding 
problem disappears.

 

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Denis Putyato
Sent: Friday, June 10, 2011 5:52 PM
To: 'OpenSIPS users mailling list'
Subject: [OpenSIPS-Users] B2B module and CANCEL

 

Hello!

 

I have a such problem opensips1.6.4-2

 

There are two proxies of version 1.6.4.-2 which has been installed on the same 
server.

 

One proxy (proxy1) using B2B “top hiding” and located in /usr/local/sbc and 
using one signaling port 

Another proxy (proxy2) is just SIP proxy and located in 
/usr/local/opensips1.6.4/ and using another signaling port

 

Both proxies using the same ip address of the server

 

Call flow:

 

some UA – proxy1 – proxy2 – some gateway

 

When UA generate CANCEL then proxy1 does some strange things with FROM or TO 
uri headers (you can see it in attachment).  Because of this proxy2 cannot 
parse CANCEL properly and transaction in proxy2 cannot be canceled.

 

Thank you for any help.

 

 

 

 

 

 

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


[OpenSIPS-Users] B2B module and CANCEL

2011-06-10 Thread Denis Putyato
Hello!

 

I have a such problem opensips1.6.4-2

 

There are two proxies of version 1.6.4.-2 which has been installed on the same 
server.

 

One proxy (proxy1) using B2B “top hiding” and located in /usr/local/sbc and 
using one signaling port 

Another proxy (proxy2) is just SIP proxy and located in 
/usr/local/opensips1.6.4/ and using another signaling port

 

Both proxies using the same ip address of the server

 

Call flow:

 

some UA – proxy1 – proxy2 – some gateway

 

When UA generate CANCEL then proxy1 does some strange things with FROM or TO 
uri headers (you can see it in attachment).  Because of this proxy2 cannot 
parse CANCEL properly and transaction in proxy2 cannot be canceled.

 

Thank you for any help.

 

 

 

 

 

 

Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_msg: SIP 
Request:
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_msg:  
method:  
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_msg:  
uri: 
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_msg:  
version: 
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
flags=2
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:core:parse_via_param: found param type 232,  = 
; state=6
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:core:parse_via_param: found param type 235,  = ; state=17
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_via: end 
of header reached, state=5
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
via found, flags=2
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
this is the first via
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:receive_msg: 
After parse_msg...
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:receive_msg: 
preparing to run routing scripts...
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
flags=
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_to: end 
of header reached, state=10
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_to: 
display={}, ruri={sip:88123364021@1.1.1.1:5063;transport=UDP}
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:get_hdr_field: 
 [52]; uri=[sip:88123364021@1.1.1.1:5063;transport=UDP] 
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:get_hdr_field: 
to body [#015#012]
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:get_hdr_field: 
cseq : <2> 
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:get_hdr_field: 
content_length=0
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:get_hdr_field: 
found end of header
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:b2b_entities:b2b_prescript_f: start - method = CANCEL
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:core:parse_to_param: tag=2e1b1846
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_to: end 
of header reached, state=29
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_to: 
display={}, ruri={sip:8123364079@1.1.1.1:5063;transport=UDP}
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:b2b_entities:b2b_parse_key: Does not have b2b_entities prefix
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:b2b_entities:b2bl_search_iteratively: Search for record with callid= 
MzBhYzkyODA2YjEzZGEyZTFhNjAxMzBhMjI1NWU3ZmU., tag= 2e1b1846
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:b2b_entities:b2bl_search_iteratively: Found callid= 
MzBhYzkyODA2YjEzZGEyZTFhNjAxMzBhMjI1NWU3ZmU., tag= 2e1b1846
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:tm:t_newtran: 
transaction on entrance=0x
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
flags=
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
flags=78
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:tm:t_lookup_request: start searching: hash=49978, isACK=0
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:tm:matching_3261: 
RFC3261 transaction matching failed
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:tm:t_lookup_request: no transaction found
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:parse_headers: 
flags=
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:core:check_ip_address: params 192.168.18.55, 192.168.18.55, 0
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: DBG:core:_shm_resize: 
resize(0) called
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:tm:cleanup_uac_timers: RETR/FR timers reset
Jun 10 17:40:47 kam /usr/local/sbc/sbin/opensips[1814]: 
DBG:tm:insert_timer_unsafe: [2]: 0xb6b940bc (3652)
Jun 10 17:40:47 kam /usr/local/sbc/sbin