[OpenSIPS-Users] Load balancer - how to not change origination ip
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Jul 21 11:53:21 CEST 2009
Hi Gabriel,
Sorry for delay.....I looked over your script and I think the CANCEL is
not properly handled . You have in script:
# handle cancel and re-transmissions
if ( !t_check_trans() ) {
if (is_method("CANCEL")){
xlog("Failure route 1 CANCEL $du - CHECK POINT\n");
# send("udp:$du:5060");
exit;
}
}
but it should be something like:
# handle cancel and re-transmissions
if ( t_check_trans() ) {
if (is_method("CANCEL")){
xlog("Failure route 1 CANCEL $du - CHECK POINT\n");
t_relay();
exit;
}
}
Regards,
Bogdan
Gabriel Georgescu wrote:
>
> Attached are the traces and the config files.
> The call originates from yyy.136.171.132, opensips runs load_balancer
> at xxx.121.254.18 and termination is one of the 3 gw's:
> xxx.121.254.201. xxx.121.254.202 or xxx.121.254.203.
> While call is ringing origination disconnects (CANCEL) but this has no
> effect on termination. Call is still ringing until is answered (as in
> the logs) or times out.
>
> Thanks for the answers,
> Gabriel
>
>
> At 03:32 PM 7/13/2009, Bogdan-Andrei Iancu wrote:
>> Salut Gabriel,
>>
>> Could you post SIP trace (ngrep from opensips server) and log
>> (debug=6) for the entire call (covering the INVITE + ringing + CANCEL) ?
>>
>> Regards,
>> Bogdan
>>
>>
>> Gabriel Georgescu wrote:
>>> Salutare Bogdan,
>>>
>>> I do exactly the tutorial routing. Yes there is a t_relay() at the
>>> end and one after loose_route().
>>> if (!has_totag()) {
>>> # initial request
>>> record_route();
>>> } else {
>>> # sequential request -> obey Route indication
>>> loose_route();
>>> t_relay();
>>> exit;
>>> }
>>>
>>> I checked on the termination windows machine and there is no CANCEL
>>> received when I call through opensips (and disconnect while ringing).
>>> But if I call directly to the windows machine the CANCEL is received
>>> and call disconnected.
>>>
>>> So the CANCEL arrives at opensips but is not forwarded to the
>>> termination.
>>> What am I missing? How should I catch this message and forward it?
>>>
>>> Thanks much,
>>> Gabi
>>>
>>>
>>> At 02:36 PM 7/9/2009, Bogdan-Andrei Iancu wrote:
>>>> Salut Gabriel,
>>>>
>>>> It looks like there is a problem in how you process the CANCEL - do
>>>> you do a t_relay() for the received CANCEL ? can you check this at
>>>> network level if the received CANCEL is actually sent out to the
>>>> callee part?
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Gabriel Georgescu wrote:
>>>>> Thank you for your advices!
>>>>>
>>>>> Regarding the second point I already have a record_route() like
>>>>> below which does not help to disconnect ringing calls:
>>>>> if (!has_totag()) {
>>>>> # initial request
>>>>> record_route();
>>>>> }
>>>>> I also tried like this without success:
>>>>>
>>>>> if
>>>>> (is_method("INVITE"))
>>>>>
>>>>> record_route();
>>>>> I wonder if the creator of the tutorial had same disconnect
>>>>> problems and how did he solved it...
>>>>>
>>>>> Looking into the trace there is a CANCEL received from softphone
>>>>> but it is not propagated to the destination server:
>>>>>
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:build_res_buf_from_sip_res: copied size: orig:108, new:
>>>>> 46, rest: 700 msg=#012SIP/2.0 183 Session Progress#015#012CSeq: 1
>>>>> INVITE#015#012Via: SIP/2.0/UDP
>>>>> 192.168.1.36:13308;received=X.136.171.132;branch=z9hG4bK-d8754z-317a22388e1b1a23-1---d8754z-;rport=61425#015#012From:
>>>>> "EyeBeamGG"<sip:Gabi at A.121.254.18>;tag=8a56554d#015#012Call-ID:
>>>>> YzE5NjRmMzY4YWVlZDJhMGU5MjdmZTlhNTgxY2MzN2M.#015#012To:
>>>>> "101"<sip:101 at A.121.254.18>;tag=0907290911276889507657541#015#012Contact:
>>>>> <sip:A.121.254.201:5060;transport=udp>#015#012Content-Type:
>>>>> application/sdp#015#012Content-Length: 229#015#012Record-Route:
>>>>> <sip:A.121.254.18;lr;ftag=8a56554d;did=0a8.698c41a>#015#012#015#012v=0#015#012o=VoipSwitch
>>>>> 8540 8540 IN IP4 A.121.254.201#015#012s=VoipSIP#015#012i=Audio
>>>>> Session#015#012c=IN IP4 A.121.254.201#015#012t=0 0#015#012m=audio
>>>>> 7540 RTP/AVP 18 101#015#012a=rtpmap:18
>>>>> G729/8000/1#015#012a=rtpmap:101
>>>>> telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:run_trans_callbacks: trans=0xb5c31df8, callback type 128,
>>>>> id 0 entered
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:dialog:next_state_dlg: dialog 0xb5c31c58 changed from state 2
>>>>> to state 2, due event 2
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:relay_reply: sent buf=0x816c2d8: SIP/2.0 1...,
>>>>> shmem=0xb5c344b8: SIP/2.0 1
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]: DBG:tm:set_timer:
>>>>> relative timeout is 120
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:insert_timer_unsafe: [1]: 0xb5c31f60 (200)
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]: DBG:tm:t_unref:
>>>>> UNREF_UNSAFE: after is 0
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>>> Jul 9 12:19:34 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:receive_msg: cleaning up
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_msg: SIP Request:
>>>>> *Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>>>> method: <CANCEL>
>>>>> *Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>>>> uri: <sip:101 at A.121.254.18>
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>>>> version: <SIP/2.0>
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: flags=2
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_via_param: found param type 232, <branch> =
>>>>> <z9hG4bK-d8754z-317a22388e1b1a23-1---d8754z->; state=6
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_via_param: found param type 235, <rport> = <n/a>;
>>>>> state=17
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_via: end of header reached, state=5
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: via found, flags=2
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: this is the first via
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:receive_msg: After parse_msg...
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:receive_msg: preparing to run routing scripts...
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: flags=100
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_to: end of header reached, state=10
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_to: display={"101"}, ruri={sip:101 at A.121.254.18}
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:get_hdr_field: <To> [30]; uri=[sip:101 at A.121.254.18]
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:get_hdr_field: to body ["101"<sip:101 at A.121.254.18>#015#012]
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:get_hdr_field: cseq <CSeq>: <1> <CANCEL>
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:get_hdr_field: content_length=0
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:get_hdr_field: found end of header
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:maxfwd:is_maxfwd_present: max_forwards header not found!
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:uri:has_totag: no totag
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_to_param: tag=8a56554d
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_to: end of header reached, state=29
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_to: display={"EyeBeamGG"},
>>>>> ruri={sip:Gabi at A.121.254.18}
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: flags=78
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:t_lookupOriginalT: searching on hash entry 18783
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:matching_3261: RFC3261 transaction matched,
>>>>> tid=-d8754z-317a22388e1b1a23-1---d8754z-
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:t_lookupOriginalT: canceled transaction found (0xb5c31df8)!
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:t_lookupOriginalT: REF_UNSAFE: after is 1
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:t_lookupOriginalT: t_lookupOriginalT completed
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:parse_headers: flags=ffffffffffffffff
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:check_via_address: params X.136.171.132, 192.168.1.36, 0
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:sl:run_sl_callbacks: callback id 0 entered
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:siptrace:trace_sl_onreply_out: trace off...
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:tm:t_unref_cell: UNREF_UNSAFE: after is 0
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>>> Jul 9 12:19:39 sippc /usr/sbin/opensips[32132]:
>>>>> DBG:core:receive_msg: cleaning up
>>>>>
>>>>>
>>>>> At 12:26 AM 7/9/2009, you wrote:
>>>>>> 2009/7/8 Gabriel Georgescu <gabrielgeo99 at gmail.com>:
>>>>>> > 1. the call arrives at the windows machine with the origination IP
>>>>>> > changed to the opensips ip, which makes billing impossible on
>>>>>> > windows. In my scenario opensips should only forward/distribute
>>>>>> calls
>>>>>> > in the simplest way without altering origination ip.
>>>>>> > Is there any method to forward the origination IP when doing
>>>>>> load_balance?
>>>>>>
>>>>>> That's impossible, but you can do 2 things if you're billing by
>>>>>> ip. Either:
>>>>>> - extract the original ip from the Via headers at the next hop, or
>>>>>> - do something like append_hf("Orig-IP", "$si"); to append the ip
>>>>>> as a
>>>>>> new header - the call may be a bit different - check the
>>>>>> documentation
>>>>>>
>>>>>> > 2. a ringing call is not disconnected if the origination party
>>>>>> hangs up.
>>>>>> > I think it misses a treatement for BYE sent from origination
>>>>>> > while call is in "connecting" state.
>>>>>> > Any clues how to correct this?
>>>>>>
>>>>>> Try adding record_route() on an INVITE packet - that way, the
>>>>>> rest of
>>>>>> the dialog will be passed through your proxy too.
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list