Hello,
I am having an issue routing an ACK back from a new upstream carrier. The basic situation is my openser 1.3.2 receives the INVITE. I do an alias_db_lookup, set some accounting flags, and send the call to t_relay
The call makes it to the PBX, as expected, and the PBX sends a 100 trying, 180 ringing. The 180 ringing is sent to the carrier. When the incoming call is answered the PBX sends a 200OK to openser, and that 200OK is sent to the carrier.
When the carrier sends the ACK back it makes it to OpenSER, but is not sent to the PBX. The PBX will send several more 200 OK attempts, but each ACK from the carrier stops at openser.
From what I can tell from the wireshark packet captures, the Request- Line header in the ACK from the carrier is sip:TELNUMBER@MY_OPENSER_IPADDR
I have compared these packets to similar traces from other carriers and the Request-Line header from the other carriers is sip:TELNUMBER@MY_PBX_IPADDR
This new carrier is telling me that they are not doing anything wrong with the ACK. RFC3261 seems specific about the construction of the ACK, but at the same time i am getting lost going to all of the other sections trying to identify details.
Basically I just need to get the ACK to the PBX. What other information can I provide with this problem.
Thanks Stagg Shelton
El Viernes, 22 de Agosto de 2008, Stagg Shelton escribió:
From what I can tell from the wireshark packet captures, the Request- Line header in the ACK from the carrier is sip:TELNUMBER@MY_OPENSER_IPADDR
I have compared these packets to similar traces from other carriers and the Request-Line header from the other carriers is sip:TELNUMBER@MY_PBX_IPADDR
An ACK for a 200 OK is a new transaction and a new request in-dialog), so the RURI in ACK *MUST* be the "Contact" in the first INVITE from the PBX.
Note also, that if your OpenSer is doing loose routing (as it usually normal and desirable) then the ACK MUST have a Route like: Route: sip:ip_openser
So the ACK MUST arrive to OpenSer because that Route header (that has preference over the RURI), and not because the RURI contains the OpenSer IP.
This new carrier is telling me that they are not doing anything wrong with the ACK. RFC3261 seems specific about the construction of the ACK, but at the same time i am getting lost going to all of the other sections trying to identify details.
Please, paste a SIP trace of the problem. hopefully here we could confirm you if the carrier behaviour is correct or not.
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Thank You Stagg Shelton
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help.
Stagg Shelton.
On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Saturday 23 August 2008 16:57:42 Stagg Shelton escribió:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Hi, just to clarify: is it your nre carrier an Asterisk? It's not the problem anyway.
The problem is in your OpenSer ACK handling. Note that:
-------------------- U +0.072541 phone:5060 -> OpenSer:5060 ACK sip:+16783832765@OpenSer SIP/2.0* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp* Route: sip:OpenSer;lr;did=952.4d684275*
# U +0.002367 OpenSer:5060 -> OpenSer:5060 ACK sip:OpenSer;lr;did=952.4d684275 SIP/2.0* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp*
# U +0.000072 OpenSer:5060 -> OpenSer:5060 ACK sip:OpenSer;lr;did=952.4d684275 SIP/2.0* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp* --------------------
The problem is that your OpenSer receives an ACK (a new request in-dialog since it's an ACK for a 200 OK) with a "Route: sip:OpenSer". This is correct of course. So your OpenSer should do loose_route() and detect "OpenSer" IP as an own ip/domain so it would remove the Route and route the ACK to the RURI (Asterisk IP). But OpenSer doesn't realiza the OpenSer IP is itself so it doesn't remove the Route and routes the ACK according to that Route, this is, doing INFINITE loops to itself.
So you must fix it by adding you OpenSer IP as an alias in the top of your OpenSer script:
alias = OpenSer_IP:5060
or maybe it's enough with:
auto_aliases=yes
Hope you understood me. If not see me.
The auto_aliases default is "on" according to the core cookbook for 1.3.x so I did not add that to my configuration. I did add alias=8.17.32.184:5060 per your suggestion and the ACK still continues in the infinite loop until the max hops is reached. I am using loose_route() if (has_totag() == true). I am pasting a copy of my openser config below for additional information on my specific configuration.
Thank You Stagg Shelton
# # $Id: openser.cfg 3542 2008-01-16 15:00:34Z miconda $ # # OpenSER basic configuration script # by Anca Vamanu anca@voice-system.ro # # Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php # for a explanation of possible statements, functions and parameters. #
####### Global Parameters #########
debug=3 log_stderror=no log_facility=LOG_LOCAL0
fork=yes children=4
/* uncomment the following lines to enable debugging */ #debug=6 #fork=no #log_stderror=yes
/* uncomment the next line to disable TCP (default on) */ disable_tcp=yes
port=5060
alias=8.17.32.184:5060
####### Modules Section ########
#set module path mpath="//lib/openser/modules/"
loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri_db.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "avpops.so" loadmodule "alias_db.so" loadmodule "permissions.so" loadmodule "carrierroute.so" loadmodule "snmpstats.so" loadmodule "dialog.so" loadmodule "group.so" loadmodule "options.so"
/* uncomment next line for multi-domain support NOTE: a DB (like mysql) module must be also loaded NOTE: be sure and enable multi-domain support in all used modules (see "multi-module params" section ) */ #loadmodule "domain.so"
# ----------------- setting module-specific parameters ---------------
# ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 0)
# ----- rr params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10)
# ----- uri_db params ----- /* by default we disable the DB support in the module as we do not need it in this configuration */ modparam("uri_db", "use_uri_table", 0) modparam("uri_db", "db_url", "")
# ----- acc params ----- /* what sepcial events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0)
/* account triggers (flags) */ modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) #modparam("acc","db_extra", "acc_extra=$var(accounting); acc_to= $var(numdialed)") modparam("acc","db_extra", "acc_extra=$var(accounting); acc_to= $var(numdialed); acc_direction=$var(direction)") #modparam("acc","db_extra", "acc_extra=$au; email=$avp(s:email)") modparam("acc", "db_url", "mysql://openser:oserdbpass@localhost/ openser")
# ----- usrloc params ----- modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url","mysql://openser:oserdbpass@localhost/ openser")
# ----- auth_db params ----- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url","mysql://openser:oserdbpass@localhost/ openser") modparam("auth_db", "load_credentials", "")
# ----- alias_db params ----- modparam("alias_db", "db_url","mysql://openser:oserdbpass@localhost/ openser")
# ----- permissions params ----- modparam("permissions", "db_url","mysql://openser:oserdbpass@localhost/ openser")
# ----- carrierroute params ----- modparam("carrierroute", "config_source", "db") modparam("carrierroute", "db_url", "mysql:// openser:oserdbpass@localhost/openser")
# ----- smpstats params ----- modparam("snmpstats", "sipEntityType", "registrarServer") modparam("snmpstats", "sipEntityType", "proxyServer") modparam("snmpstats", "snmpCommunity", "snmppass") modparam("snmpstats", "snmpgetPath", "/usr/bin/")
# ----- dialog params ----- modparam("dialog", "enable_stats", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "db_mode", 1) modparam("dialog", "db_url", "mysql://openser:oserdbpass@localhost/ openser")
# ----- group params ----- modparam("group", "db_url", "mysql://openser:oserdbpass@localhost/ openser")
####### Routing Logic ########
# main request routing logic
route{ $var(accounting) = ""; $var(numdialed) = ""; $var(direction) = "";
if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }
# Options responder if (uri==myself) { if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) { options_reply(); } }
if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accouting ... setflag(3); # ... even if the transaction fails } route(1); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard.\n"); exit; } } sl_send_reply("404","Not here"); } exit; }
#initial requests
# CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) setflag(1); setflag(2); t_relay(); exit; }
t_check_trans();
if (!(method=="REGISTER")) { if (!allow_trusted()) { if (!proxy_authorize("", "subscriber")) { $var(debug) = proxy_authorize("", "subscriber"); xlog("L_INFO", "Proxy authentication failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); xlog("Not Proxy Authorize: $var(debug)"); proxy_challenge("", "0"); exit; }
consume_credentials(); # caller authenticated } }
# record routing if (!is_method("REGISTER|MESSAGE")) record_route();
if (method=="INVITE"||method=="BYE"||method=="CANCEL") { setflag(4); }
if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }
# requests for my domain
if (is_method("PUBLISH")) { sl_send_reply("503", "Service Unavailable"); exit; }
if (is_method("REGISTER")) { if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; } if (!check_to()) { sl_send_reply("403","Forbidden auth ID"); exit; }
if (!save("location")) sl_reply_error();
exit; }
if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; }
alias_db_lookup("dbaliases"); $var(accounting) = $rU; xlog ("After alias db lookup: $rU"); remove_hf("Diversion"); if (!lookup("location")) { switch ($retcode) { case -1: case -3: if (uri=~"^sip:[0-9]{10}@") # Domestic PSTN { route(4); exit; } else if (uri=~"^sip:1[0-9]{10}@") # Domestic PSTN { route(4); exit; } else if (uri=~"^sip:011[0-9][0-9]+@") # International PSTN { route(3); exit; };
t_reply("404", "User Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } else { $rU = $oU; $var(numdialed) = $rU; $var(direction)="inbound"; } # when routing via usrloc, log the missed calls also setflag(2);
route(1); }
route[1] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { xlog("aubrey direction $var(direction)"); setflag(1); setflag(4); t_on_branch("2"); t_on_reply("2"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); }; exit; }
route[3] {
# ----------------------------------------------------------------- # PSTN International Handler # ----------------------------------------------------------------- $var(accounting) = $au; $var(numdialed) = $rU; $var(direction)="outbound";
if(!is_user_in("Credentials", "international")){ sl_send_reply("403", "Forbidden: No Intl Service"); exit; }
cr_user_rewrite_uri("sip:$au@.*","mydomain.net"); $avp(s:inv_timeout) = 45;
route(1); }
route[4] {
# ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- $var(accounting) = $au; $var(numdialed) = $rU; $var(direction)="outbound";
cr_user_rewrite_uri("sip:$au@.*","mydomain.net"); $avp(s:inv_timeout) = 45;
route(1); }
branch_route[2] { xlog("new branch at $ru\n"); }
onreply_route[2] { xlog("incoming reply $rm\n"); xlog("$rb\n"); }
failure_route[1] { if (t_was_cancelled()) { exit; } }
On Aug 25, 2008, at 5:04 AM, Iñaki Baz Castillo wrote:
El Saturday 23 August 2008 16:57:42 Stagg Shelton escribió:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Hi, just to clarify: is it your nre carrier an Asterisk? It's not the problem anyway.
The problem is in your OpenSer ACK handling. Note that:
U +0.072541 phone:5060 -> OpenSer:5060 ACK sip:+16783832765@OpenSer SIP/2.0* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp* Route: sip:OpenSer;lr;did=952.4d684275*
# U +0.002367 OpenSer:5060 -> OpenSer:5060 ACK sip:OpenSer;lr;did=952.4d684275 SIP/2.0* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp*
# U +0.000072 OpenSer:5060 -> OpenSer:5060 ACK sip:OpenSer;lr;did=952.4d684275 SIP/2.0* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP OpenSer;branch=z9hG4bKc29c.498b5a5.2* Via: SIP/2.0/UDP phone:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Contact: sip:restricted@phone:5060;transport=udp*
The problem is that your OpenSer receives an ACK (a new request in- dialog since it's an ACK for a 200 OK) with a "Route: sip:OpenSer". This is correct of course. So your OpenSer should do loose_route() and detect "OpenSer" IP as an own ip/domain so it would remove the Route and route the ACK to the RURI (Asterisk IP). But OpenSer doesn't realiza the OpenSer IP is itself so it doesn't remove the Route and routes the ACK according to that Route, this is, doing INFINITE loops to itself.
So you must fix it by adding you OpenSer IP as an alias in the top of your OpenSer script:
alias = OpenSer_IP:5060
or maybe it's enough with:
auto_aliases=yes
Hope you understood me. If not see me.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 15:30:47 Stagg Shelton escribió:
if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accouting ... setflag(3); # ... even if the transaction fails } route(1); } else {
Let's test if the ACK for a 200 OK runs correctly in that section of the script. Add a xlog:
if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { ################## if method=="ACK" { xlog("L_INFO", "-------- I'm an ACK for a 200 OK -------\n"); } ################## if (is_method("BYE")) { setflag(1); # do accouting ... setflag(3); } route(1); } else {
And test if that xlog appears in the screen output.
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
regards klaus
U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df-dcaa3e6a-2f5ec169* Record-Route: sip:8.17.32.184;lr=on;did=952.4d684275* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 INVITE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:+16783832765@8.17.32.19* Content-Type: application/sdp* Content-Length: 180*
U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 ACK sip:+16783832765@8.17.32.184 SIP/2.0* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 ACK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f* Max-Forwards: 15* Contact: sip:restricted@63.209.207.135:5060;transport=udp* Route: sip:8.17.32.184;lr;did=952.4d684275* Content-Length: 0*
Stagg Shelton schrieb:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help.
Stagg Shelton.
On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 15:52:47 Klaus Darilion escribió:
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
You are right Klaus, I didn't realize of it.
This is exactly what I told the carrier engineer about the problem. The contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning from the carrier) is my OpenSER. I informed the carrier that according to my interpretation of the RFC 3261 the RURI in the ACK MUST match the contact in the 200 OK with SDP.
The carrier interop engineer sent me the following remark after I notified them of the issue, and began pressing them on the way their ACK was created.
== BEGIN == The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did. == END ==
After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them.
== BEGIN == All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request-URIs of ACKs based on values from the SDP of the 200 OK is not the case. I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state.
I have another question based on our use of SER internally. When we send the initial INVITE, the Request-URI is set as the number at (@) the address of your [Open]SER proxy. SER will then re-write the request URI of the INVITE based on the logic in the local ser.cfg file and any local location/alias database entries used in that logic and forward the message to the destination, in this case the PBX, while adding a Record-Route header with LR set to ensure SER stays in the dialog in terms of signaling as well as adding a VIA header with a branch tag used to mark the dialog for stateful processing (when the TM module is used). In the case of stateful processing, these values are used to maintain the same signaling path for subsequent messages within the same dialog.
When stateless routing is used via the SL module, all new requests (including an ACK to a 200 response) should follow the same routing logic as the initial request. Therefore, when the ACK arrives at your SER proxy, the same routing logic should be applied to the ACK as was the original INVITE, and it should be forwarded on to the correct destination. If this is not the case, then either there must be some kind of state being tracked or the logic has been written to handle ACKs differently on purpose as this would be the only way that the handling and routing (especially the computation of the final request- uri) would be different for an ACK from an INVITE. == END ==
At this point I am ready to address any issue with my OpenSER configuration that can be identified, but if the problem is actually due to the ACK not being constructed correctly, I have to take off the technical hat, and put on the business hat, and try to get them to look at their systems, and push their vendors for support in this issue.
Thank You Stagg Shelton
On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
regards klaus
U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df- dcaa3e6a-2f5ec169* Record-Route: sip:8.17.32.184;lr=on;did=952.4d684275* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a- b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 INVITE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:+16783832765@8.17.32.19* Content-Type: application/sdp* Content-Length: 180*
U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 ACK sip:+16783832765@8.17.32.184 SIP/2.0* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a- b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 ACK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Max-Forwards: 15* Contact: sip:restricted@63.209.207.135:5060;transport=udp* Route: sip:8.17.32.184;lr;did=952.4d684275* Content-Length: 0*
Stagg Shelton schrieb:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help. Stagg Shelton. On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 16:41:37 Stagg Shelton escribió:
== BEGIN == The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did. == END ==
This make no sense *AT ALL*. An ACK for a 200 OK is a **NEW** request (a new transaction). In case an ACK for a non 200 final response the ACK is part of the INVITE transaction but this is not the case.
After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them.
== BEGIN == All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request-URIs of ACKs based on values from the SDP of the 200 OK is not the case.
"changing the Request-URIs of ACKs based on values from the SDP of the 200 OK" ???
What does he mean with "SDP"??? The only important to generate the route_set is the Contact of the "200 OK", no the SDP !!
I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state.
It's their problem if some systems route the ACK for a 200 OK in some "exotic" way, but RFC3261 says *clearly* that an ACK for a 200 is a NEW request, an in-dialog request in fact, so the RURI of the ACK must be the remote target for the UAS that must be the "Contact" in the 200 OK.
Your provider behaviour is WRONG. If they are not capable of fixing it I suggest you to add the "Contact" address also as a Record-Route parameter so you could get it from the top "Route" header in the wrong ACK from your provider. Of course this is a hack, but worse is what yuor provider does.
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful.
regards klaus
Stagg Shelton wrote:
This is exactly what I told the carrier engineer about the problem. The contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning from the carrier) is my OpenSER. I informed the carrier that according to my interpretation of the RFC 3261 the RURI in the ACK MUST match the contact in the 200 OK with SDP.
The carrier interop engineer sent me the following remark after I notified them of the issue, and began pressing them on the way their ACK was created.
== BEGIN == The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did. == END ==
After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them.
== BEGIN == All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request-URIs of ACKs based on values from the SDP of the 200 OK is not the case. I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state.
I have another question based on our use of SER internally. When we send the initial INVITE, the Request-URI is set as the number at (@) the address of your [Open]SER proxy. SER will then re-write the request URI of the INVITE based on the logic in the local ser.cfg file and any local location/alias database entries used in that logic and forward the message to the destination, in this case the PBX, while adding a Record-Route header with LR set to ensure SER stays in the dialog in terms of signaling as well as adding a VIA header with a branch tag used to mark the dialog for stateful processing (when the TM module is used). In the case of stateful processing, these values are used to maintain the same signaling path for subsequent messages within the same dialog.
When stateless routing is used via the SL module, all new requests (including an ACK to a 200 response) should follow the same routing logic as the initial request. Therefore, when the ACK arrives at your SER proxy, the same routing logic should be applied to the ACK as was the original INVITE, and it should be forwarded on to the correct destination. If this is not the case, then either there must be some kind of state being tracked or the logic has been written to handle ACKs differently on purpose as this would be the only way that the handling and routing (especially the computation of the final request-uri) would be different for an ACK from an INVITE. == END ==
At this point I am ready to address any issue with my OpenSER configuration that can be identified, but if the problem is actually due to the ACK not being constructed correctly, I have to take off the technical hat, and put on the business hat, and try to get them to look at their systems, and push their vendors for support in this issue.
Thank You Stagg Shelton
On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
regards klaus
U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df-dcaa3e6a-2f5ec169* Record-Route: sip:8.17.32.184;lr=on;did=952.4d684275* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 mailto:ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 INVITE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:+16783832765@8.17.32.19* Content-Type: application/sdp* Content-Length: 180*
U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 ACK sip:+16783832765@8.17.32.184 SIP/2.0* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 mailto:ATLMGC0720080823144655027771@209.244.63.15* CSeq: 1 ACK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f* Max-Forwards: 15* Contact: sip:restricted@63.209.207.135:5060;transport=udp* Route: sip:8.17.32.184;lr;did=952.4d684275* Content-Length: 0*
Stagg Shelton schrieb:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help. Stagg Shelton. On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 18:06:16 Klaus Darilion escribió:
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful.
It's very sad that many providers/carriers expect that the client point is an UAC, a B2BUA or a gateway, butnot a proxy.
Some time ago I was speaking with my carrier about some SIP problems and he told me that the problem was in my "INVITE" since "Contact" and "From" were different !! XDDD
I agree, and this is the first provider that we have had any issues with. My production OpenSER is supplying service to my end users from multiple providers using, sonus, broadsoft, & nextone without any issue. I have not been able to identify from packet captures which software or product this carrier is using. They have eluded in some comments that they are using SER to some capacity, but I do not have any confirmation.
Thanks Stagg Shelton
On Aug 25, 2008, at 12:17 PM, Iñaki Baz Castillo wrote:
El Monday 25 August 2008 18:06:16 Klaus Darilion escribió:
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful.
It's very sad that many providers/carriers expect that the client point is an UAC, a B2BUA or a gateway, butnot a proxy.
Some time ago I was speaking with my carrier about some SIP problems and he told me that the problem was in my "INVITE" since "Contact" and "From" were different !! XDDD
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Thanks Iñaki, and Klaus. It is a good feeling to know that I am correct with my configuration, and my interpretation of the RFC, despite having only been learning OpenSER since June of this year. I will take the information that you have presented me with, and try to work with the provider to get the issue resolved from their end.
Thank You Stagg Shelton
On Aug 25, 2008, at 12:06 PM, Klaus Darilion wrote:
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful.
regards klaus
Stagg Shelton wrote:
This is exactly what I told the carrier engineer about the problem. The contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning from the carrier) is my OpenSER. I informed the carrier that according to my interpretation of the RFC 3261 the RURI in the ACK MUST match the contact in the 200 OK with SDP. The carrier interop engineer sent me the following remark after I notified them of the issue, and began pressing them on the way their ACK was created. == BEGIN == The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did. == END == After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them. == BEGIN == All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request- URIs of ACKs based on values from the SDP of the 200 OK is not the case. I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state. I have another question based on our use of SER internally. When we send the initial INVITE, the Request-URI is set as the number at (@) the address of your [Open]SER proxy. SER will then re-write the request URI of the INVITE based on the logic in the local ser.cfg file and any local location/alias database entries used in that logic and forward the message to the destination, in this case the PBX, while adding a Record-Route header with LR set to ensure SER stays in the dialog in terms of signaling as well as adding a VIA header with a branch tag used to mark the dialog for stateful processing (when the TM module is used). In the case of stateful processing, these values are used to maintain the same signaling path for subsequent messages within the same dialog. When stateless routing is used via the SL module, all new requests (including an ACK to a 200 response) should follow the same routing logic as the initial request. Therefore, when the ACK arrives at your SER proxy, the same routing logic should be applied to the ACK as was the original INVITE, and it should be forwarded on to the correct destination. If this is not the case, then either there must be some kind of state being tracked or the logic has been written to handle ACKs differently on purpose as this would be the only way that the handling and routing (especially the computation of the final request-uri) would be different for an ACK from an INVITE. == END == At this point I am ready to address any issue with my OpenSER configuration that can be identified, but if the problem is actually due to the ACK not being constructed correctly, I have to take off the technical hat, and put on the business hat, and try to get them to look at their systems, and push their vendors for support in this issue. Thank You Stagg Shelton On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
regards klaus
U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df- dcaa3e6a-2f5ec169* Record-Route: sip:8.17.32.184;lr=on;did=952.4d684275* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df- dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15
CSeq: 1 INVITE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:+16783832765@8.17.32.19* Content-Type: application/sdp* Content-Length: 180*
U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 ACK sip:+16783832765@8.17.32.184 SIP/2.0* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df- dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15
CSeq: 1 ACK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Max-Forwards: 15* Contact: sip:restricted@63.209.207.135:5060;transport=udp* Route: sip:8.17.32.184;lr;did=952.4d684275* Content-Length: 0*
Stagg Shelton schrieb:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help. Stagg Shelton. On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
Iñaki,
Thank you for your response. I have enabled the siptrace module in openser. The data in the mysql table only shows the trace between the carrier and openser. Can I submit a pcap file that shows all of the SIP communication that occured during the call.
Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 18:22:19 Stagg Shelton escribió:
Thanks Iñaki, and Klaus. It is a good feeling to know that I am correct with my configuration, and my interpretation of the RFC, despite having only been learning OpenSER since June of this year. I will take the information that you have presented me with, and try to work with the provider to get the issue resolved from their end.
Stagg, the point here is that your provider says:
"most system’s don’t route the ACK based on its Request-URI when keeping state."
It doesn't matter what "others" do, the fact is that the provider CANNOT send a WRONG formed ACK by asumming that the client will handle it in a exotic way instead of the way RFC3261 defines (the only standard).
So the excuse of your provider is basically: - "With other clients I have not this problem". - "Most of them accept my ACK since they don't handle it as RFC3261 defines".
Your provider must recognice that him ACK is wrong, regardless of how you proxy handles it (in fact it handles it correctly). And he MUST fix it.
Pain of ignorant carriers...
Hi!
For reference if you want to present some standards to your provider:
RFC 3261:
12.2.1.1 Generating the Request
...If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
The remote target itself is defined in 12.1.2: ...The remote target MUST be set to the URI from the Contact header field of the response.
good luck klaus
Stagg Shelton wrote:
Thanks Iñaki, and Klaus. It is a good feeling to know that I am correct with my configuration, and my interpretation of the RFC, despite having only been learning OpenSER since June of this year. I will take the information that you have presented me with, and try to work with the provider to get the issue resolved from their end.
Thank You Stagg Shelton
On Aug 25, 2008, at 12:06 PM, Klaus Darilion wrote:
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful.
regards klaus
Stagg Shelton wrote:
This is exactly what I told the carrier engineer about the problem. The contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning from the carrier) is my OpenSER. I informed the carrier that according to my interpretation of the RFC 3261 the RURI in the ACK MUST match the contact in the 200 OK with SDP. The carrier interop engineer sent me the following remark after I notified them of the issue, and began pressing them on the way their ACK was created. == BEGIN == The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did. == END == After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them. == BEGIN == All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request- URIs of ACKs based on values from the SDP of the 200 OK is not the case. I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state. I have another question based on our use of SER internally. When we send the initial INVITE, the Request-URI is set as the number at (@) the address of your [Open]SER proxy. SER will then re-write the request URI of the INVITE based on the logic in the local ser.cfg file and any local location/alias database entries used in that logic and forward the message to the destination, in this case the PBX, while adding a Record-Route header with LR set to ensure SER stays in the dialog in terms of signaling as well as adding a VIA header with a branch tag used to mark the dialog for stateful processing (when the TM module is used). In the case of stateful processing, these values are used to maintain the same signaling path for subsequent messages within the same dialog. When stateless routing is used via the SL module, all new requests (including an ACK to a 200 response) should follow the same routing logic as the initial request. Therefore, when the ACK arrives at your SER proxy, the same routing logic should be applied to the ACK as was the original INVITE, and it should be forwarded on to the correct destination. If this is not the case, then either there must be some kind of state being tracked or the logic has been written to handle ACKs differently on purpose as this would be the only way that the handling and routing (especially the computation of the final request-uri) would be different for an ACK from an INVITE. == END == At this point I am ready to address any issue with my OpenSER configuration that can be identified, but if the problem is actually due to the ACK not being constructed correctly, I have to take off the technical hat, and put on the business hat, and try to get them to look at their systems, and push their vendors for support in this issue. Thank You Stagg Shelton On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:
Hi!
AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!
regards klaus
U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df- dcaa3e6a-2f5ec169* Record-Route: sip:8.17.32.184;lr=on;did=952.4d684275* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df- dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15
CSeq: 1 INVITE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:+16783832765@8.17.32.19* Content-Type: application/sdp* Content-Length: 180*
U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 ACK sip:+16783832765@8.17.32.184 SIP/2.0* From: Anonymous sip:restricted@63.209.207.135;tag=88cfd13f-13c4-48b022df- dcaa3e6a-b4657f0* To: sip:+16783832765@8.17.32.184:5060;tag=as40da5b97* Call-ID: ATLMGC0720080823144655027771@209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15
CSeq: 1 ACK* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5- dcaa5757-3884948f* Max-Forwards: 15* Contact: sip:restricted@63.209.207.135:5060;transport=udp* Route: sip:8.17.32.184;lr;did=952.4d684275* Content-Length: 0*
Stagg Shelton schrieb:
Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.
Thank you for your help. Stagg Shelton. On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió: > Iñaki, > > Thank you for your response. I have enabled the siptrace > module in > openser. The data in the mysql table only shows the trace > between the > carrier and openser. Can I submit a pcap file that shows all > of the > SIP communication that occured during the call. Hi, you don't need to enable siptrace. Just install "ngrep" and do:
ngrep -d any -P '*' -W byline -T port 5060
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Lunes, 25 de Agosto de 2008, Klaus Darilion escribió:
Hi!
For reference if you want to present some standards to your provider:
RFC 3261:
12.2.1.1 Generating the Request
...If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
The remote target itself is defined in 12.1.2: ...The remote target MUST be set to the URI from the Contact header field of the response.
One question more: If you initiate an outgoing call through that provider, is it correctly established? In that case try to call to a PSTN phone of you, and hang up the call from the PSTN in order to receive a BYE from the provider. Is that BYE correctly generated? it should have a "Route: sip:openser_ip" and a RURI like the Contact you send in the INVITE.
We've been using this provider for a few weeks now with no issues with termination to PSTN. Below is a sip trace from the PSTN to my interop system, with the hangup occuring from the PSTN. The sip trace appears to confirm that the BYE from the provider is formed correctly, and is properly relayed by openser.
Thanks Stagg Shelton
# U +3.305877 63.209.207.135:5060 -> 8.17.32.184:5060 BYE sip:6783832765@8.17.32.19 SIP/2.0* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* Max-Forwards: 15* Route: sip:8.17.32.184;lr;did=f9.56eb2673* Content-Length: 0* *
# U +0.002395 8.17.32.184:5060 -> 8.17.32.19:5060 BYE sip:6783832765@8.17.32.19 SIP/2.0* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* Via: SIP/2.0/UDP 8.17.32.184;branch=z9hG4bK41a6.c4d351.0* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* Max-Forwards: 14* Content-Length: 0* *
# U +0.003511 8.17.32.19:5060 -> 8.17.32.184:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 8.17.32.184;branch=z9hG4bK41a6.c4d351.0;received=8.17.32.184* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:6783832765@8.17.32.19* Content-Length: 0* *
On Aug 25, 2008, at 3:30 PM, Iñaki Baz Castillo wrote:
El Lunes, 25 de Agosto de 2008, Klaus Darilion escribió:
Hi!
For reference if you want to present some standards to your provider:
RFC 3261:
12.2.1.1 Generating the Request
...If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
The remote target itself is defined in 12.1.2: ...The remote target MUST be set to the URI from the Contact header field of the response.
One question more: If you initiate an outgoing call through that provider, is it correctly established? In that case try to call to a PSTN phone of you, and hang up the call from the PSTN in order to receive a BYE from the provider. Is that BYE correctly generated? it should have a "Route: sip:openser_ip" and a RURI like the Contact you send in the INVITE.
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Monday 25 August 2008 21:47:15 Stagg Shelton escribió:
We've been using this provider for a few weeks now with no issues with termination to PSTN. Below is a sip trace from the PSTN to my interop system, with the hangup occuring from the PSTN. The sip trace appears to confirm that the BYE from the provider is formed correctly, and is properly relayed by openser.
Yes, the BYE is correctly formed, so your provider has a problem when generating the ACK for a 200 OK.
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Klaus Darilion -
Stagg Shelton