17 Dec
2009
17 Dec
'09
3:17 p.m.
i noticed that if sr sends a locally generated INVITE (as result of
tm.t_uac_wait), the INVITE gets processes by my
event_route [tm:local-request]
script, but when UA responds with 200 OK, the ACK generated by sr does
not get processed by the event_route and if the UA is behind nat, the UA
never gets the ACK it because sr tries to send it to local address of
the UA.
how can i get sr to use the above event route also for locally generated
ACKs so that i can properly rewrite r-uri of the ACK?
-- juha
17 Dec
17 Dec
3:51 p.m.
Hello,
On 12/17/09 2:17 PM, Juha Heinanen wrote:
i noticed that if sr sends a locally generated INVITE
(as result of
tm.t_uac_wait), the INVITE gets processes by my
event_route [tm:local-request]
script, but when UA responds with 200 OK, the ACK generated by sr does
not get processed by the event_route and if the UA is behind nat, the UA
never gets the ACK it because sr tries to send it to local address of
the UA.
how can i get sr to use the above event route also for locally generated
ACKs so that i can properly rewrite r-uri of the ACK?
ack and cancel are generated by other part of tm, where event_route is
not executed. However, afaik, tm should automatically send the such ack
and cancel where the invite was sent.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:59 p.m.
Daniel-Constantin Mierla writes:
ack and cancel are generated by other part of tm,
where event_route is
not executed. However, afaik, tm should automatically send the such ack
and cancel where the invite was sent.
daniel,
thanks for your response. see wireshark output below. ack is NOT sent
to the same ip/port as invite.
-- juha
------------------------------------------------------------------------
No. Time Source Destination Protocol Info
4 15:48:23.012034 192.98.101.10 192.98.101.132 SIP/SDP Request:
INVITE sip:jh_tutpro_com@192.168.0.169:5074;transport=udp, with session description
Frame 4 (624 bytes on wire, 624 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.10 (192.98.101.10), Dst: 192.98.101.132
(192.98.101.132)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 60705 (60705)
Session Initiation Protocol
Request-Line: INVITE sip:jh_tutpro_com@192.168.0.169:5074;transport=udp SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
To: <sip:jh@tutpro.com>
From: <sip:click2dial@tutpro.com>;tag=4b2a36a70277f
CSeq: 1 INVITE
Call-ID: 4b2a36a70277f(a)tutpro.com
Content-Length: 131
User-Agent: SIP Proxy (2.99.99-pre3 (i386/linux))
Contact: <sip:click2dial@192.98.101.10:5060>
Reject-Contact: *;automata="YES"
Content-Type: application/sdp
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): click-to-dial 0 0 IN IP4 0.0.0.0
Session Name (s): session
Connection Information (c): IN IP4 0.0.0.0
Bandwidth Information (b): CT:1000
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 9 RTP/AVP 0
Media Attribute (a): rtpmap:0 PCMU/8000
No. Time Source Destination Protocol Info
8 15:48:25.439877 192.98.101.132 192.98.101.10 SIP/SDP Status: 200
OK, with session description
Frame 8 (719 bytes on wire, 719 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.132 (192.98.101.132), Dst: 192.98.101.10
(192.98.101.10)
User Datagram Protocol, Src Port: 60705 (60705), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
To: <sip:jh@tutpro.com>;tag=qpgxk
From: <sip:click2dial@tutpro.com>;tag=4b2a36a70277f
Call-ID: 4b2a36a70277f(a)tutpro.com
CSeq: 1 INVITE
Contact: <sip:jh_tutpro_com@192.168.0.169:5074;transport=udp>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Server: Twinkle/1.3.2
Supported: replaces,norefersub
Content-Length: 208
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 1232785010 225740651 IN IP4
192.168.0.169
Session Name (s): -
Connection Information (c): IN IP4 192.168.0.169
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8000 RTP/AVP 0 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
No. Time Source Destination Protocol Info
9 15:48:25.440175 192.98.101.10 192.168.0.169 SIP Request: ACK
sip:jh_tutpro_com@192.168.0.169:5074;transport=udp
Frame 9 (384 bytes on wire, 384 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.10 (192.98.101.10), Dst: 192.168.0.169 (192.168.0.169)
User Datagram Protocol, Src Port: sip (5060), Dst Port: alesquery (5074)
Session Initiation Protocol
Request-Line: ACK sip:jh_tutpro_com@192.168.0.169:5074;transport=udp SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
From: <sip:click2dial@tutpro.com>;tag=4b2a36a70277f
Call-ID: 4b2a36a70277f(a)tutpro.com
To: <sip:jh@tutpro.com>;tag=qpgxk
CSeq: 1 ACK
User-Agent: SIP Proxy (2.99.99-pre3 (i386/linux))
Content-Length: 0
4:33 p.m.
On 12/17/09 2:59 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I see, i will try to look over the code later today or maybe Andrei can
give a faster answer meanwhile.
Cheers,
Daniel
ack and cancel are generated by other part of
tm, where event_route is
not executed. However, afaik, tm should automatically send the such ack
and cancel where the invite was sent.
daniel,
thanks for your response. see wireshark output below. ack is NOT sent
to the same ip/port as invite.
-- juha
------------------------------------------------------------------------
No. Time Source Destination Protocol Info
4 15:48:23.012034 192.98.101.10 192.98.101.132 SIP/SDP Request:
INVITE sip:jh_tutpro_com@192.168.0.169:5074;transport=udp, with session description
Frame 4 (624 bytes on wire, 624 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.10 (192.98.101.10), Dst: 192.98.101.132
(192.98.101.132)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 60705 (60705)
Session Initiation Protocol
Request-Line: INVITE sip:jh_tutpro_com@192.168.0.169:5074;transport=udp SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
To:<sip:jh@tutpro.com>
From:<sip:click2dial@tutpro.com>;tag=4b2a36a70277f
CSeq: 1 INVITE
Call-ID: 4b2a36a70277f(a)tutpro.com
Content-Length: 131
User-Agent: SIP Proxy (2.99.99-pre3 (i386/linux))
Contact:<sip:click2dial@192.98.101.10:5060>
Reject-Contact: *;automata="YES"
Content-Type: application/sdp
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): click-to-dial 0 0 IN IP4 0.0.0.0
Session Name (s): session
Connection Information (c): IN IP4 0.0.0.0
Bandwidth Information (b): CT:1000
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 9 RTP/AVP 0
Media Attribute (a): rtpmap:0 PCMU/8000
No. Time Source Destination Protocol Info
8 15:48:25.439877 192.98.101.132 192.98.101.10 SIP/SDP Status: 200
OK, with session description
Frame 8 (719 bytes on wire, 719 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.132 (192.98.101.132), Dst: 192.98.101.10
(192.98.101.10)
User Datagram Protocol, Src Port: 60705 (60705), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
To:<sip:jh@tutpro.com>;tag=qpgxk
From:<sip:click2dial@tutpro.com>;tag=4b2a36a70277f
Call-ID: 4b2a36a70277f(a)tutpro.com
CSeq: 1 INVITE
Contact:<sip:jh_tutpro_com@192.168.0.169:5074;transport=udp>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Server: Twinkle/1.3.2
Supported: replaces,norefersub
Content-Length: 208
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 1232785010 225740651 IN IP4
192.168.0.169
Session Name (s): -
Connection Information (c): IN IP4 192.168.0.169
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8000 RTP/AVP 0 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
No. Time Source Destination Protocol Info
9 15:48:25.440175 192.98.101.10 192.168.0.169 SIP Request:
ACK sip:jh_tutpro_com@192.168.0.169:5074;transport=udp
Frame 9 (384 bytes on wire, 384 bytes captured)
Linux cooked capture
Internet Protocol, Src: 192.98.101.10 (192.98.101.10), Dst: 192.168.0.169
(192.168.0.169)
User Datagram Protocol, Src Port: sip (5060), Dst Port: alesquery (5074)
Session Initiation Protocol
Request-Line: ACK sip:jh_tutpro_com@192.168.0.169:5074;transport=udp SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bKfb.dfd399d1.0
From:<sip:click2dial@tutpro.com>;tag=4b2a36a70277f
Call-ID: 4b2a36a70277f(a)tutpro.com
To:<sip:jh@tutpro.com>;tag=qpgxk
CSeq: 1 ACK
User-Agent: SIP Proxy (2.99.99-pre3 (i386/linux))
Content-Length: 0
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:52 p.m.
even if i call fix_nated_contact() when sr receives 200 ok to locally
generated invite, it is still trying to send the ack to local address of
the ua. looks like modifications done in reply_route to 200 ok are not
visible to sr when it generates the ack.
andrei, can you confirm this? are there any means to solve this
problem?
-- juha
4:44 p.m.
Juha Heinanen wrote:
even if i call fix_nated_contact() when sr receives
200 ok to locally
generated invite, it is still trying to send the ack to local address of
the ua. looks like modifications done in reply_route to 200 ok are not
visible to sr when it generates the ack.
andrei, can you confirm this? are there any means to solve this
problem?
maybe
http://sip-router.org/docbook/sip-router/branch/master/modules_k/textops/te…
can help
klaus
4:55 p.m.
Klaus Darilion writes:
klaus,
thanks for the hint, but i'll wait first if the problem can be properly
fixed. msg_apply_changes() sounds like a hack to me.
-- juha
5:30 p.m.
Juha Heinanen wrote:
Klaus Darilion writes:
klaus,
thanks for the hint, but i'll wait first if the problem can be properly
fixed. msg_apply_changes() sounds like a hack to me.
yes, it is a hack ...
klaus
-- juha
18 Dec
18 Dec
8:18 a.m.
Klaus Darilion writes:
klaus,
since i have not heard anything from andrei or daniel about the ack
problem, i decided to give msg_apply_changes() a try. it turned out
that msg_apply_changes() cannot be called from onreply_route.
-- juha
9:56 a.m.
Hi Juha,
On 12/18/09 7:18 AM, Juha Heinanen wrote:
Klaus Darilion writes:
klaus,
since i have not heard anything from andrei or daniel
I returned too late
yesterday, I will check today.
Daniel
about the ack
problem, i decided to give msg_apply_changes() a try. it turned out
that msg_apply_changes() cannot be called from onreply_route.
--
Daniel-Constantin Mierla
* http://www.asipto.com/
1:27 p.m.
On Dec 17, 2009 at 15:52, Juha Heinanen <jh(a)tutpro.com> wrote:
even if i call fix_nated_contact() when sr receives
200 ok to locally
generated invite, it is still trying to send the ack to local address of
the ua. looks like modifications done in reply_route to 200 ok are not
visible to sr when it generates the ack.
andrei, can you confirm this? are there any means to solve this
problem?
Yes, onreply_route modifications are not taken into account by tm.
In fact final responses are processed by tm _before_ executing the
onreply_route. The onreply_route changes will only appear in the
forwarded reply.
Right now the only way to solve this without code changes is to add
another hop (e.g. route the message once through localhost or another
proxy and fix the contact there).
With coding changes I see 2 possible workarounds:
1. add a param. for using the local INVITE dst. when generating the ACK
(instead of obeying the rfc) (easy)
2. add a t_reply_fake_contact() command for changing the contact seen by
tm and maybe modifiying fix_nated_contact() to use it.
Andrei
3:01 p.m.
Andrei Pelinescu-Onciul writes:
Right now the only way to solve this without code
changes is to add
another hop (e.g. route the message once through localhost or another
proxy and fix the contact there).
andrei,
this used to work fine in k, so i would don't like the idea about
changing the script, especially when the change would not be trivial.
With coding changes I see 2 possible workarounds:
1. add a param. for using the local INVITE dst. when generating the ACK
(instead of obeying the rfc) (easy)
where would that param be added? can't the param be set automatically
when invite is issued by tm.t_uac_wait?
2. add a t_reply_fake_contact() command for changing
the contact seen by
tm and maybe modifiying fix_nated_contact() to use it.
if t_reply_fake_contact() is implemented, why can't i just call that
function in onreply_route instead of fix_nated_contact()?
-- juha
19 Dec
19 Dec
12:20 p.m.
On Dec 18, 2009 at 15:01, Juha Heinanen <jh(a)tutpro.com> wrote:
tm global param, e.g. modparam("tm", "local_200_ack_send_mode", 1).
In this case we would need to copy fix_nated_contact() into
t_reply_fake_contact().
Andrei
Andrei Pelinescu-Onciul writes:
After looking at the code, I doubt it used to work in k. k still sends
an ACK based on the reply contact and the final replies are processed
before the reply route is executed (same as in sr).
Right now the only way to solve this without code
changes is to add
another hop (e.g. route the message once through localhost or another
proxy and fix the contact there).
andrei,
this used to work fine in k, so i would don't like the idea about
changing the script, especially when the change would not be trivial. With coding changes I see 2 possible
workarounds:
1. add a param. for using the local INVITE dst. when generating the ACK
(instead of obeying the rfc) (easy)
where would that param be added? can't the param be set automatically
when invite is issued by tm.t_uac_wait?
That would complicate things. We would need another flags and we would
need to chande t_uac_wait to take another param.
2. add a t_reply_fake_contact() command for
changing the contact seen by
tm and maybe modifiying fix_nated_contact() to use it.
if t_reply_fake_contact() is implemented, why can't i just call that
function in onreply_route instead of fix_nated_contact()?
12:31 p.m.
Andrei Pelinescu-Onciul writes:
tm global param, e.g. modparam("tm", "local_200_ack_send_mode", 1).
andrei,
that would be fine with me and if it is easy too, then please go
ahead and add the param.
-- juha
With coding changes I see 2 possible workarounds:
1. add a param. for using the local INVITE dst. when generating the ACK
(instead of obeying the rfc) (easy)
where would that param be added?
12:54 p.m.
andrei,
i made the exactly same test with kamailio 1.5 and it does send the ack
to 200 ok to the same ip/port as invite. i don't know how that is
possible when you say you have read the code and there is no difference,
but that is what is happening.
wireshark output is below.
but as i told in my previous reply, the new tm module param would be
fine with me. i don't care how it is made to work as long as it works.
-- juha
----------------------------------------------------------------------------
No. Time Source Destination Protocol Info
1 12:37:47.970568 192.98.101.34 192.98.100.132 SIP/SDP Request:
INVITE sip:jh@192.168.0.169:5074, with session description
Frame 1 (594 bytes on wire, 594 bytes captured)
Ethernet II, Src: Micro-St_12:9c:1f (00:0c:76:12:9c:1f), Dst: D-Link_a1:05:85
(00:1b:11:a1:05:85)
Internet Protocol, Src: 192.98.101.34 (192.98.101.34), Dst: 192.98.100.132
(192.98.100.132)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 65023 (65023)
Session Initiation Protocol
Request-Line: INVITE sip:jh@192.168.0.169:5074 SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.34;branch=z9hG4bKe9f7.475deca2.0
To: <sip:jh@openxg.com>
From: <sip:click2dial@openxg.com>;tag=4b2cacfbec47f
CSeq: 1 INVITE
Call-ID: 4b2cacfbec47f(a)openxg.com
Content-Length: 131
User-Agent: Kamailio (1.5.3-tls (i386/linux))
Contact: <sip:click2dial@192.98.101.34:5060>
Reject-Contact: *;automata="YES"
Content-Type: application/sdp
Message Body
No. Time Source Destination Protocol Info
5 12:37:56.154785 192.98.100.132 192.98.101.34 SIP/SDP Status: 200
OK, with session description
Frame 5 (694 bytes on wire, 694 bytes captured)
Ethernet II, Src: D-Link_a1:05:85 (00:1b:11:a1:05:85), Dst: Micro-St_12:9c:1f
(00:0c:76:12:9c:1f)
Internet Protocol, Src: 192.98.100.132 (192.98.100.132), Dst: 192.98.101.34
(192.98.101.34)
User Datagram Protocol, Src Port: 65023 (65023), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.98.101.34;branch=z9hG4bKe9f7.475deca2.0
To: <sip:jh@openxg.com>;tag=tnemc
From: <sip:click2dial@openxg.com>;tag=4b2cacfbec47f
Call-ID: 4b2cacfbec47f(a)openxg.com
CSeq: 1 INVITE
Contact: <sip:jh@192.168.0.169:5074>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Server: Twinkle/1.3.2
Supported: replaces,norefersub
Content-Length: 208
Message Body
No. Time Source Destination Protocol Info
6 12:37:56.154959 192.98.101.34 192.98.100.132 SIP Request: ACK
sip:jh@192.168.0.169:5074
Frame 6 (354 bytes on wire, 354 bytes captured)
Ethernet II, Src: Micro-St_12:9c:1f (00:0c:76:12:9c:1f), Dst: D-Link_a1:05:85
(00:1b:11:a1:05:85)
Internet Protocol, Src: 192.98.101.34 (192.98.101.34), Dst: 192.98.100.132
(192.98.100.132)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 65023 (65023)
Session Initiation Protocol
Request-Line: ACK sip:jh@192.168.0.169:5074 SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.98.101.34;branch=z9hG4bKe9f7.475deca2.0
From: <sip:click2dial@openxg.com>;tag=4b2cacfbec47f
Call-ID: 4b2cacfbec47f(a)openxg.com
To: <sip:jh@openxg.com>;tag=tnemc
CSeq: 1 ACK
User-Agent: Kamailio (1.5.3-tls (i386/linux))
Content-Length: 0
18 Dec
18 Dec
3:16 p.m.
On 12/18/09 12:27 PM, Andrei Pelinescu-Onciul wrote:
On Dec 17, 2009 at 15:52, Juha
Heinanen<jh(a)tutpro.com> wrote:
Isn't the RFC requiring to send cancel and negative ack to the same
destination as INVITE?
Cheers,
Daniel
even if i call fix_nated_contact() when sr
receives 200 ok to locally
generated invite, it is still trying to send the ack to local address of
the ua. looks like modifications done in reply_route to 200 ok are not
visible to sr when it generates the ack.
andrei, can you confirm this? are there any means to solve this
problem?
Yes, onreply_route modifications are not taken into account by tm.
In fact final responses are processed by tm _before_ executing the
onreply_route. The onreply_route changes will only appear in the
forwarded reply.
Right now the only way to solve this without code changes is to add
another hop (e.g. route the message once through localhost or another
proxy and fix the contact there).
With coding changes I see 2 possible workarounds:
1. add a param. for using the local INVITE dst. when generating the ACK
(instead of obeying the rfc) (easy)
2. add a t_reply_fake_contact() command for changing
the contact seen by
tm and maybe modifiying fix_nated_contact() to use it.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:21 p.m.
Daniel-Constantin Mierla writes:
Isn't the RFC requiring to send cancel and
negative ack to the same
destination as INVITE?
in the case that i reported, the ack was to 200 ok and thus not part of
invite/200 ok transaction. in that case, the ack should be sent to
contact uri of 200 ok (there was no rr in 200 ok).
-- juha
3:32 p.m.
On 12/18/09 2:21 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
ahh, right, I got it wrong in the first place.
Then, in this case, might be good to call the event_route as well. I was
thinking the case of negative reply, where no much could have been done
in terms of routing.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Isn't the RFC requiring to send cancel and
negative ack to the same
destination as INVITE?
in the case that i reported, the ack was to 200 ok and thus not part of
invite/200 ok transaction. in that case, the ack should be sent to
contact uri of 200 ok (there was no rr in 200 ok).
3:37 p.m.
Daniel-Constantin Mierla writes:
but reply could be negative too. the system has to work no matter if
positive or negative reply is received.
in the case
that i reported, the ack was to 200 ok and thus not part of
invite/200 ok transaction. in that case, the ack should be sent to
contact uri of 200 ok (there was no rr in 200 ok).
ahh, right, I got it wrong in the first place. Then, in this case, might be good to call the
event_route as well. I was
thinking the case of negative reply, where no much could have been done
in terms of routing.
you mean calling event_route on ack? according to xlog call that i have
in event_route [tm:local-request], it is NOT called on ack to 200 ok.
-- juha
3:43 p.m.
On 12/18/09 2:37 PM, Juha Heinanen wrote:
tm:local-request is triggered only by the call of t_uac function from
tm. But I'm thinking whether makes sense or not to have it as well for
ACK of 200ok for local transactions -- this is generated by tm in other
place. All the other requests (again, apart of cancel and ack)
self-generated by proxy go via t_uac.
Cheers,
Daniel
Daniel-Constantin Mierla writes:
but reply could be negative too. the system has to work no matter if
positive or negative reply is received.
of course. Somehow I understood you are talking about ack to negative
replies. cancel and ack for negative replies are auto-generated and do
not trigger the local-request event route.
in the
case that i reported, the ack was to 200 ok and thus not part of
invite/200 ok transaction. in that case, the ack should be sent to
contact uri of 200 ok (there was no rr in 200 ok).
ahh, right, I got it wrong in the first place. Then, in this
case, might be good to call the event_route as well. I was
thinking the case of negative reply, where no much could have been done
in terms of routing.
you mean calling event_route on ack? according to xlog call that i have
in event_route [tm:local-request], it is NOT called on ack to 200 ok.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:50 p.m.
Daniel-Constantin Mierla writes:
tm:local-request is triggered only by the call of
t_uac function from
tm. But I'm thinking whether makes sense or not to have it as well for
ACK of 200ok for local transactions -- this is generated by tm in other
place. All the other requests (again, apart of cancel and ack)
self-generated by proxy go via t_uac.
ack to 200 ok is its own transaction. so how could i rewrite its
request uri to include $si$sp from 200 ok, because the info is already
lost?
on the other hand, if andrei would implement t_reply_fake_contact(), i
could call it in onreply_route with $si:$sp argument.
-- juha
4:04 p.m.
On 12/18/09 2:50 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I can find some solutions with existing code, but, let's say, they are
more workarounds. One is to use a hashtable to store per callid the ip
and port, with some timeout to be auto-deleted - then take it to build
outbound address.
However, it is better to have it fixed in the code properly.
My question about running local-request for positive ack was for generic
purpose, if someone would need in some case to process such ACK via
local-request event route.
Cheers,
Daniel
tm:local-request is triggered only by the call
of t_uac function from
tm. But I'm thinking whether makes sense or not to have it as well for
ACK of 200ok for local transactions -- this is generated by tm in other
place. All the other requests (again, apart of cancel and ack)
self-generated by proxy go via t_uac.
ack to 200 ok is its own transaction. so how could i rewrite its
request uri to include $si$sp from 200 ok, because the info is already
lost?
on the other hand, if andrei would implement
t_reply_fake_contact(), i
could call it in onreply_route with $si:$sp argument.
--
Daniel-Constantin Mierla
* http://www.asipto.com/
19 Dec
19 Dec
10:30 a.m.
i verified that if sr gets negative response to locally generated
invite, then sr sends ack to the same ip/port as where it sent the
invite to.
so the problem only exists with ack to positive reply, i.e., with ack
that is its own transaction and not part of the invite transaction.
-- juha
21 Dec
21 Dec
12:17 p.m.
since i'm stuck with ACKs to locally generated INVITEs never reaching
UASes behind NATs, i tried to read tm code to find out how to make sr
always send ACK to locally generated INVITE to use the same r-uri and
destination set as the INVITE itself.
i found this piece of code reply_received() function of t_reply.c:
if (is_invite(t)) {
if (msg_status >= 300) {
ack = build_ack(p_msg, t, branch, &ack_len);
it looks to me that the desired effect could be achieved if the middle
line is changed to something like this:
if ((msg_status >= 300) || "invite was generated locally by t_uac function")
{
does someone know how to implement the test, i.e., is there some info in
t structure that could be used to figure out if the invite was locally
generated?
-- juha
1:18 p.m.
On Dec 21, 2009 at 12:17, Juha Heinanen <jh(a)tutpro.com> wrote:
since i'm stuck with ACKs to locally generated
INVITEs never reaching
UASes behind NATs, i tried to read tm code to find out how to make sr
always send ACK to locally generated INVITE to use the same r-uri and
destination set as the INVITE itself.
i found this piece of code reply_received() function of t_reply.c:
if (is_invite(t)) {
if (msg_status >= 300) {
ack = build_ack(p_msg, t, branch, &ack_len);
it looks to me that the desired effect could be achieved if the middle
line is changed to something like this:
if ((msg_status >= 300) || "invite was generated locally by t_uac function")
{
No, not that line, You should change the else part of the same if:
} else if (is_local(t) /*&& 200 <= msg_status < 300*/) {
This is the part that generates ACK to 2xx for local transactions.
If you change the negative ack part, then you'll have an ack to 2xx
generated the same way as a neg. ack (the route set and the uri might be
wrong).
does someone know how to implement the test, i.e., is there some info in
t structure that could be used to figure out if the invite was locally
generated?
Change build_dlg_ack() (t_msg_builder.c:915), the part awhere dst is set
(uri2dst). There are some ifs enclodes in #ifdef USE_DNS_FAILOVER,
arround line 987-1009. They should be changed to look for a new tm
modparam and if it is set, set dst to the invite dst (obtained from
Trans and branch).
I'll try to do it today.
Andrei
2:51 p.m.
Andrei Pelinescu-Onciul writes:
If you change the negative ack part, then you'll
have an ack to 2xx
generated the same way as a neg. ack (the route set and the uri might be
wrong).
andrei,
this is exactly what i tried to achieve, i.e., if 200 ok is to a locally
generated invite, then ack should be send the same way as negative ack.
from rfc3261:
The ACK (to negative reply) MUST be sent to the same address, port,
and transport to which the original request was sent.
so what i proposed should work IF it is possible to add the test that i
outlined:
if ((msg_status >= 300) || "invite was
generated locally by t_uac function") {
i.e, if ack is to negative reply OR if invite was locally generated,
send the ack the same way.
but for me, of course, any way to get to the same result if fine.
-- juha
23 Dec
23 Dec
2:35 p.m.
On Dec 21, 2009 at 14:51, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
Yes, but the ACK to the negative reply is built differently. It's built
from the original INVITE and hence it doesn't include the proper route
set and possible uri changes (due to strict routers).
If you change the negative ack part, then
you'll have an ack to 2xx
generated the same way as a neg. ack (the route set and the uri might be
wrong).
andrei,
this is exactly what i tried to achieve, i.e., if 200 ok is to a locally
generated invite, then ack should be send the same way as negative ack.
from rfc3261:
The ACK (to negative reply) MUST be sent to the same address, port,
and transport to which the original request was sent.
so what i proposed should work IF it is possible to add the test that i
outlined:
if ((msg_status >= 300) || "invite was
generated locally by t_uac function") {
i.e, if ack is to negative reply OR if invite was locally generated,
send the ack the same way.
but for me, of course, any way to get to the same result if fine.
I've added a new parameter (local_ack_mode) on the sr_3.0 branch.
Docs will come a bit later.
Sorry for the delay, but my laptop had an unfortunate accident
(involving water) and it took some time to recover (drying) :-)
Andrei
5455
days inactive
5461
days old
26 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Klaus Darilion