[sr-dev] TM Reply logic

[Daniel-Constantin Mierla]

Hello,

iirc (because the discussion was back in 2002-2003), 200ok has to be 
always forwarded by a proxy -- the rfc needs to be consulted for proper 
answer.

Cheers,
Daniel

On 26/05/14 13:36, Jason Penton wrote:
> Hi,
>
> I am confused by the TM reply processing logic in a particular 
> scenario. For example, if an INVITE transaction has had a final reply 
> (let's assume 500 Error in this case). Now, if a 200 OK comes through 
> the proxy to accept the call then according to the code below, the 
> relay will be relayed to the calling party.... why? This will also 
> cause the tm transaction state to change from state 5 (deleted) to 
> state (4) confirmed.... Is this correct? (a result of this scenario is 
> that the A UAC will receive a 500 followed by a 200....)
>
>
> static enum rps t_should_relay_response( struct cell *Trans , int 
> new_code,
> int branch , int *should_store, int *should_relay,
> struct cancel_info *cancel_data, struct sip_msg *reply )
> {
> int branch_cnt;
> int picked_code;
> int new_branch;
> int inv_through;
> int extra_flags;
> int i;
> int replies_dropped;
>
> /* note: this code never lets replies to CANCEL go through;
>   we generate always a local 200 for CANCEL; 200s are
>   not relayed because it's not an INVITE transaction;
>   >= 300 are not relayed because 200 was already sent
>   out
> */
> DBG("->>>>>>>>> T_code=%d, new_code=%d\n",Trans->uas.status,new_code);
> inv_through=new_code>=200 && new_code<300 && is_invite(Trans);
> /* if final response sent out, allow only INVITE 2xx  */
> if ( Trans->uas.status >= 200 ) {
> if (inv_through) {
> DBG("DBG: t_should_relay_response: 200 INV after final sent\n");
> *should_store=0;
> Trans->uac[branch].last_received=new_code;
> *should_relay=branch;
> return RPS_PUSHED_AFTER_COMPLETION;
> }
> /* except the exception above, too late  messages will
>   be discarded */
> goto discard;
> }
>
> /* if final response received at this branch, allow only INVITE 2xx */
> if (Trans->uac[branch].last_received>=200
> && !(inv_through && Trans->uac[branch].last_received<300)) {
> /* don't report on retransmissions */
> if (Trans->uac[branch].last_received==new_code) {
> DBG("DEBUG: final reply retransmission\n");
> goto discard;
> }
> /* if you FR-timed-out, faked a local 408  and 487 came or
> *  faked a CANCEL on a non-replied branch don't
> * report on it either */
> if ((Trans->uac[branch].last_received==487) ||
> (Trans->uac[branch].last_received==408 && new_code==487)) {
> DBG("DEBUG: %d came for a %d branch (ignored)\n",
> new_code, Trans->uac[branch].last_received);
> goto discard;
> }
> /* this looks however how a very strange status rewrite attempt;
> * report on it */
> LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS: "
> "stored: %d, received: %d\n",
> Trans->uac[branch].last_received, new_code );
> goto discard;
> }
>
>
> /* no final response sent yet */
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140527/0fc8320a/attachment-0001.html>