[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sip] RE: [Sip-implementors] Changes from bis-09 to RFC 3261



I trimmed those for our needs. I'll send the raw changes as sent to the sip mailing list in another following mail.

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, July 24, 2002 8:52 AM
> To: sip@ietf.org; sip-implementors@cs.columbia.edu
> Subject: [Sip-implementors] Changes from bis-09 to RFC 3261
> 
> * It was reported that the processing of timer D in the transaction
> layer was wrong. This is the timer that fires in the INVITE client
> transaction after it has ceased waiting for retransmits of the final
> response, in order to send an ACK. Bis-09 said to inform the TU of a
> timeout. However, this is not a failure condition, so that makes no
> sense. As such, Section 17.1.1.2, now reads:
> 
> "If timer D fires while the client transaction is in the "Completed"
> state, the client transaction MUST move to the terminated state."
> 
> 
> * We clarified that, when moving to terminated state for client invite
> transactions, you need to delete the transaction immediately.
> 
> * The rules in Section 17.2.3, for matching a request to a
> transaction when the branch ID had the cookie, were not quite
> right. In particular, they were wrong for
> CANCEL. The rules were updated:
> 
>     The
>     request matches a transaction if:
> 
>      1.  the branch parameter in the request
>     is equal to the one in the top Via header field of the 
> request that
>     created the transaction, and
> 
>      2. the sent-by value in the top Via of the
>     request is equal to the one in the request that created the
>     transaction, and
> 
>      3. the method of the request matches the one that created
>     the transaction, except for ACK, where the method of the 
> request that
>     created the transaction is INVITE.
> 
> 
> * Section 18.1.1 led you to believe that if a request was too large
> for UDP, and you resent it, it had to be with TCP. ACtually, it can be
> with any congestion controlled transport (as defined by RFC 2914). We
> also clarified that if you change transports, the Via transport value
> needs to change. (its TCP in any case for our sip stack)
> 

> * Rules for equality matching of From and To header fields were
> absent, even though there were references elsewhere in the text to the
> existence of such rules. They were added. See Sections 20.20 and
> 20.39.
> 
> 
> * The spec was inconsistent on the maximum value of the expires
> Contact parameter and the Expires header field. They were made
> consistent. The maximum value is (2**32)-1.
> 
>
> * Section 20.37, on the Unsupported header field, failed to mention
> that a compact form was defined (the other headers with compact forms
> explicitly mention it in their section 20's). A mention was added.
> 
> * The transaction matching algorithm requires rules for equality of
> Via header fields, but none was defined. A rule was added, see Section
> 20.42.
> 
> * Section 21.4.15 indicated that inclusion of the unsupported
> extensions in a 420 response was a SHOULD. This is inconsistent with
> other text that said it was a MUST. Its a MUST. Section 21.4.15 was
> updated to reflect that.
>
> 
> * The BNF had this construct where there was a list of choices, and
> one of the elements in the choice was optional:
> 
> 
>        foo  =  bar / baz / [boo]
> 
> turns out, this is actually not right, since it allows for an empty
> value for foo, which is not what is intended. Therefore, the text that
> described this convention, and all usages of it in the BNF, were
> removed.
> 
> * The BNF for the user part of the SIP/SIPS URI allowed for an empty
> username and an @ sign; that is "sip:@foo.com" was valid according to
> the BNF. Its not. The BNF for the SIP-URI and SIPS-URI constructions
> was updated to correct this. Here is the change that was made (^
> characters indicate where the change is):
> 
> 
> OLD
>     SIP-URI          =  "sip:" [ userinfo "@" ] hostport
>                         uri-parameters [ headers ]
>     SIPS-URI         =  "sips:" [ userinfo "@" ] hostport
>                         uri-parameters [ headers ]
>     userinfo         =  [ user / telephone-subscriber [ ":" 
> password ]]
>     user             =  *( unreserved / escaped / user-unreserved )
> 
> NEW
>     SIP-URI          =  "sip:" [ userinfo ] hostport
>                                          ^^  delete "@"
>                         uri-parameters [ headers ]
>     SIPS-URI         =  "sips:" [ userinfo ] hostport
>                                           ^^ delete "@"
>                         uri-parameters [ headers ]
>     userinfo         =  ( user / telephone-subscriber ) [ ":" 
> password ] "@"
>                         ^                             ^       
>           ^^^^
>     user             =  1*( unreserved / escaped / user-unreserved )
>                         ^
> 
> * The Accept, Accept-Encoding, and Accept-Language and Allow 
> BNF were all
> updated to allow for the header to have an empty value.
> 
> 
> * The BNF for rfc1123-date was wrong. It was missing a space after the
> comma. It was corrected thusly:
> 
> OLD
> rfc1123-date  =  wkday "," date1 SP time SP "GMT"
> 
> NEW
> rfc1123-date  =  wkday "," SP date1 SP time SP "GMT"
>                             ^^
> 
> * The BNF for the Timestamp header was wrong. It was missing an
> explicit LWS between the the send time and the delay. It was
> added. The BNF was changed thusly:
> 
> 
> OLD
> Timestamp  =  "Timestamp" HCOLON 1*(DIGIT)
>                [ "." *(DIGIT) ] [ delay ]
> 
> NEW
> Timestamp  =  "Timestamp" HCOLON 1*(DIGIT)
>                [ "." *(DIGIT) ] [ LWS delay ]
>                                   ^^^
//lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip