Re: [OpenSIPS-Users] B2B module and CANCEL
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
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
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
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
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
