Module: sip-router Branch: master Commit: 752de05cc567c7502b1e723a09e350ce8d447664 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=752de05c...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Fri Apr 19 13:24:52 2013 +0300
modules/rr: if outbound request is outgoing, do nothing outbound specific in loose_route()
---
modules/rr/loose.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/modules/rr/loose.c b/modules/rr/loose.c index 71f2465..e1d0571 100644 --- a/modules/rr/loose.c +++ b/modules/rr/loose.c @@ -550,7 +550,11 @@ static inline int process_outbound(struct sip_msg *_m, str flow_token, rcv->src_ip.af == AF_INET6 ? "]" : "", rcv->src_port, get_proto_name(rcv->proto)); - } + } else { + LM_DBG("outbound "outgoing" request found - " + "Not using flow-token for routing\n"); + return 0; + }
return 1; } @@ -787,6 +791,8 @@ static inline int after_loose(struct sip_msg* _m, int preloaded) return FLOW_TOKEN_BROKEN; }
+ LM_DBG("process_outbound returned <%d>\n", use_ob); + /* IF the URI was added by me, remove it */ if (uri_is_myself>0) {
Hi,
Sorry I had not had a chance to respond to the thread. I've been catching up with stuff here after Kamailio World.
That fix looks OK. I'd have done it slightly differently, moving the "return 1" into the last "else if" and then having the "return 0" as the catch-all at the end of the function instead of adding an "else" case.
Regards,
Peter
On 19/04/13 11:33, Juha Heinanen wrote:
Juha Heinanen writes:
modules/rr: if outbound request is outgoing, do nothing outbound specific in loose_route()
i don't know if this was the proper fix, but at least my test cases now work ok.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
That fix looks OK. I'd have done it slightly differently, moving the "return 1" into the last "else if" and then having the "return 0" as the catch-all at the end of the function instead of adding an "else" case.
peter,
feel free to improve to your liking.
once i got that solved, i'm next havind trouble with record-route added by edge proxy (as i already mentioned in previous message).
here is invite that comes to edge proxy:
T 2013/04/19 16:50:00.043131 192.98.102.10:48018 -> 192.98.102.10:5060 [AP] INVITE sip:test@test.fi SIP/2.0. Via: SIP/2.0/TCP 192.98.102.10:48018;rport;branch=z9hG4bKPj19602c3d-c72f-4a4c-830d-400175af5366. Max-Forwards: 70. From: sip:jh@test.fi;tag=69f53ec5-b56e-4887-911d-5b389ae5ce8d. To: sip:test@test.fi. Contact: sip:jh@192.98.102.10:5068;transport=TCP;ob. Call-ID: 4529a8ec-bee6-4205-942f-be567e41a52e. CSeq: 22685 INVITE. Route: sip:192.98.102.10;transport=tcp;lr. Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS. Supported: replaces, 100rel, timer, norefersub. Session-Expires: 1800. Min-SE: 90. User-Agent: PJSUA v2.1 Linux-3.2.0.4/x86_64/glibc-2.13. Content-Type: application/sdp. Content-Length: 476.
it does not have Supported: outbound, but there is ;ob param in contact.
edge proxy then adds to the request this kind of R-R header:
Record-Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr
is this correct, because based on it, the ua that sent the invite above, sends ack to incorrectly to 192.98.102.10:5070:
T 2013/04/19 16:56:33.521310 192.98.102.10:41051 -> 192.98.102.10:5070 [AP] ACK sip:0x179a610@192.98.102.10:55798;transport=tcp SIP/2.0. Via: SIP/2.0/TCP 192.98.102.10:41051;rport;branch=z9hG4bKPj9b826086-ba81-4798-9887-8e72e094276d. Max-Forwards: 70. From: sip:jh@test.fi;tag=cb46683f-021e-4fac-b60d-e8e23accdfe7. To: sip:test@test.fi;tag=461b8ff42168dbf0. Call-ID: a7869ed1-82fd-4650-a987-f62dd8551b1d. CSeq: 32765 ACK. Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr. Route: sip:/eWzbwNo9LE2pQLAYmYUE8TAYmYK2fY=@192.98.102.20;transport=tcp;lr. Content-Length: 0.
-- juha
Juha Heinanen writes:
it does not have Supported: outbound, but there is ;ob param in contact.
this looks like bug in pjsip, because according to outbound rfc 5626:
4.3. Sending Non-REGISTER Requests
... UAs that support this specification SHOULD include the outbound option tag in a Supported header field in a request that is not a REGISTER request.
in my opinion, outbound module should check Supported: outbound and not just believe ;ob param.
perhaps there is another bug in pjsip, because it is not using the same flow for ack as it used for invite.
-- juha
I think I see the problem.
The SIP request comes into the edge proxy on port 5060 and leaves on port 5070.
When outbound is enabled Kamailio doesn't do double-record-routing. When I implemented outbound I thought that because the same information as is in the double-RR is embedded in the flow-token it wouldn't be needed. It looks like it still is needed in order for the devices surrounding the edge-proxy to be able to correctly route.
I think the fix is to re-instate double-RR for outbound and make sure that, when double-RR is used, the flow-token is added it goes into the record-route that contains the address/port/protocol that the SIP request arrived on (which I believe is the second to top one, the top one being the RR that indicates the address/port/protocol the SIP request leaves on).
This means record.c needs to be changed to add the double-RR correctly for outbound, and loose.c needs to be changed to correctly eat the two routes instead of just one. The only flow-token that should be used in loose.c is the one in the LAST route that points to the edge-proxy.
Regards,
Peter
On 19/04/13 15:00, Juha Heinanen wrote:
Peter Dunkley writes:
That fix looks OK. I'd have done it slightly differently, moving the "return 1" into the last "else if" and then having the "return 0" as the catch-all at the end of the function instead of adding an "else" case.
peter,
feel free to improve to your liking.
once i got that solved, i'm next havind trouble with record-route added by edge proxy (as i already mentioned in previous message).
here is invite that comes to edge proxy:
T 2013/04/19 16:50:00.043131 192.98.102.10:48018 -> 192.98.102.10:5060 [AP] INVITE sip:test@test.fi SIP/2.0. Via: SIP/2.0/TCP 192.98.102.10:48018;rport;branch=z9hG4bKPj19602c3d-c72f-4a4c-830d-400175af5366. Max-Forwards: 70. From: sip:jh@test.fi;tag=69f53ec5-b56e-4887-911d-5b389ae5ce8d. To: sip:test@test.fi. Contact: sip:jh@192.98.102.10:5068;transport=TCP;ob. Call-ID: 4529a8ec-bee6-4205-942f-be567e41a52e. CSeq: 22685 INVITE. Route: sip:192.98.102.10;transport=tcp;lr. Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS. Supported: replaces, 100rel, timer, norefersub. Session-Expires: 1800. Min-SE: 90. User-Agent: PJSUA v2.1 Linux-3.2.0.4/x86_64/glibc-2.13. Content-Type: application/sdp. Content-Length: 476.
it does not have Supported: outbound, but there is ;ob param in contact.
edge proxy then adds to the request this kind of R-R header:
Record-Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr
is this correct, because based on it, the ua that sent the invite above, sends ack to incorrectly to 192.98.102.10:5070:
T 2013/04/19 16:56:33.521310 192.98.102.10:41051 -> 192.98.102.10:5070 [AP] ACK sip:0x179a610@192.98.102.10:55798;transport=tcp SIP/2.0. Via: SIP/2.0/TCP 192.98.102.10:41051;rport;branch=z9hG4bKPj9b826086-ba81-4798-9887-8e72e094276d. Max-Forwards: 70. From: sip:jh@test.fi;tag=cb46683f-021e-4fac-b60d-e8e23accdfe7. To: sip:test@test.fi;tag=461b8ff42168dbf0. Call-ID: a7869ed1-82fd-4650-a987-f62dd8551b1d. CSeq: 32765 ACK. Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr. Route: sip:/eWzbwNo9LE2pQLAYmYUE8TAYmYK2fY=@192.98.102.20;transport=tcp;lr. Content-Length: 0.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
When outbound is enabled Kamailio doesn't do double-record-routing. When I implemented outbound I thought that because the same information as is in the double-RR is embedded in the flow-token it wouldn't be needed. It looks like it still is needed in order for the devices surrounding the edge-proxy to be able to correctly route.
yee, i haven't found in outbound rfc a clear statement telling that outbound UA should not care about R-R headers at all when it sends out in-dialog requests, but use the same flow as it used for dialog forming request.
-- juha
Juha Heinanen writes:
modules/rr: if outbound request is outgoing, do nothing outbound specific in loose_route()
i don't know if this was the proper fix, but at least my test cases now work ok.
except if outbound request is incoming like this ack:
ACK sip:0x179a610@192.98.102.10:55798;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.98.102.10:53004;rport;branch=z9hG4bKPj9f087cbc-a2ab-460d-8001-97a7b3ab930f Max-Forwards: 70 From: sip:jh@test.fi;tag=e3963acf-9b21-417a-82ac-0bdd28c0280f To: sip:test@test.fi;tag=b713d95a6b46ec02 Call-ID: 72b66689-a3ba-4240-af7d-be7891cdde58 CSeq: 27851 ACK Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr Route: sip:/eWzbwNo9LE2pQLAYmYUE8TAYmYK2fY=@192.98.102.20;transport=tcp;lr Content-Length: 0
i get to syslog:
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: calling loose_route() on route <sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr> Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:525]: "incoming" request found. Using flow-token for routing Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:794]: process_outbound returned <1> Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:800]: Topmost route URI: 'sip:192.98.102.10:48018;transport=tcp' is me Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: ru/du = sip:0x179a610@192.98.102.10:55798;transport=tcp/sip:192.98.102.10:48018;transport=tcp Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: Routing in-dialog ACK sip:0x179a610@192.98.102.10:55798;transport=tcp from sip:jh@test.fi to sip:192.98.102.10:48018;transport=tcp
as result, proxy sends ack back to the ua that sent it.
also the record-route header added by outbound proxy to the invite is strange:
Route: sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr
ip address is ok, but port is not the one that the proxy uses to talk with UAs. as consequence, when the ua that sent the invite sends ack, it is sending it to wrong port.
-- juha
-
Juha Heinanen -
Peter Dunkley