[OpenSIPS-Devel] [ opensips-Bugs-2940213 ] [B2B_ENTITIES] b2b_parse_key
Bugs item #2940213, was opened at 2010-01-26 15:37
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940213group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Deleted
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key
Initial Comment:
Hi,
This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(callid, hash_index, local_index) = 0)
{
// Error
}
Regards,
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940213group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2940556 ] Timer bug in TM handler
Bugs item #2940556, was opened at 2010-01-27 00:34 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940556group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Pogrebennyk (apogrebennyk) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Timer bug in TM handler Initial Comment: I have got stuck trying to implement a sort of serial forking (forwarding) scenario with OpenSIPS. The thing is that when fr_inv_timer hits, OpenSIPS (prematurely) sends INVITE on the next branch and only after that CANCELs the previous one. (And if the gateway receives different branch on transaction to which no final reply has been sent yet - it can merge the requests.) It can be clearly seen in the attached trace that contains messages from the OpenSIPS to the b2bua on the same machine port 5061. I've found this behavior to be consistent in the versions 1.3.2 - 1.5.3, but the logs that follow are from OpenSER 1.3.2. Similar bug has been reported for Kamailio: http://lists.kamailio.org/pipermail/devel/2009-May/018982.html Another thing I've found is that OpenSIPS resets the fr_timer in retransmission_handler() if no provisional response to INVITE has been received. So if the fr_timer hits OpenSIPS silently fails over to the next forwarding destination without sending CANCEL to this branch (again 1.5.3 is affected). Here we see that it forwards the INVITE and sets FR_TIMER as per script: Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: Request leaving server, D-URI='null' - M=INVITE RURI=sip:40084956288...@195.128.80.211:5061 F=sip:000...@sip2.d-tel.ru T=sip:000...@sip2.d-tel.ru IP=77.122.227.73 ID=YmM1NGE4NWQ1ZWZhZjVjNDBkNzljODZjYTk5MDVlN2Q. [...skipped...] Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:_set_fr_retr: FR_TIMER = 10 Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 10 Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=10, final value=46 ... Here it hits the retransmission_handler() - and this relative timeout is 100 messages appears: Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x28701ad0, INVITE si ... ) Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 100 Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=100, final value=3750 Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [5]: 0x28701d30 (3750) Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : done I think this timeout somehow interferes with fr_timer because when fr_timer hits in 20 seconds, OpenSIPS _silently_ fails over to the next forwarding destination without sending CANCEL to _this_ branch. This occurs only when no provisional response has been got so I tend to think this is somehow related to the timeout thing. I have added extra debug print to insert_timer_unsafe() like: LM_DBG(calling insert_timer_unsafe: timeout=%lld, final value=%lld\n,timeout,timeout + get_ticks()); so you could see the sequence of timer updates: Jan 27 05:04:15 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=200, final value=3950 Jan 27 05:04:17 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=400, final value=4350 Jan 27 05:04:21 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=400, final value=4750 Then OpenSIPS fails over to the next forwarding destination on locally generated 408 - but note there is no real sending cancel... message from cancel_branch() between these messages: Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [0]: 0x28701e60 (56) Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:relay_reply: branch=1, save=1, relay=-1 Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:final_response_handler: done Please check. -- Comment By: Andrew Pogrebennyk (apogrebennyk) Date: 2010-01-27 00:39 Message: Things to note in the ngrep trace: INVITE for branch 1 comes at 05:04:14.173313 - before the CANCEL for branch 0 which comes at 05:04:14.173572. Then there's INVITE for branch 2 at 05:04:24.274084, but no CANCEL for the previous branch (fr_timer in action - my b2bua kept retransmitting 183 Session Progress
[OpenSIPS-Devel] [ opensips-Bugs-2940418 ] stale dialog after using call hold
Bugs item #2940418, was opened at 2010-01-26 21:36 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940418group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Pogrebennyk (apogrebennyk) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: stale dialog after using call hold Initial Comment: I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended. # opensipsctl fifo profile_list_dlgs caller dialog:: hash=3718:1395615021 state:: 4 user_flags:: 0 timestart:: 1264533523 timeout:: 60019 callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM. from_uri:: sip:000...@68.166.6.122 from_tag:: ae344d3e caller_contact:: sip:000...@77.122.227.73:6370 caller_cseq:: 3 caller_route_set:: caller_bind_addr:: udp:68.166.6.122:5060 to_uri:: sip:000...@68.166.6.122 to_tag:: 2135014f callee_contact:: sip:000...@77.122.227.73:27436;rinstance=8c6d4f852faa42eb callee_cseq:: 2 callee_route_set:: callee_bind_addr:: udp:68.166.6.122:5060 -- Comment By: Andrew Pogrebennyk (apogrebennyk) Date: 2010-01-26 21:52 Message: Oh and I'm using version 1.5.3 As for configuration script, I'm doing basically create_dialog() and then set_dlg_profile() to insert dialog onto caller profile. -- Comment By: Andrew Pogrebennyk (apogrebennyk) Date: 2010-01-26 21:48 Message: I'm attaching below one the opensips log for another call, this time with debug=4. This is the stale dialog after after the call end: dialog:: hash=3558:842134357 state:: 4 user_flags:: 0 timestart:: 1264534993 timeout:: 61487 callid:: YTQ3YjRjNTVjYWQwYWRmOTQ5ZDE3MmZjOTlhMGIyY2M. from_uri:: sip:000...@68.166.6.122 from_tag:: 9673d152 caller_contact:: sip:000...@77.122.227.73:6370 caller_cseq:: 3 caller_route_set:: caller_bind_addr:: udp:68.166.6.122:5060 to_uri:: sip:000...@68.166.6.122 to_tag:: b542cf1c callee_contact:: sip:000...@77.122.227.73:27436;rinstance=8c6d4f852faa42eb callee_cseq:: 2 callee_route_set:: callee_bind_addr:: udp:68.166.6.122:5060 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940418group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2941492 ] the second transaction is not linked with the dialog
Bugs item #2941492, was opened at 2010-01-28 12:24 Message generated for change (Tracker Item Submitted) made by aap061 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2941492group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Popov (aap061) Assigned to: Nobody/Anonymous (nobody) Summary: the second transaction is not linked with the dialog Initial Comment: If we have multiple transactions within one dialog, all of them must be linked to the dialog. Overwise, reply route can't use dialog flags for the second and all the following transactions. This situation can be easily reproduced for re-INVITE case Proposal solution is attached Thanks, Alexey -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2941492group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6544] branches/1.6/modules/b2b_entities/dlg.c
Revision: 6544 http://opensips.svn.sourceforge.net/opensips/?rev=6544view=rev Author: anca_vamanu Date: 2010-01-28 11:59:08 + (Thu, 28 Jan 2010) Log Message: --- - fixed wrong strncmp of ruri with server address ( the port must be ignored if one is 5060 and the other not set), reported by Olivier Detour) Modified Paths: -- branches/1.6/modules/b2b_entities/dlg.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] bug in prescript
Hi Olivier,
Thank you for the exact report.
I have committed the fix - rev 6544.
Regards,
--
Anca Vamanu
www.voice-system.ro
Olivier Détour wrote:
Hi,
There is a bug in prescript function when you compare RURI with server_addr:
296 if (method_value!= METHOD_CANCEL
297 !((msg-first_line.u.request.uri.len ==
server_address.len )
298 strncmp(msg-first_line.u.request.uri.s, server_address.s,
299 server_address.len)== 0))
300 {
301 LM_DBG(RURI does not point to me\n);
302 return 1;
303 }
with opensips.cfg:
modparam(b2b_entities, server_address, sip:s...@10.10.10.10)
Imagine if the peer change RURI with adding the default port at the
end of the string,
or remove it: the strncmp is not sufficient.
I am working with a Cisco, and it happens.
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
Hi Olivier,
Olivier Détour wrote:
2010/1/22 Olivier Détour chino540off+kamai...@gmail.com:
Hi,
I understand the problem, but I would like to explain you my topology:
Broker1 Broker2
| |
Tel(10) -- B2BUA1 -- B2BUA2 -- Tel(20)
My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
UAS and UAC).
I want to be able to brake the current SIP session at this moment.
So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
receive it,
because It is not send to sip:s...@1.1.12.3. So message could not be
transmit to B2BUA2 ...
Maybe, I don't understand something here, but b2b_entities API could
be able to manage
this situation ?
Regards,
Hi,
I went through the source code of B2B_entities, and I don't understand
when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
void *uparam) in dlg.c:
357 while(dlg)
358 {
359 if(ruri.len == dlg-ruri.len strncmp(ruri.s,
dlg-ruri.s,
ruri.len)== 0
360 dlg-callid.len ==
callid.len
361 strncmp(dlg-callid.s,
callid.s, callid.len)== 0
362 dlg-tag[CALLER_LEG].len ==
from_tag.len
363 strncmp(dlg-tag[CALLER_LEG].s,
from_tag.s, from_tag.len)== 0)
You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
with B2BUA_entities,
Requests send by caller will change Request URI to speaks directly with UAS.
Why is the RURI in your search?
When I remove the RURI check, it works as my understanding of the RFC.
Regards,
The RURI check was added exactly because the RFC says that the RURI in
CANCEL must be exactly the same as the RURI in INVITE:
The following procedures are used to construct a CANCEL request. 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
www.voice-system.ro
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6545] branches/1.6/modules/b2b_entities/dlg.c
Revision: 6545 http://opensips.svn.sourceforge.net/opensips/?rev=6545view=rev Author: anca_vamanu Date: 2010-01-28 12:15:00 + (Thu, 28 Jan 2010) Log Message: --- - changed = with == for return code checking (bug #2940274) Modified Paths: -- branches/1.6/modules/b2b_entities/dlg.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6546] trunk/modules/b2b_entities/dlg.c
Revision: 6546 http://opensips.svn.sourceforge.net/opensips/?rev=6546view=rev Author: anca_vamanu Date: 2010-01-28 12:15:08 + (Thu, 28 Jan 2010) Log Message: --- - changed = with == for return code checking (bug #2940274) Modified Paths: -- trunk/modules/b2b_entities/dlg.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2940274 ] [B2B_ENTITIES] b2b_parse_key
Bugs item #2940274, was opened at 2010-01-26 16:54
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940274group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key
Initial Comment:
Hi,
This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(callid, hash_index, local_index) = 0)
{
// Error
}
Regards,
--
Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-01-28 14:15
Message:
Hi,
Really a very minor thing.. But if you like the strict checking instead, I
put that - see revision 6546.
Regards,
Anca
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2940274group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
Hi Olivier,
First, please do not send email to me privately ( use reply all).
You are saying that the CANCEL send by b2b_entities does not have the
exact ruri as INVITE?
Can you catch an INVITE and the corresponding CANCEL (send by
b2b_entities) and send them in an e-mail?
Regards,
--
Anca Vamanu
www.voice-system.ro
Olivier Détour wrote:
On Thu, Jan 28, 2010 at 1:05 PM, Anca Vamanu a...@opensips.org wrote:
Hi Olivier,
Olivier Détour wrote:
2010/1/22 Olivier Détour chino540off+kamai...@gmail.com:
Hi,
I understand the problem, but I would like to explain you my topology:
Broker1 Broker2
| |
Tel(10) -- B2BUA1 -- B2BUA2 -- Tel(20)
My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
UAS and UAC).
I want to be able to brake the current SIP session at this moment.
So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
receive it,
because It is not send to sip:s...@1.1.12.3. So message could not be
transmit to B2BUA2 ...
Maybe, I don't understand something here, but b2b_entities API could
be able to manage
this situation ?
Regards,
Hi,
I went through the source code of B2B_entities, and I don't understand
when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
void *uparam) in dlg.c:
357 while(dlg)
358 {
359 if(ruri.len == dlg-ruri.len strncmp(ruri.s,
dlg-ruri.s,
ruri.len)== 0
360dlg-callid.len == callid.len
361 strncmp(dlg-callid.s, callid.s,
callid.len)== 0
362 dlg-tag[CALLER_LEG].len ==
from_tag.len
363 strncmp(dlg-tag[CALLER_LEG].s,
from_tag.s, from_tag.len)== 0)
You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
with B2BUA_entities,
Requests send by caller will change Request URI to speaks directly with
UAS.
Why is the RURI in your search?
When I remove the RURI check, it works as my understanding of the RFC.
Regards,
The RURI check was added exactly because the RFC says that the RURI in
CANCEL must be exactly the same as the RURI in INVITE:
The following procedures are used to construct a CANCEL request. 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,
I understand the RFC, but I think B2B_Entities is not able to send a
CANCEL to another
B2B_Entities and receive it.
So There is a problem, I try to make the architecture with 2 B2B, and
CANCEL is my last problem.
I would like to understand how to send and receive CANCEL from and to B2B.
Regards,
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
2010/1/28 Anca Vamanu a...@opensips.org: Hi Olivier, First, please do not send email to me privately ( use reply all). Sorry about that, I did not see CC list, You are saying that the CANCEL send by b2b_entities does not have the exact ruri as INVITE? No I'm saying exactly the opposite, I know sip's RFC about CANCEL construction with INVITE header. But there a case, if B2B_entities communicates with another one, CANCEL is correctly sent to the second B2B_entities. Did you make some tests with 2 B2B face to face and try to: - CANCEL from a phone and propagate it correctly; - CANCEL from a B2B and propagate it to the callee phone; in this case, what is the best way: Send CANCEL on a side and send a 487 on the other side; or send CANCEL and wait 487 from the callee phone and propagate it to the caller phone ? Can you catch an INVITE and the corresponding CANCEL (send by b2b_entities) and send them in an e-mail? I don't have time to send it before after next week. I will come back to you after that and I will give you more information about SIP transmission, and what I am expected for my project. Regards, -- Olivier Détour ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
