Eric, see inline
Regards, Jeroen ----- Original Message ----- From: "Eric Tremblay" <[EMAIL PROTECTED]> To: <[email protected]>; <[email protected]> Sent: Thursday, April 13, 2006 2:30 AM Subject: Re: [Sip-implementors] [Sip] Simultaneous client Non-InviteTransactions > Oops, sorry, I realize this should have been posted to sip-implementors. > > Moving to the proper list, and please make sure to reply only to > sip-implementors. > > Regards, > > EricT > > > > ________________________________ > > From: Eric Tremblay [mailto:[EMAIL PROTECTED] > Sent: April 12, 2006 20:24 > To: [email protected] > Subject: [Sip] Simultaneous client Non-Invite Transactions > > > > Hi All, > > I have been digging the following question for a while without > any clear answers, so I think it may be worth a clarification in RFC > 3261. > > Is it allowed to send a non-INVITE request on an existing dialog > while there is already a client non-INVITE request in progress on this > dialog? > > Here is a summary of my findings: > > - In SIPWG Bugzilla, bug 113: The authors clearly wanted to > allow simultaneous non-INVITE transactions. > - In 3261, section 12.2.1.1 discusses how a UAC generates a > request within a dialog. This section does not disallow a UAC from > creating multiple non-INVITE client transactions. > > - In 3261, section 12.2.2 discusses how a UAS generates a > response to a request within a dialog. This section explicitly states > that a 500 response must be sent if the incoming request is > out-of-order. > > - In 3261, section 28, changes from RFC 2543, clearly states > that we can have multiple non-INVITE transactions on a dialog: > > -- quote > o RFC 2543 was silent on whether a UA could initiate a new > transaction to a peer while another was in progress. That > is now > specified here. It is allowed for non-INVITE requests, > disallowed > for INVITE. > --- endquote > > So on the UAC side, we allow it, and on the UAS side, we allow > it if the network behaves correctly, that is it does not reorder the > incoming requests. > > The problem I have is with a subscriber receiving multiple > NOTIFY over UDP, and as you might have guessed, the network reorders the > packets and then it sends a 500 to a NOTIFY, as per 3261, which removes > the subscription at the notifier. Is this the normal and expected > behavior? > >From RFC3265: A NOTIFY request is considered failed if the response times out, or a non-200 class response code is received which has no "Retry-After" header and no implied further action which can be taken to retry the request (e.g., "401 Authorization Required".)This situation qualifies as one for which there is an implied further action (namely, resend with a proper CSeq). To make this extra clear, the UAS should probably add a Retry-After: 0 header to its 500 response. The 500 response code for out-of-sequence is an unfortunate protocol choice, as it is ambiguous. But that is a different issue > Thank you for any pointers you can provide, > > Regards, > > EricT > ________________________________________ > Eric Tremblay <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > Technical Product Manager > M5T Centre D'Excellence en Telecom, Inc. > http://www.m5t.com <http://www.m5t.com> > tel: +1-819-829-3972 x238 > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
