I can't see any problem in the config file. Which clients do you use?
Put log(1,"...."); messages into your config and watch the logging messages in /var/log/messages during the CANCEL processing to find out where the CANCEL request is beeing lost.
Klaus
Kapil Dhawan wrote:
o its not happening...when first phone cancels the call....that CANCEL is not forwarded to callee phone
Regards
Dhawan K
---------- Original Message ----------- From: Klaus Darilion klaus.mailinglists@pernau.at To: abhati abhati@primus-direct.com Cc: serusers@lists.iptel.org Sent: Mon, 09 Feb 2004 16:22:34 +0100 Subject: Re: [Serusers] Cancel call Problem
What do mean by "gets hanged"? Watch the SIP call flow using ethereal: Are the CANCEL requests that arive at the proxy forwarded to the other SIP phone?
klaus
abhati wrote:
Hi All
My problem is...i have got two phones set 111 and 222. if i make call
from
111 and don't pick up 222 and cancel the call, this all is fine. but my
phone
gets hanged...both 111 and 222....what shud be done to properly handle
cancel
requests.
i am attaching my ser.cfg file.
# # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 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=7 fork=no log_stderror=yes */
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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/call.so"
modparam("domain", "db_url", "sql://root:root@localhost/ser") modparam("domain", "db_mode", 1) # Use chaching modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain")
modparam("tm", "fr_inv_timer", 30 ) modparam("registrar", "default_expires", 60) # ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2)
# -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter) # modparam("auth_db", "password_column", "password")
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- 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 ( msg:len > 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; };
# 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 (is_from_local()) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; };
# native SIP destinations are handled using our USRLOC DB if (method=="INVITE") { if(call()){ //written one module for few things works fine if (!lookup("location")) { sl_send_reply("404", "Not Found"); 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(); }; }
.
Disclaimer
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Recipients must check this email and any attachments for the presence of viruses before downloading them. Direct Internet / Primus India accepts no liability for any damage caused by any virus transmitted by this email.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
------- End of Original Message -------
.
Disclaimer
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Recipients must check this email and any attachments for the presence of viruses before downloading them. Direct Internet / Primus India accepts no liability for any damage caused by any virus transmitted by this email.
I see the exact same problem when making calls from a Sipura SPA-2000. The problem does not occur when calling from a Cisco ATA-186.
I've tried comparing the cancel messages between the 2 devices, but only found 1 difference. The ATA makes the INVITE and the cancel with user=phone appended, and the sipura does not. I'm not sure why that would make a difference, though, as long as the CANCEL matches the INVITE...
- Mike
On Mon, 9 Feb 2004, Klaus Darilion wrote:
I can't see any problem in the config file. Which clients do you use?
Put log(1,"...."); messages into your config and watch the logging messages in /var/log/messages during the CANCEL processing to find out where the CANCEL request is beeing lost.
Klaus
Kapil Dhawan wrote:
o its not happening...when first phone cancels the call....that CANCEL is not forwarded to callee phone
Regards
Dhawan K
---------- Original Message ----------- From: Klaus Darilion klaus.mailinglists@pernau.at To: abhati abhati@primus-direct.com Cc: serusers@lists.iptel.org Sent: Mon, 09 Feb 2004 16:22:34 +0100 Subject: Re: [Serusers] Cancel call Problem
What do mean by "gets hanged"? Watch the SIP call flow using ethereal: Are the CANCEL requests that arive at the proxy forwarded to the other SIP phone?
klaus
abhati wrote:
Hi All
My problem is...i have got two phones set 111 and 222. if i make call
from
111 and don't pick up 222 and cancel the call, this all is fine. but my
phone
gets hanged...both 111 and 222....what shud be done to properly handle
cancel
requests.
i am attaching my ser.cfg file.
# # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 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=7 fork=no log_stderror=yes */
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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/call.so"
modparam("domain", "db_url", "sql://root:root@localhost/ser") modparam("domain", "db_mode", 1) # Use chaching modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain")
modparam("tm", "fr_inv_timer", 30 ) modparam("registrar", "default_expires", 60) # ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2)
# -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter) # modparam("auth_db", "password_column", "password")
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- 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 ( msg:len > 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; };
# 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 (is_from_local()) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; };
# native SIP destinations are handled using our USRLOC DB if (method=="INVITE") { if(call()){ //written one module for few things works fine if (!lookup("location")) { sl_send_reply("404", "Not Found"); 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(); }; }
It is known problem with SPA-2000 - it violates RFC by inserting different branch parameter into the CANCEL compared to the same parameter in INVITE, which results in SER being unable to match CANCEL to INVITE. We have notified Siura support staff about this and are waiting for resolution.
-Maxim
Mike wrote:
I see the exact same problem when making calls from a Sipura SPA-2000. The problem does not occur when calling from a Cisco ATA-186.
I've tried comparing the cancel messages between the 2 devices, but only found 1 difference. The ATA makes the INVITE and the cancel with user=phone appended, and the sipura does not. I'm not sure why that would make a difference, though, as long as the CANCEL matches the INVITE...
- Mike
On Mon, 9 Feb 2004, Klaus Darilion wrote:
I can't see any problem in the config file. Which clients do you use?
Put log(1,"...."); messages into your config and watch the logging messages in /var/log/messages during the CANCEL processing to find out where the CANCEL request is beeing lost.
Klaus
Kapil Dhawan wrote:
o its not happening...when first phone cancels the call....that CANCEL is not forwarded to callee phone
Regards
Dhawan K
---------- Original Message ----------- From: Klaus Darilion klaus.mailinglists@pernau.at To: abhati abhati@primus-direct.com Cc: serusers@lists.iptel.org Sent: Mon, 09 Feb 2004 16:22:34 +0100 Subject: Re: [Serusers] Cancel call Problem
What do mean by "gets hanged"? Watch the SIP call flow using ethereal: Are the CANCEL requests that arive at the proxy forwarded to the other SIP phone?
klaus
abhati wrote:
Hi All
My problem is...i have got two phones set 111 and 222. if i make call
from
111 and don't pick up 222 and cancel the call, this all is fine. but my
phone
gets hanged...both 111 and 222....what shud be done to properly handle
cancel
requests.
i am attaching my ser.cfg file.
# # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 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=7 fork=no log_stderror=yes */
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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/call.so"
modparam("domain", "db_url", "sql://root:root@localhost/ser") modparam("domain", "db_mode", 1) # Use chaching modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain")
modparam("tm", "fr_inv_timer", 30 ) modparam("registrar", "default_expires", 60) # ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2)
# -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter) # modparam("auth_db", "password_column", "password")
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- 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 ( msg:len > 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; };
# 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 (is_from_local()) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; };
# native SIP destinations are handled using our USRLOC DB if (method=="INVITE") { if(call()){ //written one module for few things works fine if (!lookup("location")) { sl_send_reply("404", "Not Found"); 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(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
thx alot...this is really called wastage of time.....let me try with cisco ata.....thx and bye
Regards
Dhawan K
---------- Original Message ----------- From: Maxim Sobolev sobomax@portaone.com To: Mike voipguy@spam.turbolink.net Cc: Serusers serusers@lists.iptel.org Sent: Mon, 09 Feb 2004 21:57:04 +0200 Subject: Re: [Serusers] Cancel call Problem
It is known problem with SPA-2000 - it violates RFC by inserting different branch parameter into the CANCEL compared to the same parameter in INVITE, which results in SER being unable to match CANCEL to INVITE. We have notified Siura support staff about this and are waiting for resolution.
-Maxim
Mike wrote:
I see the exact same problem when making calls from a Sipura SPA-2000. The problem does not occur when calling from a Cisco ATA-186.
I've tried comparing the cancel messages between the 2 devices, but only found 1 difference. The ATA makes the INVITE and the cancel with user=phone appended, and the sipura does not. I'm not sure why that would make a difference, though, as long as the CANCEL matches the INVITE...
- Mike
On Mon, 9 Feb 2004, Klaus Darilion wrote:
I can't see any problem in the config file. Which clients do you use?
Put log(1,"...."); messages into your config and watch the logging messages in /var/log/messages during the CANCEL processing to find out where the CANCEL request is beeing lost.
Klaus
Kapil Dhawan wrote:
o its not happening...when first phone cancels the call....that CANCEL
is not
forwarded to callee phone
Regards
Dhawan K
---------- Original Message ----------- From: Klaus Darilion klaus.mailinglists@pernau.at To: abhati abhati@primus-direct.com Cc: serusers@lists.iptel.org Sent: Mon, 09 Feb 2004 16:22:34 +0100 Subject: Re: [Serusers] Cancel call Problem
What do mean by "gets hanged"? Watch the SIP call flow using ethereal: Are the CANCEL requests that arive at the proxy forwarded to the other SIP phone?
klaus
abhati wrote:
Hi All
My problem is...i have got two phones set 111 and 222. if i make call
from
111 and don't pick up 222 and cancel the call, this all is fine. but my
phone
gets hanged...both 111 and 222....what shud be done to properly handle
cancel
requests.
i am attaching my ser.cfg file.
# # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 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=7 fork=no log_stderror=yes */
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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/call.so"
modparam("domain", "db_url", "sql://root:root@localhost/ser") modparam("domain", "db_mode", 1) # Use chaching modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain")
modparam("tm", "fr_inv_timer", 30 ) modparam("registrar", "default_expires", 60) # ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2)
# -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter) # modparam("auth_db", "password_column", "password")
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- 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 ( msg:len > 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; };
# 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 (is_from_local()) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; };
# native SIP destinations are handled using our USRLOC DB if (method=="INVITE") { if(call()){ //written one module for few things works fine if (!lookup("location")) { sl_send_reply("404", "Not Found"); 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(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
------- End of Original Message -------
.
Disclaimer -------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Recipients must check this email and any attachments for the presence of viruses before downloading them. Direct Internet / Primus India accepts no liability for any damage caused by any virus transmitted by this email.
Following is the file when phone 111 calls 222 and call goes perfectly....
interface: eth0 (203.196.128.96/255.255.255.224) filter: ip and ( port 5060 ) match: 111@ # U 203.196.128.111:5060 -> 203.196.128.126:5060 INVITE sip:222@quckoo.com;user=phone SIP/2.0..Via:SIP/2.0/UDP 203.196.128.1 11:5060;branch=z9hG4bk7301e1fa200d7bb5806a493bf..From: <sip:111@quckoo.com; user=phone> ;tag=13757..To: sip:222@quckoo.com;user=phone..Call-ID:020431 29-19e5-4bc0-7ff9-00583b006c02@203.196.128.111..CSeq:1 INVITE..Contact: <si p:111@203.196.128.111:5060;user=phone;transport=udp>..Content-Type:applicat ion/sdp..Content-Length:270..Max-Forwards:72..Supported:timer..Session-Expi res:1800..Min-SE:1800....v=0..o=SS-TA101 4671 4671 IN IP4 203.196.128.111.. s=-..c=IN IP4 203.196.128.111..t=0 0..m=audio 23000 RTP/AVP 0 8 18 4 101..a =rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap: 4 G723-63/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-11.... # U 203.196.128.126:5060 -> 203.196.128.111:5060 SIP/2.0 100 trying -- your call is important to us..Via:SIP/2.0/UDP 203.196 .128.111:5060;branch=z9hG4bk7301e1fa200d7bb5806a493bf..From: <sip:111@qucko o.com;user=phone> ;tag=13757..To: sip:222@quckoo.com;user=phone..Call-ID: 02043129-19e5-4bc0-7ff9-00583b006c02@203.196.128.111..CSeq:1 INVITE..Server : Sip EXpress router (0.8.12 (i386/linux))..Content-Length: 0..Warning: 392 203.196.128.126:5060 "Noisy feedback tells: pid=8037 req_src_ip=203.196.1 28.111 req_src_port=5060 in_uri=sip:222@quckoo.com;user=phone out_uri=sip:2 22@203.196.128.121;user=phone via_cnt==1".... # U 203.196.128.126:5060 -> 203.196.128.121:5060 INVITE sip:222@203.196.128.121;user=phone SIP/2.0..Record-Route: <sip:222@2 03.196.128.126;ftag=13757;lr=on>..Via: SIP/2.0/UDP 203.196.128.126;branch=z 9hG4bK3c7a.9dbc7de4.0..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7 301e1fa200d7bb5806a493bf..From: sip:111@quckoo.com;user=phone ;tag=13757. .To: sip:222@quckoo.com;user=phone..Call-ID:02043129-19e5-4bc0-7ff9-00583 b006c02@203.196.128.111..CSeq:1 INVITE..Contact: <sip:111@203.196.128.111:5 060;user=phone;transport=udp>..Content-Type:application/sdp..Content-Length :270..Max-Forwards:71..Supported:timer..Session-Expires:1800..Min-SE:1800.. ..v=0..o=SS-TA101 4671 4671 IN IP4 203.196.128.111..s=-..c=IN IP4 203.196.1 28.111..t=0 0..m=audio 23000 RTP/AVP 0 8 18 4 101..a=rtpmap:0 PCMU/8000..a= rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:4 G723-63/8000..a=rtpma p:101 telephone-event/8000..a=fmtp:101 0-11.... # U 203.196.128.121:5060 -> 203.196.128.126:5060 SIP/2.0 100 Trying..Via:SIP/2.0/UDP 203.196.128.126;branch=z9hG4bK3c7a.9dbc 7de4.0..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7301e1fa200d7bb5 806a493bf..Record-Route: sip:222@203.196.128.126;ftag=13757;lr=on..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <sip:222@quckoo.com;user=ph one> ;tag=15400..CSeq:1 INVITE..Call-ID:02043129-19e5-4bc0-7ff9-00583b006c0 2@203.196.128.111..Content-Length:0.... # U 203.196.128.121:5060 -> 203.196.128.126:5060 SIP/2.0 180 Ringing..Via:SIP/2.0/UDP 203.196.128.126;branch=z9hG4bK3c7a.9db c7de4.0..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7301e1fa200d7bb 5806a493bf..Record-Route: sip:222@203.196.128.126;ftag=13757;lr=on..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <sip:222@quckoo.com;user=p hone> ;tag=15400..CSeq:1 INVITE..Call-ID:02043129-19e5-4bc0-7ff9-00583b006c 02@203.196.128.111..P-N-UAType:ip..Content-Length:0.... # U 203.196.128.126:5060 -> 203.196.128.111:5060 SIP/2.0 180 Ringing..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk730 1e1fa200d7bb5806a493bf..Record-Route: <sip:222@203.196.128.126;ftag=13757;l r=on>..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <sip:222@qucko o.com;user=phone> ;tag=15400..CSeq:1 INVITE..Call-ID:02043129-19e5-4bc0-7ff 9-00583b006c02@203.196.128.111..P-N-UAType:ip..Content-Length:0.... # U 203.196.128.121:5060 -> 203.196.128.126:5060 SIP/2.0 200 OK..Via:SIP/2.0/UDP 203.196.128.126;branch=z9hG4bK3c7a.9dbc7de4 .0..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7301e1fa200d7bb5806a 493bf..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <sip:222@qucko o.com;user=phone> ;tag=15400..CSeq:1 INVITE..Call-ID:02043129-19e5-4bc0-7ff 9-00583b006c02@203.196.128.111..Record-Route: <sip:222@203.196.128.126;ftag =13757;lr=on>..Contact: sip:222@203.196.128.121:5060;transport=udp..Suppo rted:timer..Session-Expires:1800;refresher=uac..Content-Type:application/sd p..Content-Length:216....v=0..o=SS-TA101 25742 25742 IN IP4 203.196.128.121 ..s=-..c=IN IP4 203.196.128.121..t=0 0..m=audio 54321 RTP/AVP 0 8 18 4..a=r tpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:4 G723-63/8000.... # U 203.196.128.126:5060 -> 203.196.128.111:5060 SIP/2.0 200 OK..Via:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7301e1fa 200d7bb5806a493bf..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <s ip:222@quckoo.com;user=phone> ;tag=15400..CSeq:1 INVITE..Call-ID:02043129-1 9e5-4bc0-7ff9-00583b006c02@203.196.128.111..Record-Route: <sip:222@203.196. 128.126;ftag=13757;lr=on>..Contact: <sip:222@203.196.128.121:5060;transport =udp>..Supported:timer..Session-Expires:1800;refresher=uac..Content-Type:ap plication/sdp..Content-Length:216....v=0..o=SS-TA101 25742 25742 IN IP4 203 .196.128.121..s=-..c=IN IP4 203.196.128.121..t=0 0..m=audio 54321 RTP/AVP 0 8 18 4..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000. .a=rtpmap:4 G723-63/8000.... # U 203.196.128.111:5060 -> 203.196.128.126:5060 ACK sip:222@203.196.128.121:5060;transport=udp SIP/2.0..Via:SIP/2.0/UDP 203 .196.128.111:5060;branch=z9hG4bk7301e1fa200d7bb5806a493bf..From: <sip:111@q uckoo.com;user=phone> ;tag=13757..To: sip:222@quckoo.com;user=phone ;tag= 15400..Call-ID:02043129-19e5-4bc0-7ff9-00583b006c02@203.196.128.111..CSeq:1 ACK..Route: sip:222@203.196.128.126;ftag=13757;lr=on..Max-Forwards:72..C ontent-Length:0.... # U 203.196.128.126:5060 -> 203.196.128.121:5060 ACK sip:222@203.196.128.121;user=phone SIP/2.0..Record-Route: <sip:222@203. 196.128.126;ftag=13757;lr=on>..Via: SIP/2.0/UDP 203.196.128.126;branch=0..V ia:SIP/2.0/UDP 203.196.128.111:5060;branch=z9hG4bk7301e1fa200d7bb5806a493bf ..From: sip:111@quckoo.com;user=phone ;tag=13757..To: <sip:222@quckoo.com ;user=phone> ;tag=15400..Call-ID:02043129-19e5-4bc0-7ff9-00583b006c02@203.1 96.128.111..CSeq:1 ACK..Max-Forwards:71..Content-Length:0.... # U 203.196.128.121:5060 -> 203.196.128.126:5060 BYE sip:111@203.196.128.111:5060;user=phone;transport=udp SIP/2.0..Via:SIP/ 2.0/UDP 203.196.128.121:5060;branch=z9hG4bk830bec679d08b75ab21c692af..From: sip:222@quckoo.com;user=phone ;tag=15400..To: <sip:111@quckoo.com;user=p hone> ;tag=13757..Call-ID:02043129-19e5-4bc0-7ff9-00583b006c02@203.196.128. 111..CSeq:1 BYE..Route: sip:222@203.196.128.126;ftag=13757;lr=on..Max-For wards:72..Content-Length:0.... # U 203.196.128.126:5060 -> 203.196.128.111:5060 BYE sip:111@203.196.128.111:5060;user=phone;transport=udp SIP/2.0..Record-R oute: sip:111@203.196.128.126;ftag=15400;lr=on..Via: SIP/2.0/UDP 203.196. 128.126;branch=z9hG4bK3c7a.adbc7de4.0..Via:SIP/2.0/UDP 203.196.128.121:5060 ;branch=z9hG4bk830bec679d08b75ab21c692af..From: <sip:222@quckoo.com;user=ph one> ;tag=15400..To: sip:111@quckoo.com;user=phone ;tag=13757..Call-ID:02 043129-19e5-4bc0-7ff9-00583b006c02@203.196.128.111..CSeq:1 BYE..Max-Forward s:71..Content-Length:0.... # U 203.196.128.111:5060 -> 203.196.128.126:5060 SIP/2.0 200 OK..Via:SIP/2.0/UDP 203.196.128.126;branch=z9hG4bK3c7a.adbc7de4 .0..Via:SIP/2.0/UDP 203.196.128.121:5060;branch=z9hG4bk830bec679d08b75ab21c 692af..From: sip:222@quckoo.com;user=phone ;tag=15400..To: <sip:111@qucko o.com;user=phone> ;tag=13757..CSeq:1 BYE..Call-ID:02043129-19e5-4bc0-7ff9-0 0583b006c02@203.196.128.111..Content-Length:0.... # U 203.196.128.126:5060 -> 203.196.128.121:5060 SIP/2.0 200 OK..Via:SIP/2.0/UDP 203.196.128.121:5060;branch=z9hG4bk830bec67 9d08b75ab21c692af..From: sip:222@quckoo.com;user=phone ;tag=15400..To: <s ip:111@quckoo.com;user=phone> ;tag=13757..CSeq:1 BYE..Call-ID:02043129-19e5 -4bc0-7ff9-00583b006c02@203.196.128.111..Content-Length:0.... exit 14 received, 0 dropped
Regards
Dhawan K
.
Disclaimer -------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Recipients must check this email and any attachments for the presence of viruses before downloading them. Direct Internet / Primus India accepts no liability for any damage caused by any virus transmitted by this email.