Subject: RE: [Sip] Bug in RFC3261 ?

From: Chadha Retesh-A19894 <[email-masked]>
Date: Thu, 6 May 2004 16:50:56 +0530

I think it will retransmit INVITE only if it's a non-reliable transport.

Regards
Retesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 06, 2004 4:27 PM
To: Retesh Chadha; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

Hi

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chadha Retesh-A19894
Sent: Thursday, May 06, 2004 4:04 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

Similar is the following scenario ---
200 ok to an INVITE matching the transaction (same branch in top via header), but not matching the dialog parameters (from tag, call-tag, etc). In this case, the INVITE  transaction will be terminated with an erroneous 200 ok. Now, if the correct 200 response comes, it will be considered as a retransmission and ignored.

[Ranjit] I think if the 200 OK received is not matching the dialog parameters, it is as good as not receiving the 200 OK. So UAC could retransmit INVITE. 

In the above and all such cases, I feel uac should take a call on being strict or not. If it needs to consider such responses as invalid, it should terminate the call, and take the same action as it would have taken for a non-successful response.

Regards
Retesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 06, 2004 3:40 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

I actually feel this is more a question of
whether to accept non conforming peers. If
the implementation should be strict it can
simply terminate the associated dialog,
otherwise accept the response and face it.
I don't think RFC can provide any guidelines
on these situations.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 06, 2004 3:06 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] Bug in RFC3261 ?
> 
> 
> Hi Prasanna,
> 
> The number of via headers cannot and should not
> be validated by the transaction layer. Ideally,
> the transaction layer should not know whether
> the message is for the proxy TU or the UA TU.
> In the former, more than one via header will
> be present.
> 
> Thanks
> Kowsalya
> 
> > -----Original Message-----
> > From: Prasanna [mailto:[email-masked]]
> > Sent: Thursday, May 06, 2004 1:49 PM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sip] Bug in RFC3261 ?
> > 
> > 
> > There is a basic confusion...
> > 8.1.3.3 mentions that the "UAC" should discard the message. But is 
> > it the "transaction layer" that is discarding the message or the 
> > "TU" (which is the UA core in this case) discarding the message.
> > If the transaction discards it, Hisham's flow is okay, the 
> > timers will fire.
> > But what if the UA core discards.  Assuming the UPDATE----200 
> > exchange,
> > In this case, the transaction would have assumed the 200 
> > response to be fine
> > and moved to the "completed" state.  There is no Timer F in 
> this case
> > anyway.
> > Worse will be case if the exchange is INVITE---180----200, And 200 
> > has to be discarded.  The moment transaction deemed the 200 to be
> > okay, it will terminate.
> > 
> > 
> > Even if what 8.1.3.3 mentions is for the transaction, how about the 
> > validation of the Table 2 / Table 3 requirements. What if there is 
> > 423 without Min-Expires or a 200 for INVITE without Contact?
> > 
> > Should the complete validation be done by the transaction layer?
> > 
> > Cheers,
> > Prasanna
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Sent: Wednesday, May 05, 2004 1:42 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sip] Bug in RFC3261 ?
> > 
> > 
> > Well, you were pointing at the right sections. 17.1.1.2 and
> > 17.1.2.2 specify
> > that when Timer B (for INVITE) and Timer F (for non-INVITE) 
> fire, "the
> > client transaction SHOULD inform the TU about the
> >    timeout, and then it SHOULD enter the "Terminated" state"
> > 
> > Hisham
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of ext 
> > [email-masked]
> > Sent: 05.May.2004 03:02
> > To: PROUVOST Sébastien FTRD/DAC/ISS
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Sip] Bug in RFC3261 ?
> > 
> > 
> > 
> > Hi Sébastien,
> > 
> > I just re-read your question and realised it's more
> complicated than I
> > thought :-)
> > 
> > Hmmm......I'm not sure what it should do either.
> > 
> > I'm sure someone smarter than me will be along shortly though :-)
> > 
> > B
> > 
> > Ben Gatewood
> > Dimension Data
> > SIP Wookie
> > Level 1 10 Dorcas Street South Melbourne
> > +61 3 9626 0735
> > +61 419 885 762
> > [email-masked]
> > 
> > 
> > [email-masked]
> > Sent by: [email-masked] 
> > 05/05/2004 08:33 AM 
> >         
> >         To:        PROUVOST Sébastien FTRD/DAC/ISS
> > <[email-masked]> 
> >         cc:        [email-masked], [email-masked] 
> >         Subject:        Re: [Sip] Bug in RFC3261 ?
> > 
> > 
> > 
> > 
> > Hi Sébastien,
> > 
> > There are procedures and timers for this situation in 3261.
> > Have a look at
> > Section 17.1.1.2 and 17.1.2.2. 
> > 
> > Basically the UA should wait 64*T1 (Timer 1). T1, by default,
> > should be
> > 500ms so your UA should wait 32 seconds for a valid response. 
> > 
> > HTH,
> > 
> > B
> > 
> > Ben Gatewood
> > Dimension Data
> > SIP Wookie
> > Level 1 10 Dorcas Street South Melbourne
> > +61 3 9626 0735
> > +61 419 885 762
> > [email-masked]
> > 
> > PROUVOST Sébastien FTRD/DAC/ISS
> > <[email-masked]> 
> > Sent by: [email-masked] 
> > 04/05/2004 07:49 PM         
> >        To:        <[email-masked]> 
> >        cc:         
> >        Subject:        [Sip] Bug in RFC3261 ?
> > 
> > 
> > 
> > 
> > Hi,
> > In RFC 3261, it is written (section 8.1.3.3 for UAC Core 
> > procedures) : "If
> > more than one Via header field value is present in a 
> response, the UAC
> > SHOULD discard the message."
> > However if the UAC Core layer discards the response and if 
> > this response was
> > the only one sent (for example a 200 OK to an UPDATE), then 
> > this leads to a
> > situation when the transaction is terminated (the transaction 
> > layer received
> > the response and passed it to the UA Core) but the UA Core is 
> > still waiting
> > for a response (it discarded the 200 OK because of the 
> > presence of two Via
> > header field values and so is still waiting for the response). 
> > I believe there shall be procedures that tells the UAC Core 
> > when to stop
> > waiting for the response. Or am I misunderstanding something ? 
> > Thanks for your clarifications, 
> > Sébastien Prouvost 
> > France Telecom R&D 
> > 
> > 
> > **************************************************************
> > **************
> > **
> > - NOTICE FROM DIMENSION DATA AUSTRALIA
> > This message is confidential, and may contain proprietary or legally 
> > privileged information. If you have received this email in error, 
> > please notify the sender and delete it immediately.
> > 
> > Internet communications are not secure. You should scan this
> > message and any
> > attachments for viruses. Under no circumstances do we accept 
> > liability for
> > any loss or damage which may result from your receipt of this 
> > message or any
> > attachments.
> > **************************************************************
> > **************
> > ** 
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Prasanna <[email-masked]>
Date: Thu, 06 May 2004 21:20:21 +0530

Hi,
	In this case there is no question of retransmission as the moment a
200 for INVITE is received, the transaction terminates.  And as suggested in
the original response, the transaction has accepted these messages, so there
will be no question of retransmission whatso ever.
Regards,
Prasanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chadha
Retesh-A19894
Sent: Thursday, May 06, 2004 4:51 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

Regards
Retesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, May 06, 2004 4:27 PM
To: Retesh Chadha; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

Hi

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chadha
Retesh-A19894
Sent: Thursday, May 06, 2004 4:04 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

Similar is the following scenario ---
200 ok to an INVITE matching the transaction (same branch in top via
header), but not matching the dialog parameters (from tag, call-tag, etc).
In this case, the INVITE  transaction will be terminated with an erroneous
200 ok. Now, if the correct 200 response comes, it will be considered as a
retransmission and ignored.

[Ranjit] I think if the 200 OK received is not matching the dialog
parameters, it is as good as not receiving the 200 OK. So UAC could
retransmit INVITE. 

In the above and all such cases, I feel uac should take a call on being
strict or not. If it needs to consider such responses as invalid, it should
terminate the call, and take the same action as it would have taken for a
non-successful response.

Regards
Retesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, May 06, 2004 3:40 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Bug in RFC3261 ?

> > Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 
> > specify that when Timer B (for INVITE) and Timer F (for non-INVITE)
> fire, "the
> > There are procedures and timers for this situation in 3261. Have a 
> > look at Section 17.1.1.2 and 17.1.2.2.
> > 
> > Basically the UA should wait 64*T1 (Timer 1). T1, by default, should 
> > be 500ms so your UA should wait 32 seconds for a valid response.
> > 
> > HTH,
> > 
> > B
> > 
> > Ben Gatewood
> > Dimension Data
> > SIP Wookie
> > Internet communications are not secure. You should scan this message 
> > and any attachments for viruses. Under no circumstances do we accept
> > liability for