[OpenSER-Users] dp and dP pseudo-vars - sr-users - kamailio.org

List overview All Threads
Download

[OpenSER-Users] dp and dP pseudo-vars

[OpenSER-Users] Help Sending calls...

[OpenSER-Users] Reg. Proxy domains

Victor Gamov

24 Jan 2008 24 Jan '08

11:05 a.m.

Hi gentlemen! I use openser-1.2.2 and I want to access to dp & dP variables but sometimes they are empty. I try to access it before and after t_relay() and result is the same -- variable is empty. When this variables are set? Is it possible that they are not set at all? Thanks! -- CU, Victor Gamov

Reply

Show replies by date

Klaus Darilion

24 Jan 24 Jan

1 p.m.

Victor Gamov schrieb:

Hi gentlemen! I use openser-1.2.2 and I want to access to dp & dP variables but sometimes they are empty. I try to access it before and after t_relay() and result is the same -- variable is empty. When this variables are set?

Manually in openser.cfg or by some functions (e.g. lookup() or loose_route()).

Is it possible that they are not set at all?

yes. If openser forwards the request (e.g. t_relay) it verifies if DURI is set. If yes, the request is sent to the DURI. If DURI is not sent, the request is forwarded to the RURI. a typical example: client behind NAT register with Contact URI sip:192.168.2.2:5060. The request comes from 1.2.3.4:8888. Then during save openser will save the contact and the public address. Further, if you lookup() this user, the lookup function will set RURI to sip:192.168.2.2:5060 and duri to sip:1.2.3.4:8888 regards klaus

Reply

Victor Gamov

7:42 p.m.

Klaus Darilion wrote:

Victor Gamov schrieb:

Hi gentlemen! I use openser-1.2.2 and I want to access to dp & dP variables but sometimes they are empty. I try to access it before and after t_relay() and result is the same -- variable is empty. When this variables are set?

Manually in openser.cfg or by some functions (e.g. lookup() or loose_route()).

Is it possible that they are not set at all?

yes. If openser forwards the request (e.g. t_relay) it verifies if DURI is set. If yes, the request is sent to the DURI. If DURI is not sent, the request is forwarded to the RURI. a typical example: client behind NAT register with Contact URI sip:192.168.2.2:5060. The request comes from 1.2.3.4:8888. Then during save openser will save the contact and the public address. Further, if you lookup() this user, the lookup function will set RURI to sip:192.168.2.2:5060 and duri to sip:1.2.3.4:8888

I see. And in this situations $dP implicitly set to 'UDP' and $dp explicitly set to '8888', yes ? Another question: is it possible that t_relay() set this variables because t_relay() really know which $dP & $dp was used to send request. -- CU, Victor Gamov

Reply

Bogdan-Andrei Iancu

28 Jan 28 Jan

1:15 p.m.

Hi Victor, Victor Gamov wrote:

Klaus Darilion wrote:

Victor Gamov schrieb:

Hi gentlemen! I use openser-1.2.2 and I want to access to dp & dP variables but sometimes they are empty. I try to access it before and after t_relay() and result is the same -- variable is empty. When this variables are set?

Manually in openser.cfg or by some functions (e.g. lookup() or loose_route()).

Is it possible that they are not set at all?

yes. If openser forwards the request (e.g. t_relay) it verifies if DURI is set. If yes, the request is sent to the DURI. If DURI is not sent, the request is forwarded to the RURI. a typical example: client behind NAT register with Contact URI sip:192.168.2.2:5060. The request comes from 1.2.3.4:8888. Then during save openser will save the contact and the public address. Further, if you lookup() this user, the lookup function will set RURI to sip:192.168.2.2:5060 and duri to sip:1.2.3.4:8888

I see. And in this situations $dP implicitly set to 'UDP' and $dp explicitly set to '8888', yes ? Another question: is it possible that t_relay() set this variables because t_relay() really know which $dP & $dp was used to send request.

$dP and $dp are looking into destination uri ($du) which is an URI you set as outbound proxy. So t_relay() will not set this pvars. just to be clear, the variables do not contain information about where the message will be sent (at IP level), but where the message should be sent (outbound proxy). This is information passed to the t_relay() function and not information provided by t_relay(). Regards, Bogdan

Reply

Victor Gamov

31 Jan 31 Jan

11:19 a.m.

Bogdan-Andrei Iancu wrote:

Hi Victor, Victor Gamov wrote:

Klaus Darilion wrote:

Victor Gamov schrieb:

Hi gentlemen! I use openser-1.2.2 and I want to access to dp & dP variables but sometimes they are empty. I try to access it before and after t_relay() and result is the same -- variable is empty. When this variables are set?

Manually in openser.cfg or by some functions (e.g. lookup() or loose_route()).

Is it possible that they are not set at all?

yes. If openser forwards the request (e.g. t_relay) it verifies if DURI is set. If yes, the request is sent to the DURI. If DURI is not sent, the request is forwarded to the RURI. a typical example: client behind NAT register with Contact URI sip:192.168.2.2:5060. The request comes from 1.2.3.4:8888. Then during save openser will save the contact and the public address. Further, if you lookup() this user, the lookup function will set RURI to sip:192.168.2.2:5060 and duri to sip:1.2.3.4:8888

I see. And in this situations $dP implicitly set to 'UDP' and $dp explicitly set to '8888', yes ? Another question: is it possible that t_relay() set this variables because t_relay() really know which $dP & $dp was used to send request.

$dP and $dp are looking into destination uri ($du) which is an URI you set as outbound proxy. So t_relay() will not set this pvars. just to be clear, the variables do not contain information about where the message will be sent (at IP level), but where the message should be sent (outbound proxy). This is information passed to the t_relay() function and not information provided by t_relay().

So, there is no possibilities to get real proto/IP/port where message was sent. OK. But what about following feature request :-) http://sourceforge.net/tracker/index.php?func=detail&aid=1773214&gr… it can be extended to get per branch info about proto/IP/port -- CU, Victor Gamov

Reply

6140

days inactive

6147

days old

sr-users@lists.kamailio.org

Manage subscription

4 comments

3 participants

tags (0)

participants (3)

Bogdan-Andrei Iancu
Klaus Darilion
Victor Gamov