[OpenSIPS-Users] Load balancer - how to not change origination ip
Gabriel Georgescu
gabrielgeo99 at gmail.com
Mon Jul 13 17:04:15 CEST 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opensips.zip
Type: application/zip
Size: 9539 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20090713/0cc5f2ec/attachment-0001.zip
More information about the Users
mailing list