27 Mar
2007
27 Mar
'07
10:44 a.m.
Hi guys!
I have a question about "Proxy Route Processing"
I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of
this OpenSER):
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
From: "Vit-Horosho"
<sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
RAck: 1909013112 135588358 INVITE
CSeq: 135588359 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
Content-Length: 0
As we reading in RFC3261 "16.12 Summary of Proxy Route Processing" part:
1. Request-URI must be rewrited based on location service
2. Route header must be removed because it indicate this proxy
3. Proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value (but we have not this
Route after step 2) or in the Request-URI if no Route header field is
present (so it must be forwarded to URI getted on step 1)
But when I inspect OpenSER debug messages I found the following:
0(99796) parse_headers: flags=200
0(99796) is_preloaded: No
0(99796) grep_sock_info - checking if host==us: 11==11 &&
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
0(99796) grep_sock_info - checking if port 5060 matches port 5060
0(99796) after_strict: Next hop:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router
0(99796) parse_headers: flags=ffffffffffffffff
0(99796) rewrite_uri: Rewriting Request-URI with
'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) after_strict: The last route URI:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) parse_headers: flags=ffffffffffffffff
So request is not forwarded as I expect
Is it my misconfiguration or my misunderstood of RFC3261 ?
(the part of openser.cfg followed):
----------- cut here ----------------
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
#xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n");
# subsequent messages withing a dialog should take the
# path determined by record-routing
if ( loose_route() ) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
# route(1);
};
force_rport();
[ request processing with lookup() and actually route(1) followed ]
----------- /cut here ----------------
28 Mar
28 Mar
1:15 p.m.
Hi guys!
May be my previous message was some obscure. I'll try to make it clear.
I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of
this OpenSER):
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
From: "Vit-Horosho"
<sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
RAck: 1909013112 135588358 INVITE
CSeq: 135588359 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
Content-Length: 0
this message processed by OpenSER loose_route() and I found following
output in OpenSER debug:
0(99796) parse_headers: flags=200
0(99796) is_preloaded: No
0(99796) grep_sock_info - checking if host==us: 11==11 &&
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
0(99796) grep_sock_info - checking if port 5060 matches port 5060
0(99796) after_strict: Next hop:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router
0(99796) parse_headers: flags=ffffffffffffffff
0(99796) rewrite_uri: Rewriting Request-URI with
'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) after_strict: The last route URI:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) parse_headers: flags=ffffffffffffffff
It's strange for me why loose_route() change Request-URI with values
from Route. As I red at RFC3261 "16.12 Summary of Proxy Route
Processing" part (with my comments):
1. Request-URI must be rewrited based on location service (it will be
done after loose_route)
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (in my case Route must be removed because it
indicate this proxy)
3. Proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value (but we have not
this Route after step 2) or in the Request-URI if no Route header
field is present (so it must be forwarded to URI getted on step 1)
So my question:
Is it my misconfiguration and I must call loose_route() not for all
requests coming to my proxy or my misunderstood of RFC3261 ?
(the part of openser.cfg is followed):
----------- cut here ----------------
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
#xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n");
# subsequent messages withing a dialog should take the
# path determined by record-routing
if ( loose_route() ) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
# route(1);
};
force_rport();
Thanks for advise!
--
CU,
Victor Gamov
1:19 p.m.
Does xxx.xxx.xx.xx mean always the same IP address? Then Route header IP
address and From and To would be identical. That would be a bug.
Thus, if you replace IP addresses make sure you replace them different.
e.g. use "proxy.ip" and "gateway.ip" and "client.ip" as
placeholder.
regards
klaus
Victor Gamov wrote:
Hi guys!
May be my previous message was some obscure. I'll try to make it clear.
I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of
this OpenSER):
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes
SIP/2.0
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
From: "Vit-Horosho"
<sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
RAck: 1909013112 135588358 INVITE
CSeq: 135588359 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
Content-Length: 0
this message processed by OpenSER loose_route() and I found following
output in OpenSER debug:
0(99796) parse_headers: flags=200
0(99796) is_preloaded: No
0(99796) grep_sock_info - checking if host==us: 11==11 &&
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
0(99796) grep_sock_info - checking if port 5060 matches port 5060
0(99796) after_strict: Next hop:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router
0(99796) parse_headers: flags=ffffffffffffffff
0(99796) rewrite_uri: Rewriting Request-URI with
'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) after_strict: The last route URI:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) parse_headers: flags=ffffffffffffffff
It's strange for me why loose_route() change Request-URI with values
from Route. As I red at RFC3261 "16.12 Summary of Proxy Route
Processing" part (with my comments):
1. Request-URI must be rewrited based on location service (it will be
done after loose_route)
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (in my case Route must be removed because it
indicate this proxy)
3. Proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value (but we have not
this Route after step 2) or in the Request-URI if no Route header
field is present (so it must be forwarded to URI getted on step 1)
So my question:
Is it my misconfiguration and I must call loose_route() not for all
requests coming to my proxy or my misunderstood of RFC3261 ?
(the part of openser.cfg is followed):
----------- cut here ----------------
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
#xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n");
# subsequent messages withing a dialog should take the
# path determined by record-routing
if ( loose_route() ) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
# route(1);
};
force_rport();
Thanks for advise!
--
CU,
Victor Gamov
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:57 p.m.
Klaus Darilion wrote:
Does xxx.xxx.xx.xx mean always the same IP address?
Then Route header IP
address and From and To would be identical. That would be a bug.
Yes it's a same IP.
But why it a bug? I have two clients using the same OpenSER with address
XXX.XXX.XXX.XXX. Both clients use this IP as a "SIP proxy" parameter in
their equipments and use this address as domain of their AOR
I still confused with loose_route() behavior: why it use first and
single Route header previously placed by this proxy as route-decision
element? I hope that this Route must be deleted and R-RURI will be used
to make lookup() request.
BTW: packet in my example coming from ngrep not from OpenSER debug. So
it packet really getted by OpenSER for future processing.
Thus, if you replace IP addresses make sure you
replace them different.
e.g. use "proxy.ip" and "gateway.ip" and "client.ip" as
placeholder.
regards
klaus
Victor Gamov wrote:
> Hi guys!
>
> May be my previous message was some obscure. I'll try to make it clear.
>
> I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of
> this OpenSER):
>
>> PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
>> Via: SIP/2.0/UDP
>> 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
>> From: "Vit-Horosho"
>> <sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
>> To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
>> Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
>> RAck: 1909013112 135588358 INVITE
>> CSeq: 135588359 PRACK
>> Contact: <sip:vit-horosho@192.168.100.77:5060>
>> Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
>> Content-Length: 0
>
> this message processed by OpenSER loose_route() and I found following
> output in OpenSER debug:
>
>> 0(99796) parse_headers: flags=200
>> 0(99796) is_preloaded: No
>> 0(99796) grep_sock_info - checking if host==us: 11==11 &&
>> [xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
>> 0(99796) grep_sock_info - checking if port 5060 matches port 5060
>> 0(99796) after_strict: Next hop:
>> 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose
>> router
>> 0(99796) parse_headers: flags=ffffffffffffffff
>> 0(99796) rewrite_uri: Rewriting Request-URI with
>> 'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
>> 0(99796) after_strict: The last route URI:
>> 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
>> 0(99796) parse_headers: flags=ffffffffffffffff
>
> It's strange for me why loose_route() change Request-URI with values
> from Route. As I red at RFC3261 "16.12 Summary of Proxy Route
> Processing" part (with my comments):
>
> 1. Request-URI must be rewrited based on location service (it will be
> done after loose_route)
> 2. The proxy will inspect the URI in the topmost Route header
> field value. If it indicates this proxy, the proxy removes it
> from the Route header field (in my case Route must be removed because
> it indicate this proxy)
> 3. Proxy will forward the request to the resource indicated
> by the URI in the topmost Route header field value (but we have not
> this Route after step 2) or in the Request-URI if no Route header
> field is present (so it must be forwarded to URI getted on step 1)
>
>
> So my question:
> Is it my misconfiguration and I must call loose_route() not for all
> requests coming to my proxy or my misunderstood of RFC3261 ?
>
> (the part of openser.cfg is followed):
> >
> > ----------- cut here ----------------
> >
> > # we record-route all messages -- to make sure that
> > # subsequent messages will go through our proxy; that's
> > # particularly good if upstream and downstream entities
> > # use different transport protocol
> > record_route();
> >
> > #xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n");
> > # subsequent messages withing a dialog should take the
> > # path determined by record-routing
> > if ( loose_route() ) {
> > # mark routing logic in request
> > append_hf("P-hint: rr-enforced\r\n");
> > # route(1);
> > };
> >
> > force_rport();
>
> Thanks for advise!
>
> --
> CU,
> Victor Gamov
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
--
CU,
Victor Gamov
29 Mar
29 Mar
9:21 a.m.
The PRACK is an in-dialog request. There is no need to lookup() for
in-dialog requests as the route and the destination are already known.
In your case the PRACK looks buggy, as the IP address in the RURI is the
same as the IP address in the Route header. For loose-router in-dialog
requests the RURI must be the destination SIP URI (the URI in the
Contact: header of the INVITE) - and this URI can't be the IP address of
the proxy but must be the IP address of the caller.
If you want the whole truth you have to read RFC 3261. (in dialog
requests and loose-routing)
regards
klaus
Victor Gamov wrote:
Klaus Darilion wrote:
Does xxx.xxx.xx.xx mean always the same IP
address? Then Route header
IP address and From and To would be identical. That would be a bug.
Yes it's a same IP.
But why it a bug? I have two clients using the same OpenSER with address
XXX.XXX.XXX.XXX. Both clients use this IP as a "SIP proxy" parameter in
their equipments and use this address as domain of their AOR
I still confused with loose_route() behavior: why it use first and
single Route header previously placed by this proxy as route-decision
element? I hope that this Route must be deleted and R-RURI will be used
to make lookup() request.
BTW: packet in my example coming from ngrep not from OpenSER debug. So
it packet really getted by OpenSER for future processing.
Thus, if you replace IP addresses make sure you
replace them different.
e.g. use "proxy.ip" and "gateway.ip" and "client.ip" as
placeholder.
regards
klaus
Victor Gamov wrote:
> Hi guys!
>
> May be my previous message was some obscure. I'll try to make it clear.
>
> I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of
> this OpenSER):
>
>> PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
>> Via: SIP/2.0/UDP
>> 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
>> From: "Vit-Horosho"
>> <sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
>> To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
>> Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
>> RAck: 1909013112 135588358 INVITE
>> CSeq: 135588359 PRACK
>> Contact: <sip:vit-horosho@192.168.100.77:5060>
>> Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
>> Content-Length: 0
>
> this message processed by OpenSER loose_route() and I found following
> output in OpenSER debug:
>
>> 0(99796) parse_headers: flags=200
>> 0(99796) is_preloaded: No
>> 0(99796) grep_sock_info - checking if host==us: 11==11 &&
>> [xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
>> 0(99796) grep_sock_info - checking if port 5060 matches port 5060
>> 0(99796) after_strict: Next hop:
>> 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose
>> router
>> 0(99796) parse_headers: flags=ffffffffffffffff
>> 0(99796) rewrite_uri: Rewriting Request-URI with
>> 'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
>> 0(99796) after_strict: The last route URI:
>> 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
>> 0(99796) parse_headers: flags=ffffffffffffffff
>
> It's strange for me why loose_route() change Request-URI with values
> from Route. As I red at RFC3261 "16.12 Summary of Proxy Route
> Processing" part (with my comments):
>
> 1. Request-URI must be rewrited based on location service (it will be
> done after loose_route)
> 2. The proxy will inspect the URI in the topmost Route header
> field value. If it indicates this proxy, the proxy removes it
> from the Route header field (in my case Route must be removed because
> it indicate this proxy)
> 3. Proxy will forward the request to the resource indicated
> by the URI in the topmost Route header field value (but we have not
> this Route after step 2) or in the Request-URI if no Route header
> field is present (so it must be forwarded to URI getted on step 1)
>
>
> So my question:
> Is it my misconfiguration and I must call loose_route() not for all
> requests coming to my proxy or my misunderstood of RFC3261 ?
>
> (the part of openser.cfg is followed):
> >
> > ----------- cut here ----------------
> >
> > # we record-route all messages -- to make sure that
> > # subsequent messages will go through our proxy; that's
> > # particularly good if upstream and downstream entities
> > # use different transport protocol
> > record_route();
> >
> > #xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n");
> > # subsequent messages withing a dialog should take the
> > # path determined by record-routing
> > if ( loose_route() ) {
> > # mark routing logic in request
> > append_hf("P-hint: rr-enforced\r\n");
> > # route(1);
> > };
> >
> > force_rport();
>
> Thanks for advise!
>
> --
> CU,
> Victor Gamov
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
30 Mar
30 Mar
11:19 p.m.
Klaus Darilion wrote:
Hi Klaus!
The PRACK is an in-dialog request. There is no need to
lookup() for
in-dialog requests as the route and the destination are already known.
In your case the PRACK looks buggy, as the IP address in the RURI is the
same as the IP address in the Route header. For loose-router in-dialog
requests the RURI must be the destination SIP URI (the URI in the
Contact: header of the INVITE) -
Yes this R-URI coming from INVITE Contact: header
and this URI can't be the IP address of
the proxy but must be the IP address of the caller.
Very strange assertion. If I follow this logic then I cann't start SIP
client on the same IP-address as SIP-proxy.
If you want the whole truth you have to read RFC 3261.
(in dialog
requests and loose-routing)
I reread this (not simple) RFC periodically :-)
Now I look into issue 12 and 16 and I not found nothing wrong in request
from my clients.
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
From: "Vit-Horosho"
<sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
RAck: 1909013112 135588358 INVITE
CSeq: 135588359 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
Content-Length: 0
Now I'll explain my point of view.
As I reading in loose_route() documentation:
"The loose_route function analyzes the Route: headers in the requests.
If there is no Route: header, the function returns FALSE and routing
should be done with normal lookup functions. If a Route: header is
found, the function returns 1 and behaves as described in section 16.12
of RFC 3261."
When we looking into 16.12 we found that
"1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI."
OK. sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes is R-URI owned by this proxy.
So I can do lookup() or other my own transformation on it (really I do
this transformations after loose_route() ).
"2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached)."
Yes, the topmost Route header indicates this proxy. So proxy must remove
it simply. But at this point loose_route() rewrite R-URI:
0(99796) parse_headers: flags=200
0(99796) is_preloaded: No
0(99796) grep_sock_info - checking if host==us: 11==11 &&
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
0(99796) grep_sock_info - checking if port 5060 matches port 5060
0(99796) after_strict: Next hop:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router
0(99796) parse_headers: flags=ffffffffffffffff
0(99796) rewrite_uri: Rewriting Request-URI with
'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) after_strict: The last route URI:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) parse_headers: flags=ffffffffffffffff
But why?
Moreover, if loose_route() does not find that this Route indicate this
proxy why it changes R-URI? The Route value have lr=on parameter and
this must be treated as loose-route proxy.
May be I don't understand loose_route() properly and I don't must use it
for all requests coming to my proxy?
Or may be I still don't understand RFC properly?
Thanks!
P.S. I remove loose_route() from config and everything works OK.
--
CU,
Victor Gamov
18 Apr
18 Apr
11:59 a.m.
Victor Gamov wrote:
Klaus Darilion wrote:
Hi Klaus!
You are starting the SIP client on the same PC as the SIP proxy? Then of
course it is valid. I was thinking that the SIP client will have another
IP address.
btw: is the problem solved now?
regards
klaus
The PRACK is an in-dialog request. There is no
need to lookup() for
in-dialog requests as the route and the destination are already known.
In your case the PRACK looks buggy, as the IP address in the RURI is
the same as the IP address in the Route header. For loose-router
in-dialog requests the RURI must be the destination SIP URI (the URI
in the Contact: header of the INVITE) -
Yes this R-URI coming from INVITE Contact: header
and this URI can't be the IP address of the
proxy but must be the IP
address of the caller.
Very strange assertion. If I follow this logic then I cann't start SIP
client on the same IP-address as SIP-proxy. If you want the whole truth you have to read RFC
3261. (in dialog
requests and loose-routing)
I reread this (not simple) RFC periodically :-)
Now I look into issue 12 and 16 and I not found nothing wrong in request
from my clients.
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A
From: "Vit-Horosho"
<sip:vit-horosho@xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
To: <sip:1111@xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
Call-ID: CALL_ID3_00179A52BC45_T2098965184(a)192.168.100.77
RAck: 1909013112 135588358 INVITE
CSeq: 135588359 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222>
Content-Length: 0
Now I'll explain my point of view.
As I reading in loose_route() documentation:
"The loose_route function analyzes the Route: headers in the requests.
If there is no Route: header, the function returns FALSE and routing
should be done with normal lookup functions. If a Route: header is
found, the function returns 1 and behaves as described in section 16.12
of RFC 3261."
When we looking into 16.12 we found that
"1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI."
OK. sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes is R-URI owned by this proxy.
So I can do lookup() or other my own transformation on it (really I do
this transformations after loose_route() ).
"2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached)."
Yes, the topmost Route header indicates this proxy. So proxy must remove
it simply. But at this point loose_route() rewrite R-URI:
0(99796) parse_headers: flags=200
0(99796) is_preloaded: No
0(99796) grep_sock_info - checking if host==us: 11==11 &&
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
0(99796) grep_sock_info - checking if port 5060 matches port 5060
0(99796) after_strict: Next hop:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router
0(99796) parse_headers: flags=ffffffffffffffff
0(99796) rewrite_uri: Rewriting Request-URI with
'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) after_strict: The last route URI:
'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222'
0(99796) parse_headers: flags=ffffffffffffffff
But why?
Moreover, if loose_route() does not find that this Route indicate this
proxy why it changes R-URI? The Route value have lr=on parameter and
this must be treated as loose-route proxy.
May be I don't understand loose_route() properly and I don't must use it
for all requests coming to my proxy?
Or may be I still don't understand RFC properly?
Thanks!
P.S. I remove loose_route() from config and everything works OK.
10:30 p.m.
Klaus Darilion wrote:
Victor Gamov wrote:
Still no.
I remove loose_route() from my config and everything works fine.
So I still think that I have some misunderstanding of loose_route()
logic. Or I still needed to reread 3261 again :-)
--
CU,
Victor Gamov
Klaus Darilion wrote:
Hi Klaus!
You are starting the SIP client on the same PC as the SIP proxy? Then of
course it is valid. I was thinking that the SIP client will have another
IP address.
btw: is the problem solved now? The PRACK is an in-dialog request. There is no
need to lookup() for
in-dialog requests as the route and the destination are already known.
In your case the PRACK looks buggy, as the IP address in the RURI is
the same as the IP address in the Route header. For loose-router
in-dialog requests the RURI must be the destination SIP URI (the URI
in the Contact: header of the INVITE) -
Yes this R-URI coming from INVITE Contact: header
and this URI can't be the IP address of the
proxy but must be the IP
address of the caller.
Very strange assertion. If I follow this logic then I cann't start SIP
client on the same IP-address as SIP-proxy.
19 Apr
19 Apr
8:43 a.m.
Victor Gamov wrote:
I would rather think that one of the SIP clients is buggy - which is
usually the case.
regards
klaus
btw: is the
problem solved now?
Still no.
I remove loose_route() from my config and everything works fine.
So I still think that I have some misunderstanding of loose_route()
logic. Or I still needed to reread 3261 again :-) 
1:38 p.m.
New subject: [Users] Problem with rewriting URI
Hi,
For making a dialplan in 2 or many openser, I try fonction
rewritehost("domain.com") for override a default request URI from Client
softphone, the RURI change but the to URI still the same
if (uri=~"sip:77[1-9][0-9]+@.*")
rewritehost("domain.mg");
Openser 1
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp F=sip:user2@domain.org
T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
After :
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp F=sip:user2@domain.org
T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
Openser 2:
New request - M=INVITE RURI=sip:7722@domain.mg;transport=tcp F=sip:tvm_user2@domain.org
T=sip:7722@domain.org IP=192.168.80.254
ID=ef6a5b0a6d73c925N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
And the dial is not fully a success,it can ring but when i terminated a call the callee is
hang up !!
How solve this problem for a dial plan?
Thanks.
Regards,
Tsitsi
---------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez
des connaissances, des opinions et des expériences des internautes sur Yahoo!
Questions/Réponses.
1:45 p.m.
New subject: [Users] Problem with rewriting URI
Hello.
On 04/19/07 14:38, Tsitsi wrote:
Hi,
For making a dialplan in 2 or many openser, I try fonction
rewritehost("domain.com") for override a default request URI
from Client softphone, the RURI change but the to URI still the same
I don't
get it exactly -- can you detail a bit? rewritehost("domain.mg")
rewrite the R-URI. What do you mean tha "but the URI still the same"?
Cheers,
Daniel
if (uri=~"sip:77[1-9][0-9]+@.*")
rewritehost("domain.mg");
Openser 1
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
After :
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
Openser 2:
New request - M=INVITE RURI=sip:7722@domain.mg;transport=tcp
F=sip:tvm_user2@domain.org T=sip:7722@domain.org IP=192.168.80.254
ID=ef6a5b0a6d73c925N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
And the dial is not fully a success,it can ring but when i terminated
a call the callee is hang up !!
How solve this problem for a dial plan?
Thanks.
Regards,
Tsitsi
------------------------------------------------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos
questions ! Profitez des connaissances, des opinions et des
expériences des internautes sur Yahoo! Questions/Réponses
<http://fr.rd.yahoo.com/evt=42054/*http://fr.answers.yahoo.com>.
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2:10 p.m.
New subject: RE : Re: [Users] Problem with rewriting URI
Hi Daniel,
I want to rewrite the default domain added by UA (the local domain), I use
rewritehost("domain.com") for rewriting a the uri request like user1(a)domain.org
and it will become user1(a)domain.com and the request can be reply for another sip proxy
(domain.com) instead the local domain(domain.org) .
After this fonction rewritehost() the part the domain of URI request change but the To URI
request ( eg. To: user1(a)domain.com) does not change in the SIP request.
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
After rewriting:
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
RURI=sip:7722@domain.com: Request URI
T=sip:7722@domain.org : To URI
Thanks,
Regards,
Tsitsi
Daniel-Constantin Mierla <daniel(a)voice-system.ro> a écrit : Hello.
On 04/19/07 14:38, Tsitsi wrote:
Hi,
For making a dialplan in 2 or many openser, I try fonction
rewritehost("domain.com") for override a default request URI
from Client softphone, the RURI change but the to URI still the same
I don't
get it exactly -- can you detail a bit? rewritehost("domain.mg")
rewrite the R-URI. What do you mean tha "but the URI still the same"?
Cheers,
Daniel
if (uri=~"sip:77[1-9][0-9]+@.*")
rewritehost("domain.mg");
Openser 1
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
After :
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
Openser 2:
New request - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:tvm_user2@domain.org T=sip:7722@domain.org IP=192.168.80.254
ID=ef6a5b0a6d73c925N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
And the dial is not fully a success,it can ring but when i terminated
a call the callee is hang up !!
How solve this problem for a dial plan?
Thanks.
Regards,
Tsitsi
------------------------------------------------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos
questions ! Profitez des connaissances, des opinions et des
expériences des internautes sur Yahoo! Questions/Réponses
.
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
---------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez
des connaissances, des opinions et des expériences des internautes sur Yahoo!
Questions/Réponses.
20 Apr
20 Apr
3:42 p.m.
New subject: [Users] Problem with rewriting URI
Hi,
Is it possible? I want to make a dial plan like this :
From domain.org (match 77)
calling
7722(a)domain.org --> calling 7722(a)domain.com
From domain.com (match 55)
calling
5537(a)domain.com --> calling 5537(a)domain.org
if not match it's a local call.
Thanks
Regards,
Tsitsi
Tsitsi <mediatsitsi-ser(a)yahoo.fr> a écrit : Hi Daniel,
I want to rewrite the default domain added by UA (the local domain), I use
rewritehost("domain.com") for rewriting a the uri request like user1(a)domain.org
and it will become user1(a)domain.com and the request can be reply for another sip proxy
(domain.com) instead the local domain(domain.org) .
After this fonction rewritehost() the part the domain of URI request change but the To URI
request ( eg. To: user1(a)domain.com) does not change in the SIP request.
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
After rewriting:
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
RURI=sip:7722@domain.com: Request URI
T=sip:7722@domain.org : To URI
Thanks,
Regards,
Tsitsi
Daniel-Constantin Mierla <daniel(a)voice-system.ro> a écrit : Hello.
On 04/19/07 14:38, Tsitsi wrote:
Hi,
For making a dialplan in 2 or many openser, I try fonction
rewritehost("domain.com") for override a default request URI
from Client softphone, the RURI change but the to URI still the same
I don't
get it exactly -- can you detail a bit? rewritehost("domain.mg")
rewrite the R-URI. What do you mean tha "but the URI still the same"?
Cheers,
Daniel
if (uri=~"sip:77[1-9][0-9]+@.*")
rewritehost("domain.mg");
Openser 1
Before :
New request - M=INVITE RURI=sip:7722@domain.org;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
After :
Rewrite!!! - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:user2@domain.org T=sip:7722@domain.org IP=192.168.80.222
ID=771b514742765432N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
Openser 2:
New request - M=INVITE RURI=sip:7722@domain.com;transport=tcp
F=sip:tvm_user2@domain.org T=sip:7722@domain.org IP=192.168.80.254
ID=ef6a5b0a6d73c925N2I0ZTAwZTMzZmE1ZGUwYjc4MWNhYTM3NTA3N2RjNWY.
And the dial is not fully a success,it can ring but when i terminated
a call the callee is hang up !!
How solve this problem for a dial plan?
Thanks.
Regards,
Tsitsi
------------------------------------------------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos
questions ! Profitez des connaissances, des opinions et des
expériences des internautes sur Yahoo! Questions/Réponses
.
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
---------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo!
Questions/Réponses._______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
---------------------------------
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez
des connaissances, des opinions et des expériences des internautes sur Yahoo!
Questions/Réponses.
19 Apr
19 Apr
10:24 p.m.
Hi gentlemen!
Sorry for my perseverance but I'll try to ask my question one more time.
I have following SIP-network configuration
Term=192.168.100.77 <-> NAT=Y.Y.Y.Y <-> OpenSER=X.X.X.X <-> GW=Z.Z.Z.Z
Term uses X.X.X.X as registrar and outbound proxy. It registered on
OpenSER as "vit-horosho(a)X.X.X.X".X.X". GW is gateway connected to POTS.
Then I make call from Term to POTS number 74951000000.
'ngrep SIP port 5060' output from OpenSER machine followed (I strip some
unimportant info from requests. My comments before requests)
Initial request from Term comes to OpenSER:
U Y.Y.Y.Y:60767 -> X.X.X.X:5060
INVITE sip:74951000000@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@192.168.100.77:5060>
OK. OpenSER send prov. reply to Term:
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Content-Length: 0
Then I make my own transformations on Contact: header and OpenSER resend
request to GW. OpenSER adds Record-Route: header into request also.
U X.X.X.X:5060 -> Z.Z.Z.Z:5060
INVITE sip:74951000000@Z.Z.Z.Z;user=phone SIP/2.0
Record-Route: <sip:X.X.X.X;lr=on;
ftag=00179A52BC45_T1011336699>
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0
Via: SIP/2.0/UDP 192.168.100.77:5060;rport=60767;received=
Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@80.23 7.15.3>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265@
192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@X.X.X.X;nat=yes>
OK. GW send prov. reply to OpenSER
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767
;received=Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:57 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
OK. OpenSER resend prov. reply to Term
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
GW send 183 to OpenSER. Record-Route: header present in this reply.
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767;received=Y.Y.Y.Y;
branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:58 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
Server: Cisco-SIPGateway/IOS-12.x..
CSeq: 397703138 INVITE
RSeq: 3722
Contact: <sip:74951000000@Z.Z.Z.Z:5060>
Record-Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
OpenSER make my own transformation on Contact: header and resend 183 to
Term.
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.100.77:5060;rport=60767;
received=Y.Y.Y.Y;
branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:58 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRAC
K, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Require: 100rel
RSeq: 3722
Record-Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
Contact: <sip:74951000000@X.X.X.X:5060;nat=yes>
Term try to send PRACK to GW. It sets RURI to value getted from Contact:
header of 183 reply. It adds Route: getted from Term's route set (comes
from 183) also. So PRACK getted by OpenSER:
U Y.Y.Y.Y:60767 -> X.X.X.X:5060
PRACK sip:74951000000@X.X.X.X:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;
branch=z9hG4bK_00179A52BC45_T16F15B76
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
RAck: 3722 397703138 INVITE
CSeq: 397703139 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
And I have misunderstood at this point. I use following logic in my
openser.cfg:
route {
...
record_route();
if ( loose_route() ) {
append_hf("P-hint: rr-enforced\r\n");
# we don't call route(1) here -- we need to process all requests later
}
# main request process logic followed
...
}
and I found the following in my debug:
0(41063) after_strict: Next hop:
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699' is loose router
0(41063) parse_headers: flags=ffffffffffffffff
0(41063) rewrite_uri: Rewriting Request-URI with
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699'
0(41063) after_strict: The last route URI:
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699'
0(41063) parse_headers: flags=ffffffffffffffff
As I founded in RFC-3261 section 16.12:
"1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached)."
So my question:
why loose_route() don't treat PRACK RURI
sip:74951000000@X.X.X.X:5060;nat=yes
as resource owned by this proxy and rewrite it with Route: header URI
sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699 ?
--
CU,
Victor Gamov
20 Apr
20 Apr
8:15 a.m.
Victor Gamov wrote:
Hi gentlemen!
Sorry for my perseverance but I'll try to ask my question one more time.
I have following SIP-network configuration
Term=192.168.100.77 <-> NAT=Y.Y.Y.Y <-> OpenSER=X.X.X.X <-> GW=Z.Z.Z.Z
Term uses X.X.X.X as registrar and outbound proxy. It registered on
OpenSER as "vit-horosho(a)X.X.X.X".X.X". GW is gateway connected to POTS.
Then I make call from Term to POTS number 74951000000.
'ngrep SIP port 5060' output from OpenSER machine followed (I strip some
unimportant info from requests. My comments before requests)
Initial request from Term comes to OpenSER:
U Y.Y.Y.Y:60767 -> X.X.X.X:5060
INVITE sip:74951000000@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@192.168.100.77:5060>
OK. OpenSER send prov. reply to Term:
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Content-Length: 0
Then I make my own transformations on Contact: header
Why are you replacing the Contact with the IP address of the proxy?
There is no need to do that. If you want NAT traversal use
fix_nated_contact().
and OpenSER resend
request to GW. OpenSER adds Record-Route: header into
request also.
U X.X.X.X:5060 -> Z.Z.Z.Z:5060
INVITE sip:74951000000@Z.Z.Z.Z;user=phone SIP/2.0
Record-Route: <sip:X.X.X.X;lr=on;
ftag=00179A52BC45_T1011336699>
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0
Via: SIP/2.0/UDP 192.168.100.77:5060;rport=60767;received=
Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@80.23 7.15.3>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265@
192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@X.X.X.X;nat=yes>
OK. GW send prov. reply to OpenSER
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767
;received=Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:57 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
OK. OpenSER resend prov. reply to Term
Why does openser resend the 100? I have never seen this before.
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
GW send 183 to OpenSER. Record-Route: header present in this reply.
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767;received=Y.Y.Y.Y;
branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:58 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
Server: Cisco-SIPGateway/IOS-12.x..
CSeq: 397703138 INVITE
RSeq: 3722
Contact: <sip:74951000000@Z.Z.Z.Z:5060>
Record-Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
OpenSER make my own transformation on Contact: header
This is the root of your problem. By rewriting the Contact header with
the IP address of the proxy you are not standard conform. Thus, the
loose routing of in-dialog messages can not work anymore, as the Contact
must be the address of the client, not the proxy.
Stop manipulating the Contact header and you will see that loose routing
will work fine.
regards
klaus
and resend 183 to
Term.
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.100.77:5060;rport=60767;
received=Y.Y.Y.Y;
branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:58 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRAC
K, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Require: 100rel
RSeq: 3722
Record-Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
Contact: <sip:74951000000@X.X.X.X:5060;nat=yes>
Term try to send PRACK to GW. It sets RURI to value getted from Contact:
header of 183 reply. It adds Route: getted from Term's route set (comes
from 183) also. So PRACK getted by OpenSER:
U Y.Y.Y.Y:60767 -> X.X.X.X:5060
PRACK sip:74951000000@X.X.X.X:5060;nat=yes SIP/2.0
Via: SIP/2.0/UDP 192.168.100.77:5060;
branch=z9hG4bK_00179A52BC45_T16F15B76
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
RAck: 3722 397703138 INVITE
CSeq: 397703139 PRACK
Contact: <sip:vit-horosho@192.168.100.77:5060>
Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
And I have misunderstood at this point. I use following logic in my
openser.cfg:
route {
...
record_route();
if ( loose_route() ) {
append_hf("P-hint: rr-enforced\r\n");
# we don't call route(1) here -- we need to process all requests later
}
# main request process logic followed
...
}
and I found the following in my debug:
0(41063) after_strict: Next hop:
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699' is loose router
0(41063) parse_headers: flags=ffffffffffffffff
0(41063) rewrite_uri: Rewriting Request-URI with
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699'
0(41063) after_strict: The last route URI:
'sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699'
0(41063) parse_headers: flags=ffffffffffffffff
As I founded in RFC-3261 section 16.12:
"1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached)."
So my question:
why loose_route() don't treat PRACK RURI
sip:74951000000@X.X.X.X:5060;nat=yes
as resource owned by this proxy and rewrite it with Route: header URI
sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699 ?
2:12 p.m.
Klaus Darilion wrote:
Hm. Which part of standard is breakup by this rewriting?
Victor Gamov wrote:
fix_nated_contact() does not work correctly (I try it some times ago for
1.1.0). In this scenario it changes Term IP=192.168.100.77 with NAT
IP=Y.Y.Y.Y and NAT port=60767. So when request sending to Term then
Proxy rewrite RURI to termuser@192.168.100.77:60767 and send it to
Y.Y.Y.Y:60767
NAT send UDP-packet to Term 192.168.100.77 port 5060 (it's known because
NAT logic) and Term will reply "No such transaction" or "No such user"
(sorry I don't remember it now) because Term really don't know anything
about RURI termuser@192.168.100.77:60767
And I use my own transformation for some reasons else.
Hi gentlemen!
Sorry for my perseverance but I'll try to ask my question one more time.
I have following SIP-network configuration
Term=192.168.100.77 <-> NAT=Y.Y.Y.Y <-> OpenSER=X.X.X.X <-> GW=Z.Z.Z.Z
Term uses X.X.X.X as registrar and outbound proxy. It registered on
OpenSER as "vit-horosho(a)X.X.X.X".X.X". GW is gateway connected to POTS.
Then I make call from Term to POTS number 74951000000.
'ngrep SIP port 5060' output from OpenSER machine followed (I strip
some unimportant info from requests. My comments before requests)
Initial request from Term comes to OpenSER:
U Y.Y.Y.Y:60767 -> X.X.X.X:5060
INVITE sip:74951000000@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@192.168.100.77:5060>
OK. OpenSER send prov. reply to Term:
U X.X.X.X:5060 -> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
Content-Length: 0
Then I make my own transformations on Contact: header
Why are you replacing the Contact with the IP address of the proxy?
There is no need to do that. If you want NAT traversal use
fix_nated_contact(). and OpenSER resend
sorry for confusing -- it may be local generated 100.
request to GW. OpenSER adds Record-Route: header
into request also.
U X.X.X.X:5060 -> Z.Z.Z.Z:5060
INVITE sip:74951000000@Z.Z.Z.Z;user=phone SIP/2.0
Record-Route: <sip:X.X.X.X;lr=on;
ftag=00179A52BC45_T1011336699>
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0
Via: SIP/2.0/UDP 192.168.100.77:5060;rport=60767;received=
Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
Session-Expires: 1800
From: "Vit-Horosho" <sip:vit-horosho@80.23 7.15.3>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265@
192.168.100.77
CSeq: 397703138 INVITE
Contact: <sip:vit-horosho@X.X.X.X;nat=yes>
OK. GW send prov. reply to OpenSER
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767
;received=Y.Y.Y.Y;branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:57 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
OK. OpenSER resend prov. reply to Term
Why does openser resend the 100? I have never seen this before. U X.X.X.X:5060
-> Y.Y.Y.Y:60767
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T63F7A22E;
rport=60767;received=Y.Y.Y.Y
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
GW send 183 to OpenSER. Record-Route: header present in this reply.
U Z.Z.Z.Z:5060 -> X.X.X.X:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP X.X.X.X;branch=z9hG4bK7a3.0ae7d67.0,SIP/2.0/UDP
192.168.100.77:5060;rport=60767;received=Y.Y.Y.Y;
branch=z9hG4bK_00179A52BC45_T63F7A22E
From: "Vit-Horosho" <sip:vit-horosho@X.X.X.X>;
tag=00179A52BC45_T1011336699
To: <sip:74951000000@X.X.X.X:5060>;tag=54E1EED8-D8E
Date: Thu, 19 Apr 2007 18:37:58 GMT
Call-ID: CALL_ID4_00179A52BC45_T397365265(a)192.168.100.77
CSeq: 397703138 INVITE
RSeq: 3722
Contact: <sip:74951000000@Z.Z.Z.Z:5060>
Record-Route: <sip:X.X.X.X;lr=on;ftag=00179A52BC45_T1011336699>
OpenSER make my own transformation on Contact: header
This is the root of your problem. By rewriting the Contact header with
the IP address of the proxy you are not standard conform. Thus, the
loose routing of in-dialog messages can not work anymore, as the Contact
must be the address of the client, not the proxy.
where is differences between Proxy and Terminal using one IP (but may be
different UDP ports) and Contact: header rewrited by smart proxy which
know what it will be done when found RURI with values equal this Contact?
Which logic used by loose_route() to treat RURI as local RURI?
In this scenario why PRACK RURI
sip:74951000000@X.X.X.X:5060;nat=yes
don't treat as resource owned by this proxy?
Stop manipulating the Contact header and you will see
that loose routing
will work fine.
:-)
I stop loose_route() and everything works fine for our SIP-network. If
something come wrong -- I'll try to find new solutions for new problems.
Now I want to understand logic only.
I have only one idea -- call loose_route() after all my own
transformations and check what it will be do. But if loose_route() uses
original (not rewrited) requests so nothing to changes.
Sorry to trouble you
--
CU,
Victor Gamov
6219
days inactive
6243
days old
15 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Klaus Darilion -
Tsitsi -
Victor Gamov