Subject: [Sip] Bug in RFC3261 ?

From: PROUVOST Sébastien FTRD/DAC/ISS <[email-masked]>
Date: Tue, 4 May 2004 11:49:52 +0200

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

---

From: [email-masked]
Date: Wed, 5 May 2004 08:33:12 +1000

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.
******************************************************************************

---

From: [email-masked]
Date: Wed, 5 May 2004 10:01:36 +1000

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

[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. 

HTH, 

B

Ben Gatewood
Dimension Data
SIP Wookie

        To:        <[email-masked]> 
        cc:         

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.
******************************************************************************

---

From: [email-masked]
Date: Wed, 5 May 2004 12:02:30 +0300

OK, now I get your question.
 
UAC core does not wait. What it can do is issue the request again.
 
/Hisham

-----Original Message-----
From: ext PROUVOST Sébastien FTRD/DAC/ISS [mailto:[email-masked]]
Sent: 05.May.2004 11:49
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE : [Sip] Bug in RFC3261 ?

This does not really correspond to what I am saying. What I am saying is the following: 
 
- I send a request (UPDATE for example)
- I receive a 200 OK for this request. At this point the transaction enters the state "Completed" and then "Terminated". Then the transaction is destroyed and no more transaction layer timer is running for this transaction.
- The 200 OK is passed to the UAC Core layer. But this 200 OK contains two Via headers. Section 8.1.3.3 (that handles UAC Core procedures) says : "If more than one Via header field value is present in a response, the UAC SHOULD discard the message."" So the UAC Core discards the message. But the UAC Core is still waiting for a response (although the corresponding transaction is terminated from the transaction layer point of view). 
 
When does the UAC Core stop waiting for a response ?
 
Sébastien.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 5 mai 2004 10:12
À : [email-masked]; PROUVOST Sébastien FTRD/DAC/ISS
Cc : [email-masked]; [email-masked]
Objet : 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 :-) 

B

Ben Gatewood
Dimension Data
SIP Wookie

05/05/2004 08:33 AM 

Hi Sébastien, 

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

04/05/2004 07:49 PM 

       To:        <[email-masked]> 
       cc:         

Hi, 

Sébastien Prouvost 
France Telecom R&D

---

From: [email-masked]
Date: Thu, 6 May 2004 15:39:33 +0530

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.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 06, 2004 3:06 PM
> To: [email-masked]; [email-masked];
> [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
> 
> > From: Prasanna [mailto:[email-masked]]
> > Sent: Thursday, May 06, 2004 1:49 PM
> > To: [email-masked]; [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
> > 
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Wednesday, May 05, 2004 1:42 PM
> > To: [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
> > <[email-masked]> 
> > 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). 
> > **************************************************************
> > **************
> > **
> > 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

---

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

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.

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

---

From: [email-masked]
Date: Thu, 6 May 2004 16:27:21 +0530

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. 

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 ?

> > 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.
> > 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.
> > 
> > 
> > validation of the Table 2 / Table 3 requirements. What if there is 
> > 423 without Min-Expires or a 200 for INVITE without Contact?
> > 
> > privileged information. If you have received this email in error, 
> > please notify the sender and delete it immediately.
> > 
> > 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
> > 
> 
> 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: PROUVOST Sébastien FTRD/DAC/ISS <[email-masked]>
Date: Wed, 5 May 2004 10:49:18 +0200

Sébastien.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 5 mai 2004 10:12
À : [email-masked]; PROUVOST Sébastien FTRD/DAC/ISS
Cc : [email-masked]; [email-masked]
Objet : RE: [Sip] Bug in RFC3261 ?

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, 

B

Ben Gatewood
Dimension Data
SIP Wookie

05/05/2004 08:33 AM 

Hi Sébastien, 

HTH, 

B

Ben Gatewood
Dimension Data
SIP Wookie

04/05/2004 07:49 PM 

       To:        <[email-masked]> 
       cc:         

Hi, 

Sébastien Prouvost 
France Telecom R&D

---

From: PROUVOST Sébastien FTRD/DAC/ISS <[email-masked]>
Date: Wed, 5 May 2004 11:42:10 +0200

I am not sure this is the right behavior ... What if it gets the same answer ? It sends again the same request ?
Shouldn't the behavior of the UAC Core receiving such an answer be specified ? 

Sébastien.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 5 mai 2004 11:03
À : PROUVOST Sébastien FTRD/DAC/ISS; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: RE : [Sip] Bug in RFC3261 ?

 
/Hisham

-----Original Message-----
From: ext PROUVOST Sébastien FTRD/DAC/ISS [mailto:[email-masked]]
Sent: 05.May.2004 11:49
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE : [Sip] Bug in RFC3261 ?

 
 
Sébastien.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 5 mai 2004 10:12
À : [email-masked]; PROUVOST Sébastien FTRD/DAC/ISS
Cc : [email-masked]; [email-masked]
Objet : RE: [Sip] Bug in RFC3261 ?

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, 

B

Ben Gatewood
Dimension Data
SIP Wookie

05/05/2004 08:33 AM 

Hi Sébastien, 

HTH, 

B

Ben Gatewood
Dimension Data
SIP Wookie

04/05/2004 07:49 PM 

       To:        <[email-masked]> 
       cc:         

Hi, 

Sébastien Prouvost 
France Telecom R&D

---

From: [email-masked]
Date: Fri, 7 May 2004 13:52:42 +0530

Thanks & Regards,

Nataraju A.B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PROUVOST Sébastien FTRD/DAC/ISS
Sent: Wednesday, May 05, 2004 2:19 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE : [Sip] Bug in RFC3261 ?

 [Nataraju] when UAC core receives a response with more than one VIA header means intermediate entity did not remove the VIA header. Or some intermediate entities might have maliciously added the via header. Hence the UAC will discard the response

Sébastien.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 5 mai 2004 10:12
À : [email-masked]; PROUVOST Sébastien FTRD/DAC/ISS
Cc : [email-masked]; [email-masked]
Objet : RE: [Sip] Bug in RFC3261 ?

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, 

B

Ben Gatewood
Dimension Data
SIP Wookie

05/05/2004 08:33 AM 

Hi Sébastien, 

HTH, 

B

Ben Gatewood
Dimension Data
SIP Wookie

04/05/2004 07:49 PM 

       To:        <[email-masked]> 
       cc:         

Hi, 

Sébastien Prouvost 
France Telecom R&D