Hello Everyone,
I am a newbie SER user.
I am working on a chat client application that supports VoIP and text chat (both single and multiparty IM). I am using Microsoft's RTCDLL with SER.
My question is, is there an issue with regards to using RTCDLL with SER and using TCP as the transfer protocol? I asked this because if i specify UDP as the transfer protocol im using for both the proxy and registrar, text chat works just fine. If i change either of the settings to TCP, i get the 481 error (Call Leg transaction does not exist) whenever the contacted UA tries to send back message (reply) to the caller/initiator of the text chat.
The following are the infos relevant to my system setup
OS version is : Linux Redhat 9
Version: ser 0.8.12 ( i 386/linux)
flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
@(#) $ld:main.c.v 1.168 2003/10/12 15:09:08 andrei Exp $ main.c compiled on 13:09:22 Nov 21 2003 with gcc 2.95
ser config file
# # $Id: ser.cfg,v 1.21.2.1 2003/07/30 16:46:18 andrei Exp $ # # simple quick-start config script #
# ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode debug=3 fork=yes log_stderror=no */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" sip_warning=yes server_signature=yes uid="adrian" gid="adrian" listen=192.168.10.38 listen=127.0.0.1
# hostname matching an alias will satisfy the condition uri==myself". alias=gandalf.hq1.astra.ph #alias=hq1.astra.ph alias=192.168.10.38 # ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so" loadmodule "/usr/lib/ser/modules/sl.so" loadmodule "/usr/lib/ser/modules/tm.so" loadmodule "/usr/lib/ser/modules/rr.so" loadmodule "/usr/lib/ser/modules/maxfwd.so" loadmodule "/usr/lib/ser/modules/usrloc.so" loadmodule "/usr/lib/ser/modules/registrar.so" loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_db.so" loadmodule "/usr/lib/ser/modules/acc.so" loadmodule "/usr/lib/ser/modules/exec.so" loadmodule "/usr/lib/ser/modules/group.so" loadmodule "/usr/lib/ser/modules/print.so" loadmodule "/usr/lib/ser/modules/textops.so" loadmodule "/usr/lib/ser/modules/uri.so" loadmodule "/usr/lib/ser/modules/pa.so"
# ----------------- setting module-specific parameters --------------- # ------------- tm parameters
modparam("tm", "fr_timer", 10) modparam("tm", "fr_inv_timer", 20)
# ------------- rr parameters
# set ";lr" tag to “;lr=trueâ€<9d> modparam("rr", "enable_full_lr", 1)
# ------------- accounting parameters modparam("acc", "log_missed_flag", 3) modparam("acc", "log_level", 1) modparam("acc", "log_flag", 1)
# ------------- usrloc parameters
# 2 enables write-back to persistent mysql storage for speed # disable=0, write-through=1 modparam("usrloc", "db_mode", 0)
# minimize write back window - default is 60 seconds modparam("usrloc", "timer_interval", 10)
# database location modparam("usrloc", "db_url", "sql://ser:heslo@localhost/ser")
# ------------- auth parameters
# database location modparam("auth_db", "db_url", "sql://ser:heslo@localhost/ser")
# allows clear text passwords in the mysql database modparam("auth_db", "calculate_ha1",1)# yes)
# name of password column in mysql database modparam("auth_db", "password_column", "password")
# pa initialization #modparam("pa", "default_expires", 3600)
# ------------------------- request routing logic ------------------- # main routing logic
route{
# initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol record_route(); # loose-route processing if (loose_route()) { t_relay(); break; }; lookup("aliases"); # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication if (!www_authorize("gandalf.hq1.astra.ph", "subscriber")) { www_challenge("gandalf.hq1.astra.ph", "1"); break; };
# only registered users are allowed # if (!is_user("replicator") & !check_to()) { # log(1, "LOG: unregistered user registration # attempt\n"); # sl_send_reply("403", "Only registered users are # allowed"); # break; # };
# it is an authenticated request, update Contact # database now # if (!save("location")) { # sl_reply_error(); # };
save("location"); break; };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; };
#if(t_newtran()){ # if (method=="SUBSCRIBE" || method=="PUBLISH"){ # handle_subscription("registrar"); # break; # }; #};
# forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); };
}
end of config file
As i said before, if i use UDP as my transport protocol, everything works fine....the call initiator can send messages and the receiver can reply back.
But when i use TCP, even if the call initiator can still send messages like before without any problem, the other client UA (receiver) cannot send messages back anymore....here is the sample captured SIP Messages when the caller sends text chat messages.
T 192.168.10.42:1283 -> 192.168.10.38:5060 [AP] MESSAGE sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on SIP/2.0..Via: SIP/2.0/TCP 192.1 68.10.42:14457..Max-Forwards: 70..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=b f0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c1138152 e1221e@192.168.10.42..CSeq: 3 MESSAGE..Route: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..C ontact: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp..User-Agent: RTC/1.2..Content-Type: text/ enriched; charset=UTF-8..Content-Length: 230....{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0 Ar ial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewkind4\uc1\pard\cf1\b\fs18 jon : \cf0\b0\fs1 6 hello po\par..\pard\f1\fs17\par..}.. ########## T 192.168.10.38:33101 -> 192.168.10.27:11818 [AP] MESSAGE sip:192.168.10.27:11818;transport=tcp SIP/2.0..Record-Route: <sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7 dc9c41d799d979d8aa40b6ef;lr=on>..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKd26d.d1049a22.4;i=01..Via: SIP/2.0/TCP 192 .168.10.42:14457..Max-Forwards: 69..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid =bf0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c11381 52e1221e@192.168.10.42..CSeq: 3 MESSAGE..Contact: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp ..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 230....{\rtf1\ansi\ansicpg1252\deff0\ deflang1033{\fonttbl{\f0\fnil\fcharset0 Arial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewk ind4\uc1\pard\cf1\b\fs18 jon : \cf0\b0\fs16 hello po\par..\pard\f1\fs17\par..}.. # T 192.168.10.27:11818 -> 192.168.10.38:33101 [AP] SIP/2.0 200 OK..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKd26d.d1049a22.4;i=01..Via: SIP/2.0/TCP 192.168.10.42:14457. .From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..To: <sip:rose@gandalf. hq1.astra.ph>;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 3 MES SAGE..Contact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..User-Agent: RTC/1.2..Content-Len gth: 0.... ## T 192.168.10.38:5060 -> 192.168.10.42:1283 [AP] SIP/2.0 200 OK..Via: SIP/2.0/TCP 192.168.10.42:14457..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d 979d8aa40b6ef;epid=bf0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e42568 63ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 3 MESSAGE..Contact: <sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.1 0.27;transport=tcp>..User-Agent: RTC/1.2..Content-Length: 0....
______________________________________________________________
And here is the sample SIP captured message if the receiver tries to reply back to the caller....the one with the 481 error
T 192.168.10.27:1077 -> 192.168.10.38:5060 [AP] MESSAGE sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on SIP/2.0..Via: SIP/2.0/TCP 192.1 68.10.27:11818..Max-Forwards: 70..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c1138152 e1221e@192.168.10.42..CSeq: 1 MESSAGE..Route: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp..Co ntact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..User-Agent: RTC/1.2..Content-Type: text/ enriched; charset=UTF-8..Content-Length: 249....{\rtf1\ansi\ansicpg1252\deff0\deflang13321{\fonttbl{\f0\fnil\fcharset0 A rial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewkind4\uc1\pard\cf1\b\fs18 rose : \cf0\b0\f s16 r\lang1033 eply\par..\pard\lang13321\f1\fs17\par..}.. ########## T 192.168.10.38:33101 -> 192.168.10.27:11818 [AP] MESSAGE sip:192.168.10.27:11818;transport=tcp SIP/2.0..Record-Route: <sip:rose@192.168.10.38;transport=tcp;ftag=0ce6d678 daf24305a094f59a177bdac7;lr=on>..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKf26d.b82505f.4;i=11..Via: SIP/2.0/TCP 192. 168.10.27:11818..Max-Forwards: 69..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c113815 2e1221e@192.168.10.42..CSeq: 1 MESSAGE..Contact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp ..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 249....{\rtf1\ansi\ansicpg1252\deff0\ deflang13321{\fonttbl{\f0\fnil\fcharset0 Arial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\view kind4\uc1\pard\cf1\b\fs18 rose : \cf0\b0\fs16 r\lang1033 eply\par..\pard\lang13321\f1\fs17\par..}.. ## T 192.168.10.38:5060 -> 192.168.10.27:1077 [AP] SIP/2.0 408 Request Timeout..Via: SIP/2.0/TCP 192.168.10.27:11818..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf 24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Ca ll-ID: e4256863ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 1 MESSAGE..Server: Sip EXpress router (0.8.11 (i386/linux)) ..Content-Length: 0..Warning: 392 192.168.10.38:5060 "Noisy feedback tells: pid=5107 req_src_ip=192.168.10.27 req_src_p ort=1077 in_uri=sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on out_uri=sip:192.168.10. 27:9287;transport=tcp via_cnt==0".... ## T 192.168.10.27:11818 -> 192.168.10.38:33101 [AP] SIP/2.0 481 Call Leg/Transaction Does Not Exist..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKf26d.b82505f.4;i=11..Via: SIP/2.0/TCP 192.168.10.27:11818..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" < sip:jon@gandalf.hq1.astra.ph>;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c1138152e 1221e@192.168.10.42..CSeq: 1 MESSAGE..User-Agent: RTC/1.2..Content-Length: 0....
I have no clue as to why it behaves this way while it does not so using UDP. I don't know where the actual problem lies although i am biased that more likely, it is microsoft's fault. ^_^
Please enlighten me, anything would greatly help.
Many thanks in advance....
Take a look at the email " BYE issues" from 12.8. Looks like Andrew Mee is having the same problem. Maybe he could solve it.
Klaus
Jonathan wrote:
Hello Everyone,
I am a newbie SER user.
I am working on a chat client application that supports VoIP and text chat (both single and multiparty IM). I am using Microsoft's RTCDLL with SER.
My question is, is there an issue with regards to using RTCDLL with SER and using TCP as the transfer protocol? I asked this because if i specify UDP as the transfer protocol im using for both the proxy and registrar, text chat works just fine. If i change either of the settings to TCP, i get the 481 error (Call Leg transaction does not exist) whenever the contacted UA tries to send back message (reply) to the caller/initiator of the text chat.
The following are the infos relevant to my system setup
OS version is : Linux Redhat 9
Version: ser 0.8.12 ( i 386/linux)
flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
@(#) $ld:main.c.v 1.168 2003/10/12 15:09:08 andrei Exp $ main.c compiled on 13:09:22 Nov 21 2003 with gcc 2.95
ser config file
# # $Id: ser.cfg,v 1.21.2.1 2003/07/30 16:46:18 andrei Exp $ # # simple quick-start config script #
# ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode debug=3 fork=yes log_stderror=no */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" sip_warning=yes server_signature=yes uid="adrian" gid="adrian" listen=192.168.10.38 listen=127.0.0.1
# hostname matching an alias will satisfy the condition uri==myself". alias=gandalf.hq1.astra.ph #alias=hq1.astra.ph alias=192.168.10.38 # ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so" loadmodule "/usr/lib/ser/modules/sl.so" loadmodule "/usr/lib/ser/modules/tm.so" loadmodule "/usr/lib/ser/modules/rr.so" loadmodule "/usr/lib/ser/modules/maxfwd.so" loadmodule "/usr/lib/ser/modules/usrloc.so" loadmodule "/usr/lib/ser/modules/registrar.so" loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_db.so" loadmodule "/usr/lib/ser/modules/acc.so" loadmodule "/usr/lib/ser/modules/exec.so" loadmodule "/usr/lib/ser/modules/group.so" loadmodule "/usr/lib/ser/modules/print.so" loadmodule "/usr/lib/ser/modules/textops.so" loadmodule "/usr/lib/ser/modules/uri.so" loadmodule "/usr/lib/ser/modules/pa.so"
# ----------------- setting module-specific parameters --------------- # ------------- tm parameters
modparam("tm", "fr_timer", 10) modparam("tm", "fr_inv_timer", 20)
# ------------- rr parameters
# set ";lr" tag to “;lr=trueâ€<9d> modparam("rr", "enable_full_lr", 1)
# ------------- accounting parameters modparam("acc", "log_missed_flag", 3) modparam("acc", "log_level", 1) modparam("acc", "log_flag", 1)
# ------------- usrloc parameters
# 2 enables write-back to persistent mysql storage for speed # disable=0, write-through=1 modparam("usrloc", "db_mode", 0)
# minimize write back window - default is 60 seconds modparam("usrloc", "timer_interval", 10)
# database location modparam("usrloc", "db_url", "sql://ser:heslo@localhost/ser")
# ------------- auth parameters
# database location modparam("auth_db", "db_url", "sql://ser:heslo@localhost/ser")
# allows clear text passwords in the mysql database modparam("auth_db", "calculate_ha1",1)# yes)
# name of password column in mysql database modparam("auth_db", "password_column", "password")
# pa initialization #modparam("pa", "default_expires", 3600)
# ------------------------- request routing logic ------------------- # main routing logic
route{
# initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol record_route(); # loose-route processing if (loose_route()) { t_relay(); break; }; lookup("aliases"); # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") {# Uncomment this if you want to use digest authentication if (!www_authorize("gandalf.hq1.astra.ph", "subscriber")) { www_challenge("gandalf.hq1.astra.ph", "1"); break; };
# only registered users are allowed # if (!is_user("replicator") & !check_to()) { # log(1, "LOG: unregistered user registration # attempt\n"); # sl_send_reply("403", "Only registered users are # allowed"); # break; # }; # it is an authenticated request, update Contact # database now # if (!save("location")) { # sl_reply_error(); # }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; #if(t_newtran()){ # if (method=="SUBSCRIBE" || method=="PUBLISH"){ # handle_subscription("registrar"); # break; # }; #}; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); };}
end of config file
As i said before, if i use UDP as my transport protocol, everything works fine....the call initiator can send messages and the receiver can reply back.
But when i use TCP, even if the call initiator can still send messages like before without any problem, the other client UA (receiver) cannot send messages back anymore....here is the sample captured SIP Messages when the caller sends text chat messages.
T 192.168.10.42:1283 -> 192.168.10.38:5060 [AP] MESSAGE sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on SIP/2.0..Via: SIP/2.0/TCP 192.1 68.10.42:14457..Max-Forwards: 70..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=b f0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c1138152 e1221e@192.168.10.42..CSeq: 3 MESSAGE..Route: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..C ontact: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp..User-Agent: RTC/1.2..Content-Type: text/ enriched; charset=UTF-8..Content-Length: 230....{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0 Ar ial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewkind4\uc1\pard\cf1\b\fs18 jon : \cf0\b0\fs1 6 hello po\par..\pard\f1\fs17\par..}.. ########## T 192.168.10.38:33101 -> 192.168.10.27:11818 [AP] MESSAGE sip:192.168.10.27:11818;transport=tcp SIP/2.0..Record-Route: <sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7 dc9c41d799d979d8aa40b6ef;lr=on>..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKd26d.d1049a22.4;i=01..Via: SIP/2.0/TCP 192 .168.10.42:14457..Max-Forwards: 69..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid =bf0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c11381 52e1221e@192.168.10.42..CSeq: 3 MESSAGE..Contact: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp ..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 230....{\rtf1\ansi\ansicpg1252\deff0\ deflang1033{\fonttbl{\f0\fnil\fcharset0 Arial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewk ind4\uc1\pard\cf1\b\fs18 jon : \cf0\b0\fs16 hello po\par..\pard\f1\fs17\par..}.. # T 192.168.10.27:11818 -> 192.168.10.38:33101 [AP] SIP/2.0 200 OK..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKd26d.d1049a22.4;i=01..Via: SIP/2.0/TCP 192.168.10.42:14457. .From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..To: <sip:rose@gandalf. hq1.astra.ph>;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e4256863ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 3 MES SAGE..Contact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..User-Agent: RTC/1.2..Content-Len gth: 0.... ## T 192.168.10.38:5060 -> 192.168.10.42:1283 [AP] SIP/2.0 200 OK..Via: SIP/2.0/TCP 192.168.10.42:14457..From: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d 979d8aa40b6ef;epid=bf0baf3a75..To: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..Call-ID: e42568 63ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 3 MESSAGE..Contact: <sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.1 0.27;transport=tcp>..User-Agent: RTC/1.2..Content-Length: 0....
And here is the sample SIP captured message if the receiver tries to reply back to the caller....the one with the 481 error
T 192.168.10.27:1077 -> 192.168.10.38:5060 [AP] MESSAGE sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on SIP/2.0..Via: SIP/2.0/TCP 192.1 68.10.27:11818..Max-Forwards: 70..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c1138152 e1221e@192.168.10.42..CSeq: 1 MESSAGE..Route: sip:jon@gandalf.hq1.astra.ph:14457;maddr=192.168.10.42;transport=tcp..Co ntact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp..User-Agent: RTC/1.2..Content-Type: text/ enriched; charset=UTF-8..Content-Length: 249....{\rtf1\ansi\ansicpg1252\deff0\deflang13321{\fonttbl{\f0\fnil\fcharset0 A rial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\viewkind4\uc1\pard\cf1\b\fs18 rose : \cf0\b0\f s16 r\lang1033 eply\par..\pard\lang13321\f1\fs17\par..}.. ########## T 192.168.10.38:33101 -> 192.168.10.27:11818 [AP] MESSAGE sip:192.168.10.27:11818;transport=tcp SIP/2.0..Record-Route: <sip:rose@192.168.10.38;transport=tcp;ftag=0ce6d678 daf24305a094f59a177bdac7;lr=on>..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKf26d.b82505f.4;i=11..Via: SIP/2.0/TCP 192. 168.10.27:11818..Max-Forwards: 69..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c113815 2e1221e@192.168.10.42..CSeq: 1 MESSAGE..Contact: sip:rose@gandalf.hq1.astra.ph:11818;maddr=192.168.10.27;transport=tcp ..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 249....{\rtf1\ansi\ansicpg1252\deff0\ deflang13321{\fonttbl{\f0\fnil\fcharset0 Arial;}{\f1\fnil\fcharset0 Tahoma;}}..{\colortbl ;\red0\green0\blue255;}..\view kind4\uc1\pard\cf1\b\fs18 rose : \cf0\b0\fs16 r\lang1033 eply\par..\pard\lang13321\f1\fs17\par..}.. ## T 192.168.10.38:5060 -> 192.168.10.27:1077 [AP] SIP/2.0 408 Request Timeout..Via: SIP/2.0/TCP 192.168.10.27:11818..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf 24305a094f59a177bdac7..To: "jon" sip:jon@gandalf.hq1.astra.ph;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Ca ll-ID: e4256863ae5e4c82b2c1138152e1221e@192.168.10.42..CSeq: 1 MESSAGE..Server: Sip EXpress router (0.8.11 (i386/linux)) ..Content-Length: 0..Warning: 392 192.168.10.38:5060 "Noisy feedback tells: pid=5107 req_src_ip=192.168.10.27 req_src_p ort=1077 in_uri=sip:rose@192.168.10.38;transport=tcp;ftag=c3366ad7dc9c41d799d979d8aa40b6ef;lr=on out_uri=sip:192.168.10. 27:9287;transport=tcp via_cnt==0".... ## T 192.168.10.27:11818 -> 192.168.10.38:33101 [AP] SIP/2.0 481 Call Leg/Transaction Does Not Exist..Via: SIP/2.0/TCP 192.168.10.38;branch=z9hG4bKf26d.b82505f.4;i=11..Via: SIP/2.0/TCP 192.168.10.27:11818..From: sip:rose@gandalf.hq1.astra.ph;tag=0ce6d678daf24305a094f59a177bdac7..To: "jon" < sip:jon@gandalf.hq1.astra.ph>;tag=c3366ad7dc9c41d799d979d8aa40b6ef;epid=bf0baf3a75..Call-ID: e4256863ae5e4c82b2c1138152e 1221e@192.168.10.42..CSeq: 1 MESSAGE..User-Agent: RTC/1.2..Content-Length: 0....
I have no clue as to why it behaves this way while it does not so using UDP. I don't know where the actual problem lies although i am biased that more likely, it is microsoft's fault. ^_^
Please enlighten me, anything would greatly help.
Many thanks in advance....
After much more discovery we have figured out what the issue is with the MS RTC 1.2 and SER.
This isn't so much as a bug with SER but with MS RTC 1.2, it is caused by MS RTC sending incorrect Request-URI in the headers. This only occurs in request routed mode from the callee end.
Take the example: RTC Client A SIP Server RTC Client B -----INVITE--------------> <----100 Trying----------- -----INVITE----------------> <----100 Trying------------- <----180 Ringing---------- <----180 Ringing------------ <----200 OK w/ INVITE----- <----200 OK w/ INVITE------- -----ACK-----------------> -----ACK------------------->
All is fine at this point, however now lets send a message from A to B: RTC Client A SIP Server RTC Client B ----MESSAGE b@server----> ----MESSAGE b@server----> <----200 OK ------------- <----200 OK --------------
All is still fine, However if we send a message back from B to A: RTC Client A SIP Server RTC Client B <----MESSAGE b@server---- -----MESSAGE b@server----> <----481 Call Leg/T DNE--- This is obvious because the SER server sees this message as needing to go back to B when it should be forwarded to A as per "8.1.1.1 Request-URI" of the rfc (as far as my understanding on this). This issue occurs with BYE commands and possibly other types of commands.
I might add the To: and From: header fields are correct.
Solution to this problem could (or is there an existing way) a module/control could be created that checks if the To: field doesn't equal the request-uri that the request-uri be changed to the information in the To: field?
Yes I agree that while this is a MS RTC problem, I figure this is going to be a better/quicker short term solution. I have not tested if this problem exists with other SIP servers.
I can send some ngrep logs if anyone likes?
Hello Andrew,
It seems im also being troubled by the problem you have perfectly put into words unlike the one in my email. ^_^
I just want to ask though, because when i use UDP as the protocol in my rtc profile, this problem does not occur and communication flow between user A and B goes smoothly.
Do you think there is an explanation behind that? Why would SER/RTCDLL combination work when it's under UDP and not when using TCP?
I really have no idea, just observations.
Any comments and/or ideas regarding this issue would greatly help.
Thanks alot in advance.
- Jonathan -
On Wed, 18 Aug 2004 09:46:05 +1000, Andrew Mee andrew@healthshare.net.au wrote:
After much more discovery we have figured out what the issue is with the MS RTC 1.2 and SER.
This isn't so much as a bug with SER but with MS RTC 1.2, it is caused by MS RTC sending incorrect Request-URI in the headers. This only occurs in request routed mode from the callee end.
Take the example: RTC Client A SIP Server RTC Client B -----INVITE--------------> <----100 Trying----------- -----INVITE----------------> <----100 Trying------------- <----180 Ringing---------- <----180 Ringing------------ <----200 OK w/ INVITE----- <----200 OK w/ INVITE------- -----ACK-----------------> -----ACK------------------->
All is fine at this point, however now lets send a message from A to B: RTC Client A SIP Server RTC Client B ----MESSAGE b@server----> ----MESSAGE b@server----> <----200 OK ------------- <----200 OK --------------
All is still fine, However if we send a message back from B to A: RTC Client A SIP Server RTC Client B <----MESSAGE b@server---- -----MESSAGE b@server----> <----481 Call Leg/T DNE--- This is obvious because the SER server sees this message as needing to go back to B when it should be forwarded to A as per "8.1.1.1 Request-URI" of the rfc (as far as my understanding on this). This issue occurs with BYE commands and possibly other types of commands.
I might add the To: and From: header fields are correct.
Solution to this problem could (or is there an existing way) a module/control could be created that checks if the To: field doesn't equal the request-uri that the request-uri be changed to the information in the To: field?
Yes I agree that while this is a MS RTC problem, I figure this is going to be a better/quicker short term solution. I have not tested if this problem exists with other SIP servers.
I can send some ngrep logs if anyone likes?
-- Andrew Mee
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I haven't looked into UDP yet as I have a TCP requirement..... however I will look into it further.. Although I'm wondering does UDP use record_route? Hmmmm.... I found that if the mode was set to loose routing (TCP) the problem didn't occur because the UA sent the messages directly to each other, is this what you see? Does the UDP set the request-uri properly? you should be able to see this in your ngrep/ethereal.
How good is your C programming :) a 'correcting module' under 'rr.so' would be my recommendation...
Andrew
Jonathan wrote:
Hello Andrew,
It seems im also being troubled by the problem you have perfectly put into words unlike the one in my email. ^_^
I just want to ask though, because when i use UDP as the protocol in my rtc profile, this problem does not occur and communication flow between user A and B goes smoothly.
Do you think there is an explanation behind that? Why would SER/RTCDLL combination work when it's under UDP and not when using TCP?
I really have no idea, just observations.
Any comments and/or ideas regarding this issue would greatly help.
Thanks alot in advance.
- Jonathan -
On Wed, 18 Aug 2004 09:46:05 +1000, Andrew Mee andrew@healthshare.net.au wrote:
After much more discovery we have figured out what the issue is with the MS RTC 1.2 and SER.
This isn't so much as a bug with SER but with MS RTC 1.2, it is caused by MS RTC sending incorrect Request-URI in the headers. This only occurs in request routed mode from the callee end.
Take the example: RTC Client A SIP Server RTC Client B -----INVITE--------------> <----100 Trying----------- -----INVITE----------------> <----100 Trying------------- <----180 Ringing---------- <----180 Ringing------------ <----200 OK w/ INVITE----- <----200 OK w/ INVITE------- -----ACK-----------------> -----ACK------------------->
All is fine at this point, however now lets send a message from A to B: RTC Client A SIP Server RTC Client B ----MESSAGE b@server----> ----MESSAGE b@server----> <----200 OK ------------- <----200 OK --------------
All is still fine, However if we send a message back from B to A: RTC Client A SIP Server RTC Client B <----MESSAGE b@server---- -----MESSAGE b@server----> <----481 Call Leg/T DNE--- This is obvious because the SER server sees this message as needing to go back to B when it should be forwarded to A as per "8.1.1.1 Request-URI" of the rfc (as far as my understanding on this). This issue occurs with BYE commands and possibly other types of commands.
I might add the To: and From: header fields are correct.
Solution to this problem could (or is there an existing way) a module/control could be created that checks if the To: field doesn't equal the request-uri that the request-uri be changed to the information in the To: field?
Yes I agree that while this is a MS RTC problem, I figure this is going to be a better/quicker short term solution. I have not tested if this problem exists with other SIP servers.
I can send some ngrep logs if anyone likes?
-- Andrew Mee
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Yes, when i use UDP, SER sets the request-uri properly it seems (or i don't know, maybe RTC does something that causes SER to recognize the correct address). And still yes, UDP uses record_route. I've tried removing record route and hence putting the two UAs in peer-to-peer session.....and TCP did work fine this way.
But still, i have no idea why it shouldn't work with record_route (TCP) while it does so with UDP. >_<;;
Here's another sample SIP Message capture, this time showing the UDP packets.
First, the UA that initiated the call sends a message _______________________________________________________
# U 192.168.10.42:4461 -> 192.168.10.38:5060 MESSAGE sip:jon@gandalf.hq1.astra.ph SIP/2.0..Via: SIP/2.0/UDP 192.168.10.42:16054..Max-Forwards: 70..From: "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..To: sip:jon@gandalf.hq1.astra.ph. .Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..Contact: sip:192.168.10.42:16054..User-Agen t: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 227...."My Message Here" # U 192.168.10.38:5060 -> 192.168.10.27:14412 MESSAGE sip:192.168.10.27:14412 SIP/2.0..Record-Route: <sip:jon@192.168.10.38;ftag=ce10eb946c934f1f9c14812bd35adfa9;lr=o n>..Via: SIP/2.0/UDP 192.168.10.38;branch=z9hG4bKbaba.47427281.0..Via: SIP/2.0/UDP 192.168.10.42:16054..Max-Forwards: 69 ..From: "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..To: <sip:jon@ga ndalf.hq1.astra.ph>..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..Contact: <sip:192.168.10. 42:16054>..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content-Length: 227...."Message Here" # U 192.168.10.27:4671 -> 192.168.10.38:5060 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 192.168.10.38;branch=z9hG4bKbaba.47427281.0..Via: SIP/2.0/UDP 192.168.10.42:16054.. From: "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..To: <sip:jon@gand alf.hq1.astra.ph>;tag=805b3c1efca340598f2b00bf297b58dd..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..User-Agent: RTC/1.2..Content-Length: 0.... # U 192.168.10.27:4671 -> 192.168.10.38:5060 SIP/2.0 200 OK..Via: SIP/2.0/UDP 192.168.10.38;branch=z9hG4bKbaba.47427281.0..Via: SIP/2.0/UDP 192.168.10.42:16054..From : "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..To: <sip:jon@gandalf. hq1.astra.ph>;tag=805b3c1efca340598f2b00bf297b58dd..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MES SAGE..Record-Route: sip:jon@192.168.10.38;ftag=ce10eb946c934f1f9c14812bd35adfa9;lr=on..Contact: <sip:192.168.10.27:144 12>..User-Agent: RTC/1.2..Content-Length: 0.... # U 192.168.10.38:5060 -> 192.168.10.42:16054 SIP/2.0 200 OK..Via: SIP/2.0/UDP 192.168.10.42:16054..From: "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934 f1f9c14812bd35adfa9;epid=90fbe8b22b..To: sip:jon@gandalf.hq1.astra.ph;tag=805b3c1efca340598f2b00bf297b58dd..Call-ID: b f67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..Record-Route: <sip:jon@192.168.10.38;ftag=ce10eb946c934f 1f9c14812bd35adfa9;lr=on>..Contact: sip:192.168.10.27:14412..User-Agent: RTC/1.2..Content-Length: 0.... # _______________________________________________________
This one is the SIP messages from the other UA replying to the caller _______________________________________________________
U 192.168.10.27:4671 -> 192.168.10.38:5060 MESSAGE sip:jon@192.168.10.38;ftag=ce10eb946c934f1f9c14812bd35adfa9;lr=on SIP/2.0..Via: SIP/2.0/UDP 192.168.10.27:14412. .Max-Forwards: 70..From: sip:jon@gandalf.hq1.astra.ph;tag=805b3c1efca340598f2b00bf297b58dd..To: "adrian" <sip:adrian@g andalf.hq1.astra.ph>;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192 .168.10.42..CSeq: 1 MESSAGE..Route: sip:192.168.10.42:16054..Contact: sip:192.168.10.27:14412..User-Agent: RTC/1.2.. Content-Type: text/enriched; charset=UTF-8..Content-Length: 258...."Message here"
# U 192.168.10.38:5060 -> 192.168.10.42:16054 MESSAGE sip:192.168.10.42:16054 SIP/2.0..Record-Route: <sip:jon@192.168.10.38;ftag=805b3c1efca340598f2b00bf297b58dd;lr=o n>..Via: SIP/2.0/UDP 192.168.10.38;branch=z9hG4bKbaba.57427281.0..Via: SIP/2.0/UDP 192.168.10.27:14412..Max-Forwards: 69 ..From: sip:jon@gandalf.hq1.astra.ph;tag=805b3c1efca340598f2b00bf297b58dd..To: "adrian" <sip:adrian@gandalf.hq1.astra. ph>;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..Contact: sip:192.168.10.27:14412..User-Agent: RTC/1.2..Content-Type: text/enriched; charset=UTF-8..Content -Length: 258...."Message Here"
# U 192.168.10.42:4461 -> 192.168.10.38:5060 SIP/2.0 200 OK..Via: SIP/2.0/UDP 192.168.10.38;branch=z9hG4bKbaba.57427281.0..Via: SIP/2.0/UDP 192.168.10.27:14412..From : sip:jon@gandalf.hq1.astra.ph;tag=805b3c1efca340598f2b00bf297b58dd..To: "adrian" sip:adrian@gandalf.hq1.astra.ph;ta g=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..Call-ID: bf67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MES SAGE..Contact: sip:192.168.10.42:16054..User-Agent: RTC/1.2..Content-Length: 0.... # U 192.168.10.38:5060 -> 192.168.10.27:14412 SIP/2.0 200 OK..Via: SIP/2.0/UDP 192.168.10.27:14412..From: sip:jon@gandalf.hq1.astra.ph;tag=805b3c1efca340598f2b00bf2 97b58dd..To: "adrian" sip:adrian@gandalf.hq1.astra.ph;tag=ce10eb946c934f1f9c14812bd35adfa9;epid=90fbe8b22b..Call-ID: b f67cf236e954ebda981f07d8f28b7dd@192.168.10.42..CSeq: 1 MESSAGE..Contact: sip:192.168.10.42:16054..User-Agent: RTC/1.2. .Content-Length: 0....
____________________________________________________
Let me know if you'd find something else about the TCP bug using record_route. ^_^
Id really appreciate it. i'll see what i can do about the checking module in rr.so but Im not sure my C skills are up to the task of touching SER's modules, it's been many years since i last programmed in C. ^_^;;
Thanks for the bits of information and help you gave. It made the issue clearer.
- Jonathan -
From MS RTC Newsgroup:
...The issue here is that the BYE sent by test1 gets routed back to test1. This is because RTC1.2 does strict routing. However, on the proxy on the other hand does only loose routing and does not provide backward compatibility as provisioned in RFC 3261. Test1 receives this BYE out of the blue and a result sends a 481....
According to RFC 3261:
16.4 Route Information Preprocessing
The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request.
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1).
This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear.
......
I am trying to write a patch to fix this and I am having limited success, perhaps someone would be better at this?
please send your config file and complete message dumps. Actually SER should handle obsoleted RFC2543 record-routing too.
-jiri
At 04:49 AM 8/23/2004, Andrew Mee wrote:
From MS RTC Newsgroup:
...The issue here is that the BYE sent by test1 gets routed back to test1. This is because RTC1.2 does strict routing. However, on the proxy on the other hand does only loose routing and does not provide backward compatibility as provisioned in RFC 3261. Test1 receives this BYE out of the blue and a result sends a 481....
According to RFC 3261:
16.4 Route Information Preprocessing
The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request.
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1). This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear.......
I am trying to write a patch to fix this and I am having limited success, perhaps someone would be better at this?
-- Andrew Mee
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
See the following threads: There are some logs in these as well as some examples of what does and doesn't work. http://lists.iptel.org/pipermail/serusers/2004-August/010582.html http://lists.iptel.org/pipermail/serusers/2004-August/010708.html If this isn't enough info I can get some more for you I'm not the only one with this issue ;) I use the example config with Proxy_auth and record_route enabled.
Andrew
Jiri Kuthan wrote:
please send your config file and complete message dumps. Actually SER should handle obsoleted RFC2543 record-routing too.
-jiri
At 04:49 AM 8/23/2004, Andrew Mee wrote:
From MS RTC Newsgroup:
...The issue here is that the BYE sent by test1 gets routed back to test1. This is because RTC1.2 does strict routing. However, on the proxy on the other hand does only loose routing and does not provide backward compatibility as provisioned in RFC 3261. Test1 receives this BYE out of the blue and a result sends a 481....
According to RFC 3261:
16.4 Route Information Preprocessing
The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request.
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1).
This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear.
......
I am trying to write a patch to fix this and I am having limited success, perhaps someone would be better at this?
-- Andrew Mee
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-
Andrew Mee -
Jiri Kuthan -
Jonathan -
Klaus Darilion