[OpenSIPS-Users] TopologyHiding in Dialog Module
Vlad Paiu
vladpaiu at opensips.org
Wed Apr 25 16:30:21 CEST 2012
Hello,
match_dialog() works at dialog level, while t_check_trans() works at
transaction level.
When you call match_dialog() on a sequential request within the dialog,
OpenSIPS will try to match the request to an already ongoing dialog in
the OpenSIPS memory. If it succeeds, further on in your script you will
have access to dialog related features.
t_check_trans() works differently, based on what type of request you are
handling. For CANCELs, it will return true if the INVITE transaction
exists for that CANCEL, for ACKs it will return true if it's an
end-to-end ACK for an INVITE transaction. Further more, for other
requests, t_check_trans() will check if there is already an ongoing
transaction, and thus the current request is a retransmission. In such a
case, your script execution will stop, as you do not normally want to
re-process retransmissions.
Regards,
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/25/2012 05:03 PM, Wilmar Campos wrote:
> Vlad, can you please explain the difference between match_dialog() and
> t_check_trans()? I have read the documentation but I still don't get it!
>
> Thank you,
>
> WC
>
> On Wed, Apr 25, 2012 at 4:44 AM, Vlad Paiu <vladpaiu at opensips.org
> <mailto:vladpaiu at opensips.org>> wrote:
>
> Hi,
>
> It seems you are looping the ACK over & over to yourself, so I
> think your sequential requests processing is wrong.
> For matching sequential requests within a topo hiding dialog, use
> the match_dialog() function [1] .
>
> [1] http://www.opensips.org/html/docs/modules/devel/dialog#id295095
>
>
> Regards,
>
> Vlad Paiu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> On 04/24/2012 08:17 PM, Wilmar Campos wrote:
>> Here are additional trace information of what I am seeing:
>>
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:rr:find_first_route: No Route headers found
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:rr:loose_route: There is no Route HF
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]: no loose
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> ERROR:siptrace:trace_dialog: failed to create dialog
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]: ack or
>> prack
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_headers: flags=78
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_lookup_request: start searching: hash=58803, isACK=1
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_headers: flags=38
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_to_param: tag=3544276353-446053
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_to: end of header reached, state=29
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_to: display={"Wilmar Campos"},
>> ruri={sip:12054 at x.x.x.101 <mailto:sip:12054 at x.x.x.101>}
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_lookup_request: REF_UNSAFE:[0xb4f2b744] after is 1
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_lookup_request: e2e proxy ACK found
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]: match
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> x.x.x.253 <null> is ACK relay
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_newtran: transaction on entrance=(nil)
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:parse_headers: flags=ffffffffffffffff
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_newtran: building branch for end2end ACK - flags=1
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:tm:t_relay_to: forwarding ACK
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:mk_proxy: doing DNS lookup...
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:check_ip_address: params x.x.x.253, x.x.x.253, 0
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:forward_request: sending:
>> Apr 24 13:12:42 prox-qos ACK: sip:x.x.x.253;did=c75.06cce112 SIP/2.0
>> Apr 24 13:12:42 prox-qos Max-Forwards: 47
>> Apr 24 13:12:42 prox-qos To: <sip:7917573108366435 at x.x.x.253>
>> <mailto:sip:7917573108366435 at x.x.x.253>;tag=c4d8a7fc-CC-33
>> Apr 24 13:12:42 prox-qos From: "Wilmar Campos"
>> <sip:12054 at x.x.x.101>
>> <mailto:sip:12054 at x.x.x.101>;tag=3544276353-446053
>> Apr 24 13:12:42 prox-qos Call-ID: 1351817-3544276353-446044 at nextone
>> Apr 24 13:12:42 prox-qos CSeq: 1 ACK
>> Apr 24 13:12:42 prox-qos Allow: INVITE, BYE, OPTIONS, CANCEL,
>> ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.253;branch=z9hG4bK3b5e.12d52d27.2
>> Apr 24 13:12:42 prox-qos Via: SIP/2.0/UDP
>> x.x.x.101:5060;branch=z9hG4bKde33285d3f6afec6b8ce5c7ef7f135e1
>> Apr 24 13:12:42 prox-qos Contact: <sip:12054 at x.x.x.101:5060>
>> <mailto:sip:12054 at x.x.x.101:5060>
>> Apr 24 13:12:42 prox-qos Content-Length: 0
>> Apr 24 13:12:42 prox-qos .:
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12526]:
>> DBG:core:forward_request: orig. len=1822, new_len=1884, proto=1
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_msg: SIP Request:
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_msg: method: <ACK>
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_msg: uri: <sip:x.x.x.253;did=c75.06cce112>
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_msg: version: <SIP/2.0>
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_headers: flags=2
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_to_param: tag=c4d8a7fc-CC-33
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_to: end of header reached, state=29
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_to: display={},
>> ruri={sip:7917573108366435 at x.x.x.253
>> <mailto:sip:7917573108366435 at x.x.x.253>}
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:get_hdr_field: <To> [57];
>> uri=[sip:7917573108366435 at x.x.x.253
>> <mailto:sip:7917573108366435 at x.x.x.253>]
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:get_hdr_field: to body [<sip:7917573108366435 at x.x.x.253>
>> <mailto:sip:7917573108366435 at x.x.x.253>]
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:get_hdr_field: cseq <CSeq>: <1> <ACK>
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_via_param: found param type 232, <branch> =
>> <z9hG4bK3b5e.12d52d27.2>; state=16
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_via: end of header reached, state=5
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_headers: via found, flags=2
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:parse_headers: this is the first via
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:receive_msg: After parse_msg...
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:core:receive_msg: preparing to run routing scripts...
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:sl:sl_filter_ACK: to late to be a local ACK!
>> Apr 24 13:12:42 prox-qos /usr/local/sbin/opensips[12528]:
>> DBG:maxfwd:is_maxfwd_present: value = 47
>>
>>
>>
>>
>> On Mon, Apr 23, 2012 at 4:41 AM, Vlad Paiu <vladpaiu at opensips.org
>> <mailto:vladpaiu at opensips.org>> wrote:
>>
>> Hello,
>>
>> Please post a full SIP trace of the dialog where the ACK is
>> not properly routed, as well as the OpenSIPS full debug log
>> for it.
>>
>> Regards,
>>
>> Vlad Paiu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 04/20/2012 09:11 PM, Wilmar Campos wrote:
>>> Hi to All,
>>> I hope everybody is well and ready for the weekend!
>>>
>>> In the last days I have been playing with the topologyhiding
>>> from the Dialog Module, I am using Opensips 1.8.0.
>>> When I dont use topology_hiding() all messages are
>>> transmited OK, but when I use it, all but the ACK messages
>>> are transmited, t_relay is executed but message is never
>>> delivered to the other party.
>>>
>>> Can you please point me to the right direction here.
>>>
>>> I am pretty sure I am detecting the ACK, also I am sure
>>> t_relay its been executed.
>>>
>>> Thank all for seeing this..
>>>
>>> --
>>> Wilmar Campos
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> --
>> Wilmar Campos
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> --
> Wilmar Campos
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120425/59e9d2a7/attachment-0001.htm>
More information about the Users
mailing list