Christer Holmberg's answer is perfectly CORECT... ----- Original Message ----- From: "P Rajmohan Banavi-A17190" <[EMAIL PROTECTED]> To: "Attila Sipos" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, September 01, 2003 7:07 PM Subject: RE: [Sip-implementors] To-Tag value
> The transaction will match as per 17.1.3, since the branch param and cseq method in both final responses will be the same as in the UAC INVITE request. Till timer D fires, subsequent final responses will be absorbed by the UAC and will send out an ACK per final response since this is for UNRELIABLE transport. > > In such a scenario, should the earlier To-Tag be replaced by the newer one? > [ABN] This To-Tag raplacement does not happpen since this response will not be sent up to TU... > -----Original Message----- > From: Attila Sipos [mailto:[EMAIL PROTECTED] > Sent: Monday, September 01, 2003 6:53 PM > To: Attila Sipos; P Rajmohan Banavi-A17190; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] To-Tag value > > > > > > Sorry, I was wrong, > > Natraj's response is right. > > >The 500 response will be dropped in the first place. > >since there is not matching txn by that time... > >No entity must send response with diff tags for the same call (even among > >provisional and final responses also...) > > My scenario was nonsense, since if there was a 300 response, > there wouldn't be a call up anyway (since it's just a redirection > response). > > But two final responses are still illegal so, as Natraj > said, the second one (the 500) will get dropped. > > > > > -----Original Message----- > From: Attila Sipos [mailto:[EMAIL PROTECTED] > Sent: 01 September 2003 14:18 > To: 'P Rajmohan Banavi-A17190'; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] To-Tag value > > > > > I think this is illegal. > > The 300 is a FINAL response already (anything >= 200 is a FINAL response) > so you cannot send another final response afterwards. > > I think the correct thing to do would be: > > > UAC UAS > ------ ------ > -------------------------------> INVITE > <------------------------------- 300 Multiple choices > --------------------------------> ACK > <------------------------------- BYE > --------------------------------> OK (to BYE) > > In the BYE request, you can specify a disconnection reason, if you like, > using the "The Reason Header Field for the Session Initiation Protocol (SIP)" > in RFC3326: > http://www.faqs.org/rfcs/rfc3326.html <http://www.faqs.org/rfcs/rfc3326.html> > > Regards, > > Attila > > Attila Sipos > Software Engineer > <http://www.vegastream.com <http://www.vegastream.com> > > VegaStream : A World of difference for your Integrated Communications > > > -----Original Message----- > From: P Rajmohan Banavi-A17190 [mailto:[EMAIL PROTECTED] > Sent: 01 September 2003 14:11 > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] To-Tag value > > > Hi, > > This is related to INVITE transaction on unreliable transport. > > UAC UAS > ------ ------ > -------------------------------> INVITE > <------------------------------- 300 Multiple choices > --------------------------------> ACK > <------------------------------- 500 Server internal error (before the Timer D fires) > > --------------------------------> ACK > > Suppose the "To-tag" in the second final response (500) sent by UAS is different than the one in the initial response (300), > > 1. how should the UAC behave? > > 2. And what should be the value of the "To-Tag" in the ACK sent by UAC for 500 response? > > regards, > Rajmohan > > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
