I agree - the example is not flawed (at least in the way the errata reports).

Muthu seems to troubled by the reuse of the call-id and from tag when the initial transaction didn't create a dialog. While doing so is not required by the specification, nothing makes it illegal either.

RjS

On Feb 9, 2009, at 11:59 AM, Brett Tate wrote:

The reported error does not sound correct. If RFC 4028 is incorrect concerning From tag, so is RFC 3261 (section 8.1 and likely other sections) and various other RFCs.



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of RFC
Errata System
Sent: Monday, February 09, 2009 12:37 PM
To: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [Sip] [Technical Errata Reported] RFC4028 (1681)


The following errata report has been submitted for RFC4028,
"Session Timers in the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4028&eid=1681

--------------------------------------
Type: Technical
Reported by: Muthu Arul Mozhi <[email protected]>

Section: 13

Original Text
-------------
In section 13 (Example Call Flow) the From tag never changes
between the initial INVITE message and the subsequent INVITE
messages sent after receiving a 422:

message 1
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
  Supported: timer
  Session-Expires: 50
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314159 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp
  Content-Length: 142

message 4
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
  Supported: timer
  Session-Expires: 3600
  Min-SE: 3600
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314160 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp
  Content-Length: 142

message 10
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
  Supported: timer
  Session-Expires: 4000
  Min-SE: 4000
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314161 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp

However, as per RFC 3261, if an initial INVITE generates a non-2xx final response, that terminates all sessions and all dialogs that were created.

Hence, these are not re-INVITE messages, rather new INVITE messages and
should use a new From tag.

Corrected Text
--------------
message 1
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
  Supported: timer
  Session-Expires: 50
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314159 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp
  Content-Length: 142

message 4
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
  Supported: timer
  Session-Expires: 3600
  Min-SE: 3600
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=2568701785
  Call-ID: a84b4c76e66710
  CSeq: 314160 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp
  Content-Length: 142

message 10
  INVITE sips:[email protected] SIP/2.0
  Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
  Supported: timer
  Session-Expires: 4000
  Min-SE: 4000
  Max-Forwards: 70
  To: Bob <sips:[email protected]>
  From: Alice <sips:[email protected]>;tag=5647301796
  Call-ID: a84b4c76e66710
  CSeq: 314161 INVITE
  Contact: <sips:[email protected]>
  Content-Type: application/sdp

Notes
-----
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, February 09, 2009 10:09 PM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram
Mohan R (rmohanr)
Subject: Re: UAS behavior after sending 422 for initial INVITE

yes, I think so.

        Paul

Muthu ArulMozhi Perumal (mperumal) wrote:
In section 13 (Example Call Flow) of RFC 4028 the From tag never changes between the initial INVITE message and the subsequent INVITE messages
sent after receiving a 422:

message 1
  INVITE sips:[email protected] SIP/2.0
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710

message 4
  INVITE sips:[email protected] SIP/2.0
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710

message 10
  INVITE sips:[email protected] SIP/2.0
  From: Alice <sips:[email protected]>;tag=1928301774
  Call-ID: a84b4c76e66710

Is this a bug in the RFC?

thanks,
Muthu

|-----Original Message-----
|From: Paul Kyzivat (pkyzivat)
|Sent: Wednesday, February 04, 2009 12:36 AM
|To: Radha Krishna Saragadam (rsaragad)
|Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal);
Ram Mohan R (rmohanr)
|Subject: Re: UAS behavior after sending 422 for initial INVITE
|
|Radha,
|
|It is not a reinvite, because a dialog was never established - the
first
|call failed.
|
|So you are starting a new invite. You can use the same callid, but
|should use a new from-tag.
|
|       Thanks,
|       Paul
|
|Radha Krishna Saragadam (rsaragad) wrote:
|> Hi Paul
|>
|>   My question is for initial INVITE. For initial INVITE if UA
|> receives 422 and UA want to retry INVITE with new value increased
value
|> then what should be the To(with tag), From(with tag) and CallID
values?
|> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for
|> To,From and CallID
|>
|> Regards
|> S.Radha krishna

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4028 (draft-ietf-sip-session-timer-15)
--------------------------------------
Title : Session Timers in the Session Initiation Protocol
(SIP)
Publication Date    : April 2005
Author(s)           : S. Donovan, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip

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

Reply via email to