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@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@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@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

Klaus Darilion writes:

maybe http://sip-router.org/docbook/sip-router/branch/master/modules_k/textops/tex... can help

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

Klaus Darilion writes:

maybe http://sip-router.org/docbook/sip-router/branch/master/modules_k/textops/tex... can help

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

On Dec 17, 2009 at 15:52, Juha Heinanen jh@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

On Dec 18, 2009 at 15:01, Juha Heinanen jh@tutpro.com wrote:

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.

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).

...

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?

tm global param, e.g. modparam("tm", "local_200_ack_send_mode", 1).

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()?

In this case we would need to copy fix_nated_contact() into t_reply_fake_contact().

Andrei

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@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@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@openxg.com To: sip:jh@openxg.com;tag=tnemc CSeq: 1 ACK User-Agent: Kamailio (1.5.3-tls (i386/linux)) Content-Length: 0

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

Daniel-Constantin Mierla writes:

...

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.

but reply could be negative too. the system has to work no matter if positive or negative reply is received.

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

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

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

On Dec 21, 2009 at 12:17, Juha Heinanen jh@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

On Dec 21, 2009 at 14:51, Juha Heinanen jh@tutpro.com wrote:

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.

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).

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