22 Jun
2005
22 Jun
'05
2:53 p.m.
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
22 Jun
22 Jun
5:02 p.m.
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.
5:38 p.m.
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(a)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.101<http://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(a)10.99.47.102.
CSeq: 300 INVITE.
Proxy-Authenticate: Digest
realm="sip.mycompany.com<http://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(a)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(a)10.99.47.102.
CSeq: 301 INVITE.
Contact: <sip:4075559999@10.99.47.102:5060>.
Proxy-Authorization: Digest username="4075559999",
realm="sip.mycompany.com<http://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.101<http://71.99.100.101>
.
From: 4075559999 <sip:4075559999@sip.mycompany.com>;tag=3734116179.
To: <sip:3215550000@sip.mycompany.com>.
Call-ID: 1206868322(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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.101<http://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(a)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(a)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(a)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(a)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(a)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(a)10.99.47.102.
CSeq: 301 ACK.
Content-Length: 0.
On 6/22/05, Jan Janak <jan(a)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.
6:39 p.m.
New subject: [Serusers] ser + sems + (radius+mysql)
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
9:54 p.m.
New subject: [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_machine/do…
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:13 p.m.
New subject: [Serusers] ser + sems + (radius+mysql)
Thanks but there are no information about Radius configuration!
-----Original Message-----
From: Stefan Sayer <sayer(a)fokus.fraunhofer.de>
To: a cairo <a.cairo(a)scsitalia.it>
Cc: serusers <serusers(a)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(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
10:14 p.m.
New subject: [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:
23 Jun
23 Jun
10:09 p.m.
New subject: [Serusers] ser + sems + (radius+mysql)
My radius work fine!
My problem is on sems module!
-----Original Message-----
From: "Bruno Lopes F. Cabral" <bruno(a)openline.com.br>
To: a cairo <a.cairo(a)scsitalia.it>
Cc: serusers <serusers(a)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: 
25 Aug
25 Aug
12:40 a.m.
New subject: [Serusers] 487 hop to hop????
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
8:47 a.m.
New subject: [Serusers] 487 hop to hop????
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:05 p.m.
New subject: [Serusers] 487 hop to hop????
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:09 p.m.
New subject: [Serusers] 487 hop to hop????
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:
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@upenn.edu
That's right! CANCEL and 487 are hob-by-hob,
if the corresponding
INVITE was forwarded stateful.
regards
klaus
Greg Fausak wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:30 p.m.
New subject: [Serusers] 487 hop to hop????
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:58 p.m.
New subject: [Serusers] 487 hop to hop????
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
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
Hi Greg!
Greg Fausak wrote:
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?
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(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
>
9:49 p.m.
New subject: [Serusers] 487 hop to hop????
At 04:58 PM 8/25/2005, Greg Fausak wrote:
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
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 Greg!
Greg Fausak wrote:
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? 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.
10:40 p.m.
New subject: [Serusers] 487 hop to hop????
On 8/25/05, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 04:58 PM 8/25/2005, Greg Fausak wrote:
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
greg(a)thursday.com
On Aug 25, 2005, at 9:30 AM, Klaus Darilion
wrote:
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 Greg!
Greg Fausak wrote:
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? 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.
11:39 p.m.
New subject: [Serusers] 487 hop to hop????
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
6:17 p.m.
New subject: [Serusers] 487 hop to hop????
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
6:52 p.m.
New subject: [Serusers] 487 hop to hop????
On 8/25/05, Juha Heinanen <jh(a)tutpro.com> wrote:
Greg Fausak writes:
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
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
--
Greg Fausak
greg(a)thursday.com
7:12 p.m.
New subject: [Serusers] 487 hop to hop????
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
8:21 p.m.
New subject: [Serusers] 487 hop to hop????
Juha Heinanen wrote:
Greg Fausak writes:
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
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
6831
days inactive
6895
days old
20 comments
10 participants
participants (10)
-
a cairo -
Bruno Lopes F. Cabral -
Greg Fausak -
Jan Janak -
Java Rockx -
Jiri Kuthan -
Juha Heinanen -
Klaus Darilion -
Stefan Sayer -
Steve Blair