17 Aug
2004
17 Aug
'04
10:04 a.m.
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....
--
Jonathan
17 Aug
17 Aug
9:18 p.m.
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....
11:46 p.m.
New subject: [Serusers] MSRTC DLL Bug with SER
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
18 Aug
18 Aug
12:43 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1:56 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER
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(a)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(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
>
>
>
--
Andrew Mee
Programmer
HealthShare
Level 3 80 Stamford Rd Indooroopilly QLD 4086 Australia
T +61 (0)7 3378 7575 F +61 (0)7 3878 9883 M 0415 9044 65 E andrew(a)healthshare.com.au W
www.healthshare.com.au
Disclaimer
The information in this e-mail is confidential and may be legally privileged. It is
intended solely for the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and unlawful. Despite our
best efforts, the sender and HealthShare makes no warranties that this e-mail is free of
infection by computer viruses or other contamination.
10:54 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER
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 -
23 Aug
23 Aug
2:49 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER --- More information, Possibly SER not RFC 3261 compliant??
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
3:57 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER --- More information, Possibly SER not RFC 3261 compliant??
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
5:06 a.m.
New subject: [Serusers] MSRTC DLL Bug with SER --- More information, Possibly SER not RFC 3261 compliant??
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:
--
Andrew Mee
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
7267
days inactive
7273
days old
8 comments
4 participants
participants (4)
-
Andrew Mee -
Jiri Kuthan -
Jonathan -
Klaus Darilion