[OpenSIPS-Users] hairpin and outside of dialog detection

[Bogdan-Andrei Iancu]

Hi Frank,

We can use get_dialog_info , but a bit hackish :)  - as the search is 
based on the values of the dlg vars, not on the callid (unless you go 
and add to each dialog a variable containing the callid :) )

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 24.05.2014 02:18, frank fox wrote:
> Thank you Bogdan for the reply.
>
> I am wondering if I can use the get_dialog__info somehow to find out 
> the original Invite (A) is sent back.
>
> I am still investigating if my SIP flow will always keep the contract 
> (with the VIA header solution).
>
> Is there any other modules or functions that I could possibly use?
>
> Thank you,
> Frank
>
> --- Original Message ---
>
> From: "Bogdan-Andrei Iancu" <bogdan at opensips.org>
> Sent: May 22, 2014 1:06 PM
> To: "frank fox" <franklyfox at outlook.com>, users at lists.opensips.org
> Subject: Re: hairpin and outside of dialog detection
>
> Hello Frank,
>
> Well, the match dialog does not work for this as the second INVITE is 
> not a sequential request, but an initial one (the dialog wise matching 
> is done only on the sequential requests).
>
> You can do the check by looking at the IPs in the VIA header, hoping 
> proxy2 is doing no topo hiding. So, when the call is back to proxy1, 
> the via[2] ip should belong to itself.
>
> Regards,
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
> On 20.05.2014 21:48, frank fox wrote:
>>
>> Greetings:
>>
>> I have a scenario as below:
>> Proxy-1 ---(A)---> Proxy-2
>>        <----(B)------------
>>
>> (A) := Initial Invite from proxy-1 to proxy-2
>> (B) := proxy-2 modifies the $rd and sends the initial Invite back to 
>> proxy-1
>>
>> Question:
>> How can the proxy-1 knows that the coming Invite was originally sent 
>> by itself?
>>
>> It seems the match_dialog() doesn't work for this situation:
>>
>> dialog::  hash=3514:62628069"7"
>>         state:: 2
>>         user_flags:: 65536
>>         timestart:: 0
>>         timeout:: 0
>>         callid:: a7ab8ff06766fabe1b4846712fba1051 at 10.242.65.162 
>> <mailto:a7ab8ff06766fabe1b4846712fba1051 at 10.242.65.162>
>>         from_uri:: sip:19905635611 at 10.242.65.162 
>> <mailto:sip:19905635611 at 10.242.65.162>
>>         to_uri:: sip:19905591214 at external-sip.vocalocity.com 
>> <mailto:sip:19905591214 at external-sip.vocalocity.com>
>>         caller_tag:: 14174341581400528279229
>>         caller_contact:: sip:19905635611 at 10.242.65.162:5060 
>> <mailto:sip:19905635611 at 10.242.65.162:5060>
>>         callee_cseq:: 0
>>         caller_route_set::
>>         caller_bind_addr:: udp:10.116.239.217:5060
>>         callee_tag:: 16423468221400528279248
>>         callee_contact::
>>            caller_cseq:: 102
>>         callee_route_set::
>>         callee_bind_addr:: udp:10.116.239.217:5060
>>
>>
>> dialog::  hash=3514:62628069"8"
>>         state:: 2
>>         user_flags:: 65536
>>         timestart:: 0
>>         timeout:: 0
>>         callid:: a7ab8ff06766fabe1b4846712fba1051 at 10.242.65.162 
>> <mailto:a7ab8ff06766fabe1b4846712fba1051 at 10.242.65.162>
>>         from_uri:: sip:19905635611 at 10.242.65.162 
>> <mailto:sip:19905635611 at 10.242.65.162>
>>         to_uri:: sip:19905591214 at external-sip.vocalocity.com 
>> <mailto:sip:19905591214 at external-sip.vocalocity.com>
>>         caller_tag:: 14174341581400528279229
>>         caller_contact::
>>         callee_cseq:: 0
>>         caller_route_set::
>>         caller_bind_addr:: udp:10.116.239.217:5060
>>         callee_tag:: 16423468221400528279248
>>         callee_contact::
>>         caller_cseq:: 102
>>         callee_route_set::
>>         callee_bind_addr:: udp:10.116.239.217:5060
>>
>>
>> Regards,
>> Frank
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140525/03ee7eb5/attachment.htm>