Hi All.
I'm using t_check_status() to do call forwarding on 486 Busy responses. I have an odd thing happening where SER receives the 486 Busy message (for which SER properly sends an ACK response) and then the failure_route calls append_branch() and t_relay() to try another destination.
After the new leg of the call is setup and then torn down, the original 486 Busy seems to be hung in the tm module, because it magically appears in ngrep, which shows it being sent back to the caller as if the append_branch() never took place.
Is there anything special that I should be doing to "swallow" the 486 Busy response to prevent it from being sent to the caller UA?
Regards, Paul
On 22-06-2005 08:53, Java Rockx wrote:
Hi All.
I'm using t_check_status() to do call forwarding on 486 Busy responses. I have an odd thing happening where SER receives the 486 Busy message (for which SER properly sends an ACK response) and then the failure_route calls append_branch() and t_relay() to try another destination.
After the new leg of the call is setup and then torn down, the original 486 Busy seems to be hung in the tm module, because it magically appears in ngrep, which shows it being sent back to the caller as if the append_branch() never took place.
Is there anything special that I should be doing to "swallow" the 486 Busy response to prevent it from being sent to the caller UA?
What was the reply received on the new leg ? Did you setup failure_route again for the new leg ?
Jan.
Jan,
The failure_route is set up for the new leg. In this test, I cancelled the call before the new leg was set up. Below is the SIP message log for the call. It does show everything worked properly (as far as I can tell). The only funny thing is the very last two (2) messages are the Busy/ACK which were from the original leg of the call.
Regards, Paul
U 2005/06/22 11:30:09.877341 71.99.100.101:1105 http://71.99.100.101:1105-> 10.2.20.21:5060 http://10.2.20.21:5060 INVITE sip:3215550000@sip.mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK845928821. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 300 INVITE. Contact: sip:4075559999@10.99.47.102:5060. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 178. . v=0. o=- 10231 3023 IN IP4 10.99.47.102 http://10.99.47.102. s=-. c=IN IP4 10.99.47.102 http://10.99.47.102. t=0 0. m=audio 13456 RTP/AVP 0 8 2 4 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20.
U 2005/06/22 11:30:09.886368 10.2.20.21:5060 http://10.2.20.21:5060 -> 71.99.100.101:1105 http://71.99.100.101:1105 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK845928821;rport=1105;received=71.99.100.101http://71.99.100.101 . From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag= 1fe477f7999553e49c27ea343e9a9216.a61e. Call-ID: 1206868322@10.99.47.102. CSeq: 300 INVITE. Proxy-Authenticate: Digest realm="sip.mycompany.comhttp://sip.mycompany.com", nonce="42b9852d9bf1f9e07dce81b5f490cd7db9c3a5cb", qop="auth". Content-Length: 0. .
U 2005/06/22 11:30:10.039330 71.99.100.101:1105 http://71.99.100.101:1105-> 10.2.20.21:5060 http://10.2.20.21:5060 ACK sip:3215550000@sip.mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK845928821. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag= 1fe477f7999553e49c27ea343e9a9216.a61e. Call-ID: 1206868322@10.99.47.102. CSeq: 300 ACK. Content-Length: 0. .
U 2005/06/22 11:30:10.161309 71.99.100.101:1105 http://71.99.100.101:1105-> 10.2.20.21:5060 http://10.2.20.21:5060 INVITE sip:3215550000@sip.mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. Contact: sip:4075559999@10.99.47.102:5060. Proxy-Authorization: Digest username="4075559999", realm="sip.mycompany.comhttp://sip.mycompany.com", nonce="42b9852d9bf1f9e07dce81b5f490cd7db9c3a5cb", uri=" sip:3215550000@sip.mycompany.com", response="4d1076d3f8b4e348ea1666ec45351a42", algorithm=MD5, cnonce="2bddf808d944c1ac18add98d49b8c031", qop=auth, nc=00000005. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 178. . v=0. o=- 10231 3023 IN IP4 10.99.47.102 http://10.99.47.102. s=-. c=IN IP4 10.99.47.102 http://10.99.47.102. t=0 0. m=audio 13456 RTP/AVP 0 8 2 4 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20.
U 2005/06/22 11:30:10.226992 10.2.20.21:5060 http://10.2.20.21:5060 -> 71.99.100.101:1105 http://71.99.100.101:1105 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK256996988;rport=1105;received=71.99.100.101http://71.99.100.101 . From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. Content-Length: 0. .
U 2005/06/22 11:30:10.227613 10.2.20.21:5060 http://10.2.20.21:5060 -> 66.90.46.29:9534 http://66.90.46.29:9534 INVITE sip:3215550000@66.90.46.29:9534;user=phone SIP/2.0. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. Contact: sip:4075559999@71.99.100.101:1105. max-forwards: 16. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 175. P-hint: Local Destination. . v=0. o=- 10231 3023 IN IP4 10.99.47.102 http://10.99.47.102. s=-. c=IN IP4 10.3.0.44 http://10.3.0.44. t=0 0. m=audio 36144 RTP/AVP 0 8 2 4 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20.
U 2005/06/22 11:30:10.356381 66.90.46.29:9534 http://66.90.46.29:9534 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.5.22 http://1.0.5.22. Content-Length: 0. .
U 2005/06/22 11:30:10.365636 66.90.46.29:9534 http://66.90.46.29:9534 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 486 Busy. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=6052578f448e8c60. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.5.22 http://1.0.5.22. Content-Length: 0. .
U 2005/06/22 11:30:10.366767 10.2.20.21:5060 http://10.2.20.21:5060 -> 66.90.46.29:9534 http://66.90.46.29:9534 ACK sip:3215550000@66.90.46.29:9534;user=phone SIP/2.0. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.0. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. Call-ID: 1206868322@10.99.47.102. To: sip:3215550000@sip.mycompany.com;tag=6052578f448e8c60. CSeq: 301 ACK. Content-Length: 0. .
U 2005/06/22 11:30:10.387854 10.2.20.21:5060 http://10.2.20.21:5060 -> 66.90.46.29:5060 http://66.90.46.29:5060 INVITE sip:3215591422@66.90.46.29:5060;user=phone SIP/2.0. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. Contact: sip:4075559999@71.99.100.101:1105. max-forwards: 16. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 175. P-hint: Local Destination. P-hint: Forward Busy. . v=0. o=- 10231 3023 IN IP4 10.99.47.102 http://10.99.47.102. s=-. c=IN IP4 10.3.0.44 http://10.3.0.44. t=0 0. m=audio 36144 RTP/AVP 0 8 2 4 18 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20.
U 2005/06/22 11:30:10.515511 66.90.46.29:5060 http://66.90.46.29:5060 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.6.3 http://1.0.6.3. Content-Length: 0. .
U 2005/06/22 11:30:10.524907 66.90.46.29:5060 http://66.90.46.29:5060 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=79fe39bbac0500c1. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.6.3 http://1.0.6.3. Content-Length: 0. .
U 2005/06/22 11:30:10.525545 10.2.20.21:5060 http://10.2.20.21:5060 -> 71.99.100.101:1105 http://71.99.100.101:1105 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=79fe39bbac0500c1. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.6.3 http://1.0.6.3. Content-Length: 0. .
U 2005/06/22 11:30:14.217891 71.99.100.101:1105 http://71.99.100.101:1105-> 10.2.20.21:5060 http://10.2.20.21:5060 CANCEL sip:3215550000@sip.mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 CANCEL. max-forwards: 70. Content-Length: 0. .
U 2005/06/22 11:30:14.231433 10.2.20.21:5060 http://10.2.20.21:5060 -> 66.90.46.29:5060 http://66.90.46.29:5060 CANCEL sip:3215591422@66.90.46.29:5060;user=phone SIP/2.0. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com. Call-ID: 1206868322@10.99.47.102. CSeq: 301 CANCEL. max-forwards: 16. Content-Length: 0. P-hint: Local Destination. .
U 2005/06/22 11:30:14.236203 10.2.20.21:5060 http://10.2.20.21:5060 -> 71.99.100.101:1105 http://71.99.100.101:1105 SIP/2.0 200 canceling. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK256996988;rport=1105;received=71.99.100.101http://71.99.100.101 . From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: <sip:3215550000@sip.mycompany.com
;tag=6310aaf6cb6aa68cca9add6fbfab6d5f-84ff.
Call-ID: 1206868322@10.99.47.102. CSeq: 301 CANCEL. Content-Length: 0. .
U 2005/06/22 11:30:14.357391 66.90.46.29:5060 http://66.90.46.29:5060 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=ea9d53a35f368d2c. Call-ID: 1206868322@10.99.47.102. CSeq: 301 CANCEL. User-Agent: Grandstream BT100 1.0.6.3 http://1.0.6.3. Contact: sip:3215591422@172.31.130.83;user=phone. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Supported: replaces. Content-Length: 0. .
U 2005/06/22 11:30:14.363088 66.90.46.29:5060 http://66.90.46.29:5060 -> 10.2.20.21:5060 http://10.2.20.21:5060 SIP/2.0 487 Request Cancelled. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=131981a71ac26bed. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.6.3 http://1.0.6.3. Content-Length: 0. .
U 2005/06/22 11:30:14.363534 10.2.20.21:5060 http://10.2.20.21:5060 -> 66.90.46.29:5060 http://66.90.46.29:5060 ACK sip:3215591422@66.90.46.29:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP 10.3.0.42 http://10.3.0.42;branch=z9hG4bK1cca.129837b2.1. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. Call-ID: 1206868322@10.99.47.102. To: sip:3215550000@sip.mycompany.com;tag=131981a71ac26bed. CSeq: 301 ACK. Content-Length: 0. .
U 2005/06/22 11:30:14.363910 10.2.20.21:5060 http://10.2.20.21:5060 -> 71.99.100.101:1105 http://71.99.100.101:1105 SIP/2.0 486 Busy. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;rport=1105;received=71.99.100.101 http://71.99.100.101 ;branch=z9hG4bK256996988. Record-Route: <sip:10.3.0.42:5060 http://10.3.0.42:5060;lr>. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=6052578f448e8c60. Call-ID: 1206868322@10.99.47.102. CSeq: 301 INVITE. User-Agent: Grandstream BT100 1.0.5.22 http://1.0.5.22. Content-Length: 0. .
U 2005/06/22 11:30:14.598784 71.99.100.101:1105 http://71.99.100.101:1105-> 10.2.20.21:5060 http://10.2.20.21:5060 ACK sip:3215550000@sip.mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.99.47.102:5060 http://10.99.47.102:5060 ;branch=z9hG4bK256996988. From: 4075559999 sip:4075559999@sip.mycompany.com;tag=3734116179. To: sip:3215550000@sip.mycompany.com;tag=6052578f448e8c60. Call-ID: 1206868322@10.99.47.102. CSeq: 301 ACK. Content-Length: 0.
On 6/22/05, Jan Janak jan@iptel.org wrote:
On 22-06-2005 08:53, Java Rockx wrote:
Hi All.
I'm using t_check_status() to do call forwarding on 486 Busy responses.
I
have an odd thing happening where SER receives the 486 Busy message (for which SER properly sends an ACK response) and then the failure_route
calls
append_branch() and t_relay() to try another destination.
After the new leg of the call is setup and then torn down, the original
486
Busy seems to be hung in the tm module, because it magically appears in ngrep, which shows it being sent back to the caller as if the append_branch() never took place.
Is there anything special that I should be doing to "swallow" the 486
Busy
response to prevent it from being sent to the caller UA?
What was the reply received on the new leg ? Did you setup failure_route again for the new leg ?
Jan.
How to configure sems with radius? How to configure fifo_db_url ? It's necessary to create a local mysql db on the server of the sems? I have ser+sems on a server and freeradius+mysql on another. Please help
Hello,
please have a look at the ser-sems configuration howto, this might get you started: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/sems/answer_machine/doc...
Stefan On Wed, 22 Jun 2005, a cairo wrote:
How to configure sems with radius? How to configure fifo_db_url ? It's necessary to create a local mysql db on the server of the sems? I have ser+sems on a server and freeradius+mysql on another. Please help
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks but there are no information about Radius configuration!
-----Original Message----- From: Stefan Sayer sayer@fokus.fraunhofer.de To: a cairo a.cairo@scsitalia.it Cc: serusers serusers@lists.iptel.org Date: Wed, 22 Jun 2005 21:54:41 +0200 (MEST) Subject: Re: [Serusers] ser + sems + (radius+mysql)
Hello,
please have a look at the ser-sems configuration howto, this might get you started: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/sems/answer_machin e/docs/Configure-Sems-Ser-HOWTO
Stefan On Wed, 22 Jun 2005, a cairo wrote:
How to configure sems with radius? How to configure fifo_db_url ? It's necessary to create a local mysql db on the server of the sems? I have ser+sems on a server and freeradius+mysql on another. Please help
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
There _is_ a RADIUS HOWTO on http://www.iptel.org/ser/
to configure the freeradius part I'd suggest you dig the list archive because examples were given here a lot.
a cairo wrote:
Thanks but there are no information about Radius configuration!
-----Original Message-----
please have a look at the ser-sems configuration howto, this might get you started:
My radius work fine! My problem is on sems module!
-----Original Message----- From: "Bruno Lopes F. Cabral" bruno@openline.com.br To: a cairo a.cairo@scsitalia.it Cc: serusers serusers@lists.iptel.org Date: Wed, 22 Jun 2005 17:14:28 -0300 Subject: Re: [Serusers] ser + sems + (radius+mysql)
There _is_ a RADIUS HOWTO on http://www.iptel.org/ser/
to configure the freeradius part I'd suggest you dig the list archive because examples were given here a lot.
a cairo wrote:
Thanks but there are no information about Radius configuration!
-----Original Message-----
please have a look at the ser-sems configuration howto, this might
get
you started:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it?
---greg
That's right! CANCEL and 487 are hob-by-hob, if the corresponding INVITE was forwarded stateful.
regards klaus
Greg Fausak wrote:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it?
---greg
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Howdy,
I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be accomplished with ser?
Thank you for your feedback,
Regards, ---greg
On Aug 25, 2005, at 1:47 AM, Klaus Darilion wrote:
That's right! CANCEL and 487 are hob-by-hob, if the corresponding INVITE was forwarded stateful.
regards klaus
Greg Fausak wrote:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it? ---greg _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
My understanding is that this response is sent by a user agent that has received a cancel message and also to the sender of the original invite.
Greg Fausak wrote:
Howdy,
I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be accomplished with ser?
Thank you for your feedback,
Regards, ---greg
On Aug 25, 2005, at 1:47 AM, Klaus Darilion wrote:
That's right! CANCEL and 487 are hob-by-hob, if the corresponding INVITE was forwarded stateful.
regards klaus
Greg Fausak wrote:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it? ---greg _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Greg!
Greg Fausak wrote:
Howdy,
I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
Imagine a forked call. If the call in canceled, ser has to wait for the 487 messages from all branches. Only after it received the 487 from all branches, it will send a 487 to the caller.
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be
What would be the difference if it would come end2end? The caller will receive a 487 which will match the call-id and from tag (I think the to-tag will be the to-tag of the last 487 received from called parties).
Thus, the caller can not distinghuish if it is generated from ser or from a caller.
regards klaus
accomplished with ser?
Thank you for your feedback,
Regards, ---greg
On Aug 25, 2005, at 1:47 AM, Klaus Darilion wrote:
That's right! CANCEL and 487 are hob-by-hob, if the corresponding INVITE was forwarded stateful.
regards klaus
Greg Fausak wrote:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it? ---greg _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
Hi Greg!
Greg Fausak wrote:
Howdy, I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
Imagine a forked call. If the call in canceled, ser has to wait for the 487 messages from all branches. Only after it received the 487 from all branches, it will send a 487 to the caller.
Using this logic ser has to wait for the 487 before it sends it to the caller. What I'm seeing is the 487 is sent straight away, right after the 200. Is this because the call is not forked? If it was forked I'd see the 487s come back to the ser proxy before the ser proxy sends it to the caller?
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be
What would be the difference if it would come end2end? The caller will receive a 487 which will match the call-id and from tag (I think the to-tag will be the to-tag of the last 487 received from called parties).
Thus, the caller can not distinghuish if it is generated from ser or from a caller.
I think that is the crux of the matter. The to-tag isn't available when the call is INVITEd.
So, the bottom line is a 487 is hop to hop, just like a cancel.
---greg
regards klaus
accomplished with ser? Thank you for your feedback, Regards, ---greg On Aug 25, 2005, at 1:47 AM, Klaus Darilion wrote:
That's right! CANCEL and 487 are hob-by-hob, if the corresponding INVITE was forwarded stateful.
regards klaus
Greg Fausak wrote:
I've got a call trace that shows an INVITE being CANCELed, the CANCEL is hop to hop. I had thought the 487 was generated at the other end and came all the way back, but my call traces indicate that the 487 is being generated hop to hop as well. That's not right, is it? ---greg _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 04:58 PM 8/25/2005, Greg Fausak wrote:
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
Hi Greg!
Greg Fausak wrote:
Howdy, I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
Imagine a forked call. If the call in canceled, ser has to wait for the 487 messages from all branches. Only after it received the 487 from all branches, it will send a 487 to the caller.
Using this logic ser has to wait for the 487 before it sends it to the caller. What I'm seeing is the 487 is sent straight away, right after the 200. Is this because the call is not forked? If it was forked I'd see the 487s come back to the ser proxy before the ser proxy sends it to the caller?
It does not care if the request is forked or not, it just sends the 487 straight. Which makes upstream clients better happy if one or more downstream servers don't respond to the CANCEL request.
One may argue whether this optimization is worth it or not, but in absence of counter-arguments I am not sure we should change it.
-Jiri
On 8/25/05, Jiri Kuthan jiri@iptel.org wrote:
At 04:58 PM 8/25/2005, Greg Fausak wrote:
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
Hi Greg!
Greg Fausak wrote:
Howdy, I've been scouring the RFCs looking for this verbiage. One of our developers here is telling me that is a mistake, that the 487 needs to come from the far end. Do you know where I might find more information about this topic?
Imagine a forked call. If the call in canceled, ser has to wait for the 487 messages from all branches. Only after it received the 487 from all branches, it will send a 487 to the caller.
Using this logic ser has to wait for the 487 before it sends it to the caller. What I'm seeing is the 487 is sent straight away, right after the 200. Is this because the call is not forked? If it was forked I'd see the 487s come back to the ser proxy before the ser proxy sends it to the caller?
It does not care if the request is forked or not, it just sends the 487 straight. Which makes upstream clients better happy if one or more downstream servers don't respond to the CANCEL request.
One may argue whether this optimization is worth it or not, but in absence of counter-arguments I am not sure we should change it.
-Jiri
Hi Jiri,
Hope all is well!
The main argument I'm getting is that the totag is different when the SER proxy responds to the CANCEL with a 200 and then a 487. The 487 totag does not match the original 183's totag. The Via/branch matches OK, but the developers here are relying on the totag to match the 487 to the INVITE/183 transaction, not the CANCEL 'transaction'.
Do you know what I'm talking about? What is your opinion? I can forward a call trace (ngrep) or ethereal if you want to see it.
Are you heading out to VON?
---greg
Greg Fausak wrote:
The main argument I'm getting is that the totag is different when the SER proxy responds to the CANCEL with a 200 and then a 487. The 487 totag does not match the original 183's totag. The Via/branch matches OK, but the developers here are relying on the totag to match the 487 to the INVITE/183 transaction, not the CANCEL 'transaction'.
section 12.3 Termination of a Dialog:
Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details.
Thus, the to-tag of the 487 is irrelevant, as 487 terminates all early dialogs of this request.
klaus
Do you know what I'm talking about? What is your opinion? I can forward a call trace (ngrep) or ethereal if you want to see it.
Are you heading out to VON?
---greg
Greg Fausak writes:
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be accomplished with ser?
ser is not responding to cancel with 487. response to cancel is 200 canceling. 487 is sent by uas when it receives a cancel to an invite to which it has not yet sent a final response.
now the question is what is the proper thing for statefull ser to do, when uac cancels an invite which is forked by ser to multiple destinations and some of the branches have already responded with final non 2xx reply.
currently in failure route ser.cfg sees the lowest numbered reply whereas ser itself responds to uac with 200 canceling and then with 487. in my opinion this makes no sense, because it makes failure route think that a uas was, for example, busy and acts accordingly. a better behavior would be if also failure route would see 487 as the final reply.
i'm currently experimenting with the following change to t_reply.c t_pick_branch to solve this problem:
for ( b=t->first_branch; b<t->nr_of_outgoings ; b++ ) { /* "fake" for the currently processed branch */ if (b==inc_branch) { if (inc_code == 487) { lowest_b=b; lowest_s=inc_code; break; } if (inc_code<lowest_s) { lowest_b=b; lowest_s=inc_code; } continue; } ...
-- juha
On 8/25/05, Juha Heinanen jh@tutpro.com wrote:
Greg Fausak writes:
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be accomplished with ser?
ser is not responding to cancel with 487. response to cancel is 200 canceling. 487 is sent by uas when it receives a cancel to an invite to which it has not yet sent a final response.
That's what I would think should happen. The 487 would come all the way from the UAS to the UAC. However, what I'm seeing is SER is responding with a 487 at each hop.
I am running t_relay between each hop, so, that's stateful.
I've attached an .rtf file of the trace overview, it shows the 183s coming end to end, from the uas to the uac, but the 487s are being generated by the ser proxies hop to hop.
I can eliminate that behaviour if I use 'forward' between proxies instead of t_relay. Maybe I just don't understand the implication of these ser commands. t_relay is a transaction/stateful, forward is not.
---greg
now the question is what is the proper thing for statefull ser to do, when uac cancels an invite which is forked by ser to multiple destinations and some of the branches have already responded with final non 2xx reply.
currently in failure route ser.cfg sees the lowest numbered reply whereas ser itself responds to uac with 200 canceling and then with 487. in my opinion this makes no sense, because it makes failure route think that a uas was, for example, busy and acts accordingly. a better behavior would be if also failure route would see 487 as the final reply.
i'm currently experimenting with the following change to t_reply.c t_pick_branch to solve this problem:
for ( b=t->first_branch; b<t->nr_of_outgoings ; b++ ) { /* "fake" for the currently processed branch */ if (b==inc_branch) { if (inc_code == 487) { lowest_b=b; lowest_s=inc_code; break; } if (inc_code<lowest_s) { lowest_b=b; lowest_s=inc_code; } continue; } ...-- juha
Greg Fausak writes:
The 487 would come all the way from the UAS to the UAC. However, what I'm seeing is SER is responding with a 487 at each hop.
it is correct behavior when ser is operating statefully.
I've attached an .rtf file of the trace overview, it shows the 183s coming end to end, from the uas to the uac, but the 487s are being generated by the ser proxies hop to hop.
that is correct, because even statefull proxy must forward provisional responses as is.
t_relay is a transaction/stateful, forward is not.
yes.
by the way, my test code didn't work. the problem is that ser receives 487s from the other branches also in case then ser itself cancels the other branches.
looks like the best solution would be a function that can be used in failure route to test if the transaction in question has been canceled by uac. i don't know if it currently possible to make such test.
-- juha
Juha Heinanen wrote:
Greg Fausak writes:
It seems to me that the ser proxy is responding to the cancel with a 487. If I had to make it come from the far end can that be accomplished with ser?
ser is not responding to cancel with 487. response to cancel is 200 canceling. 487 is sent by uas when it receives a cancel to an invite to which it has not yet sent a final response.
now the question is what is the proper thing for statefull ser to do, when uac cancels an invite which is forked by ser to multiple destinations and some of the branches have already responded with final non 2xx reply.
The behavior is defined in 3261 section 16.7, item 6 (page 110). It also states clearly: "3-6xx responses are delivered hop-by-hop."
regards klaus
currently in failure route ser.cfg sees the lowest numbered reply whereas ser itself responds to uac with 200 canceling and then with 487. in my opinion this makes no sense, because it makes failure route think that a uas was, for example, busy and acts accordingly. a better behavior would be if also failure route would see 487 as the final reply.
i'm currently experimenting with the following change to t_reply.c t_pick_branch to solve this problem:
for ( b=t->first_branch; b<t->nr_of_outgoings ; b++ ) { /* "fake" for the currently processed branch */ if (b==inc_branch) { if (inc_code == 487) { lowest_b=b; lowest_s=inc_code; break; } if (inc_code<lowest_s) { lowest_b=b; lowest_s=inc_code; } continue; } ...
-- juha
-
a cairo -
Bruno Lopes F. Cabral -
Greg Fausak -
Jan Janak -
Java Rockx -
Jiri Kuthan -
Juha Heinanen -
Klaus Darilion -
Stefan Sayer -
Steve Blair