Re: [Serusers] rewritehostport and RFC3261 compliant - sr-users

18 Dec 2007

Hi Adrien!

I Cc this email also to the seruser mailing list as it might be 
interesting for others too.

Adrien Lemoine schrieb:
...
  Hi Klaus,

 I've some good news !!! (Sorry to take your time)

 I try the solution in the URL paste in the last mail, and it runs !

 So I've something like this :

 if ( t_check_status("(1[0-7][0-9])|(180)") ) {
         xlog("L_WARN","time=[%Tf] call id=[%ci] call seq=[%cs] contact
 header=[%ct] from uri=[%fu] from tag=[%ft] request's method=[%rm] request's
 uri=[%ru] to uri=[%tu] to tag=[%tt] sip message id=[%mi] process id=[%pp] ip
 source=[%is] flags=[%mf], fix To-Tag failure [Thomson]\n");
 		subst('/^(To:.*)\;tag=[^;[:cntrl:]]*/\1/i');
     }
 	break;

 The guy precise that 183 don't have to be included in this test, why ? 
Bogdan was afraid that this could break "early media", but I'm sure it 
is best to include 183 as well.

Thus this regular expression should handle all provisional responses.
t_check_status("(1[0-9][0-9])")

...
  Is this could be okay for simplify the solution and
don't take the risk to
 break an other service by collateral effects ? 
You never know and it would be better to fix it in the SIP 
phone/gateway. But I think it is a acceptable workaround.

...
  I think I beging to understand the problem : my
Thomson product "remember"
 of the first to-tag include in "180 ringing" and doesn't accept an other
 to-tag for the same transaction. Isn't it ? 
Yes.

Some theory: SIP has to match incoming requests and responses to 
existing dialog. This is done by comparing the 3-tuple 
call-id/from-tag/to-tag.

Messages which are sent out of dialog do not have a to-tag (tag 
parameter in the To: header).

The initial INVITE request is sent "out-of-dialog" (no to-tag). If a SIP 
client responses to the INVITE request it adds a to-tag to the response. 
Thus, if the INVITE is sent to multiple devices (e.g. parallel ringing 
on multiple SIP devices or call forwarding on timeout) the caller will 
receive multiple responses. As the to-tag is different for each called 
SIP device the caller can detect responses from different devices. (this 
is a feature of SIP).

If the caller SIP client receives provisional responses (101-199) it 
will create an "early dialog". Once a final response is received the 
dialog will convert into "confirmed" state ( 200 OK) or the dialog will 
be terminated (3xx-6xx responses).

Example:

caller           proxy             phone1    phone2
*0
  --INVITE---------->

  <-100 (no to tag)-- ----INVITE------>
*1                   <---100 trying---
                      <---180 ringing--
<---180 ringing-----

*2

                      ----INVITE----------------->
                      <---100 trying--------------
                      <---180 ringing-------------
<---180 ringing-----

*3

                       <---200 ok-----------------
<----200 ok ---------
*4
                       ----CANCEL------>
                       ........

An RFC compliant SIP client should handle the scenario following:
*0: the caller sends the INVITE (out-of-dilaog).

*1: The caller receives a 100 trying response. A "100 trying" does not 
have a to-tag and thus does not create dialogs. It will only stop 
retransmissions.

*2: The caller receives a provisional response. It creates an 
"early-dialog" with the identifier call-id/fromtag/totag1.

*3: The caller receives another provisional response. The response has a 
different to-tag. Thus the caller creates a second "early-dialog" with 
identifier call-id/fromtag/totag2.

*4: The caller receives a final response. The 200 ok matches 
call-id/fromtag/totag2. Thus, the first early-dialog will be terminated 
and the second early-dialog will be transformed into "confirmed" state.

Some non-complient clients handle it in other ways, e.g.:
- Asterisk with "pedantic=no": Asterisk does not care about totags in 
provisional responses but only in the 200 ok. (works but insecure).
- Asterisk with "pedantic=yes": Asterisk learns the totag from the first 
provisional response. All further responses with different totag are 
ignored. (breaks compatibility).

I guess the Thomson device has the some bug as Asterisk in pedantic mode.

...
  If it's that, I don't read something about
this behaviour in the RFC to
 argument my quick fix. 
Of course the workaround with "removing totags in provisional responses" 
breaks the RFC - but in the case with broken clients the RFC is already 
broken by the clients.

...
  An other problem appears, you said that "try to
remove the to-tag in the 180
 and 183 responses *to this client*". I would like too, but how can I match
 UserAgent in Status, there's not. 
If the INVITE has a user agent header like
"User-Agent: Thomsen abcd....." you activate the reply_route. E.g.

...
if ((method == INVITE)
    && (search("User-Agent: Thomson")) {
   t_on_reply("1");
   xlog("L_INFO","buggy Thomson, activate reply route to strip
totag");
}
...

onreply_route[1] {
   xlog("L_INFO","reply route: strip totag");
   # put some more xlog here if wanted...
   if (t_check_status("(1[0-9][0-9])")) {
     subst('/^(To:.*)\;tag=[^;[:cntrl:]]*/\1/i');
   }
}

regards
Klaus