Hi All.
I just don't see why loose_route() returned FALSE for this INVITE message. Can anyone help?
This INVITE was sent from my SIP phone to my SER-0.9 proxy. The IPs look funny because our SER proxy sits behind a Cisco 3600 and the ALG stuff has rewritten the IPs (ie, the 10.3.0.221 address).
Regards, Paul
U 2005/03/14 16:01:19.932196 69.200.205.122:5060 -> 10.3.0.221:5060 INVITE sip:9195531888@66.243.109.99:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP 69.200.205.122:5060;branch=z9hG4bK2434592534. Route: sip:10.3.0.221;ftag=10000000-0-1811969809;lr. Route: sip:216.229.127.60:5060;lr. From: 3475626630 sip:3475626630@66.243.109.99:5060;user=phone;tag=550070175. To: sip:9195531888@64.152.60.6;user=phone;tag=10000000-0-1811969809. Call-ID: 348926-3319820023-453493@66.243.109.99. CSeq: 1 INVITE. Contact: sip:3475626630@69.200.205.122:5060. max-forwards: 70. Allow: INVITE, ACK, OPTIONS, CANCEL, BYE. Content-Type: application/sdp. Content-Length: 171. . v=0. o=- 9528 3044 IN IP4 0.0.0.0. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 13456 RTP/AVP 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendonly. a=ptime:20.
Hi Paul!
That something I also asked several times and no answer yet. In my experience, loose_route() is true if the request URI contains the "lr" paramter (message comes from a strict router). Nevertheless, the loose_route function will remove its own Route: header.
I solve the troubles by allowing t_relay for all messages with to-tag (in-dialog).
regards, klaus
Java Rockx wrote:
Hi All.
I just don't see why loose_route() returned FALSE for this INVITE message. Can anyone help?
This INVITE was sent from my SIP phone to my SER-0.9 proxy. The IPs look funny because our SER proxy sits behind a Cisco 3600 and the ALG stuff has rewritten the IPs (ie, the 10.3.0.221 address).
Regards, Paul
U 2005/03/14 16:01:19.932196 69.200.205.122:5060 -> 10.3.0.221:5060 INVITE sip:9195531888@66.243.109.99:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP 69.200.205.122:5060;branch=z9hG4bK2434592534. Route: sip:10.3.0.221;ftag=10000000-0-1811969809;lr. Route: sip:216.229.127.60:5060;lr. From: 3475626630 sip:3475626630@66.243.109.99:5060;user=phone;tag=550070175. To: sip:9195531888@64.152.60.6;user=phone;tag=10000000-0-1811969809. Call-ID: 348926-3319820023-453493@66.243.109.99. CSeq: 1 INVITE. Contact: sip:3475626630@69.200.205.122:5060. max-forwards: 70. Allow: INVITE, ACK, OPTIONS, CANCEL, BYE. Content-Type: application/sdp. Content-Length: 171. . v=0. o=- 9528 3044 IN IP4 0.0.0.0. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 13456 RTP/AVP 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendonly. a=ptime:20.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks Klaus.
So have you come to the conclusion that these messages are not handled correctly due to a real bug in ser-0.9?
Regards, Paul
On Tue, 15 Mar 2005 11:04:03 +0100, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi Paul!
That something I also asked several times and no answer yet. In my experience, loose_route() is true if the request URI contains the "lr" paramter (message comes from a strict router). Nevertheless, the loose_route function will remove its own Route: header.
I solve the troubles by allowing t_relay for all messages with to-tag (in-dialog).
regards, klaus
Java Rockx wrote:
Hi All.
I just don't see why loose_route() returned FALSE for this INVITE message. Can anyone help?
This INVITE was sent from my SIP phone to my SER-0.9 proxy. The IPs look funny because our SER proxy sits behind a Cisco 3600 and the ALG stuff has rewritten the IPs (ie, the 10.3.0.221 address).
Regards, Paul
U 2005/03/14 16:01:19.932196 69.200.205.122:5060 -> 10.3.0.221:5060 INVITE sip:9195531888@66.243.109.99:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP 69.200.205.122:5060;branch=z9hG4bK2434592534. Route: sip:10.3.0.221;ftag=10000000-0-1811969809;lr. Route: sip:216.229.127.60:5060;lr. From: 3475626630 sip:3475626630@66.243.109.99:5060;user=phone;tag=550070175. To: sip:9195531888@64.152.60.6;user=phone;tag=10000000-0-1811969809. Call-ID: 348926-3319820023-453493@66.243.109.99. CSeq: 1 INVITE. Contact: sip:3475626630@69.200.205.122:5060. max-forwards: 70. Allow: INVITE, ACK, OPTIONS, CANCEL, BYE. Content-Type: application/sdp. Content-Length: 171. . v=0. o=- 9528 3044 IN IP4 0.0.0.0. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 13456 RTP/AVP 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendonly. a=ptime:20.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Paul!
I wouldn't call it bug - let's call it a strange behaviour. I haven't done loose_route testing on 0.9.0, my experiences are from old times (0.8.12).
IMO loose_route() should be true for all in-dialog requests which were correctly sent to this SIP proxy (= the SIP proxy finds itself in the topmost route header or in the request URI), regardless if the previous hop was a strict router or a loose route, because there is no difference how this messages will be routed.
regards, klaus
Java Rockx wrote:
Thanks Klaus.
So have you come to the conclusion that these messages are not handled correctly due to a real bug in ser-0.9?
Regards, Paul
On Tue, 15 Mar 2005 11:04:03 +0100, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi Paul!
That something I also asked several times and no answer yet. In my experience, loose_route() is true if the request URI contains the "lr" paramter (message comes from a strict router). Nevertheless, the loose_route function will remove its own Route: header.
I solve the troubles by allowing t_relay for all messages with to-tag (in-dialog).
regards, klaus
Java Rockx wrote:
Hi All.
I just don't see why loose_route() returned FALSE for this INVITE message. Can anyone help?
This INVITE was sent from my SIP phone to my SER-0.9 proxy. The IPs look funny because our SER proxy sits behind a Cisco 3600 and the ALG stuff has rewritten the IPs (ie, the 10.3.0.221 address).
Regards, Paul
U 2005/03/14 16:01:19.932196 69.200.205.122:5060 -> 10.3.0.221:5060 INVITE sip:9195531888@66.243.109.99:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP 69.200.205.122:5060;branch=z9hG4bK2434592534. Route: sip:10.3.0.221;ftag=10000000-0-1811969809;lr. Route: sip:216.229.127.60:5060;lr. From: 3475626630 sip:3475626630@66.243.109.99:5060;user=phone;tag=550070175. To: sip:9195531888@64.152.60.6;user=phone;tag=10000000-0-1811969809. Call-ID: 348926-3319820023-453493@66.243.109.99. CSeq: 1 INVITE. Contact: sip:3475626630@69.200.205.122:5060. max-forwards: 70. Allow: INVITE, ACK, OPTIONS, CANCEL, BYE. Content-Type: application/sdp. Content-Length: 171. . v=0. o=- 9528 3044 IN IP4 0.0.0.0. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 13456 RTP/AVP 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendonly. a=ptime:20.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Java Rockx -
Klaus Darilion