Re: [Technical Errata Reported] RFC4028 (1681)

Robert Sparks <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <[email protected]> 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.