Jakub Jablonski XB (AL/EAB) wrote: > Hi, > is this clear from RFCs, that you shouldn't send an offer in the last > message in the transaction?
No, it is not especially clear. It was the subject of extensive debate some time ago. See draft-sawada-sipping-sip-offeranswer-00.txt for a much more extensive discussion. >>From the other side, how should the UA treat the SDP, if it is received > in the last message in the transaction? > > Jakub > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 24 February 2006 11:11 > To: Jakub Jablonski XB (AL/EAB) > Cc: [email protected]; > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] SDP offer in response to UPDATE > or PRACK > > > > Hi jakub, > > There should be at most one offer/answer per transaction.Please > refer the following link. > > http://www1.ietf.org/mail-archive/web/sip/current/msg11956.html > <http://www1.ietf.org/mail-archive/web/sip/current/msg11956.html> > > so, 2xx for PRACK or 2xx for UPDATE cannot carry the SDP since > there is no subsequent message in the corresponding > transaction to carry the answer. > > if at all offer/answer exchange is required in the below > scenarios then it can happen b/w > > i) PRACK and its 2xx > ii) UPDATE and its 2xx. > > Rgds, > Gururaj > > Inactive hide details for "Jakub Jablonski XB \(AL/EAB\)" > <[EMAIL PROTECTED]>"Jakub Jablonski XB \(AL/EAB\)" > <[EMAIL PROTECTED]> > > > > > "Jakub Jablonski XB \(AL/EAB\)" > <[EMAIL PROTECTED]> > Sent by: > [EMAIL PROTECTED] > > 02/24/2006 03:08 PM > > > > To > > <[email protected]> > > > cc > > > > > Subject > > [Sip-implementors] SDP offer in response to UPDATE or PRACK > > > Hi, > is it possible to send an new offer in the 2xx response to > UPDATE or > PRACK? > > Case 1: > > UAC UAS > | F1 INVITE (SDP) | <- The offer in offer/answer > model > |-------------------->| > | F2 1xx-rel (SDP) | <- The answer in offer/answer > model > |<--------------------| > | F3 PRACK | > |-------------------->| > | F4 2xx PRA (SDP) | <- The offer in offer/answer > model ? > |<--------------------| > | F5 UPDATE (SDP) | <- The answer in offer/answer > model ? > |<--------------------| > | F6 2xx UPDATE | > |-------------------->| > > Case 2: > > UAC UAS > | F1 INVITE (SDP) | <- The offer in offer/answer > model > |-------------------->| > | F2 1xx-rel (SDP) | <- The answer in offer/answer > model > |<--------------------| > | F3 PRACK | > |-------------------->| > | F4 2xx PRACK | > |<--------------------| > | F5 UPDATE | > |<--------------------| > | F6 2xx UPDATE (SDP) | <- The offer in offer/answer > model ? > |-------------------->| > | F7 UPDATE (SDP) | <- The answer in offer/answer > model ? > |<--------------------| > | F8 2xx UPDATE | > |-------------------->| > > These cases are not mentioned in > draft-sawada-sipping-sip-offeranswer-00.txt, > but I didn't find anything in RFCs that would forbid them. > > > Thanks, > Jakub > > _______________________________________________ > Sip-implementors mailing list > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > *********************** FSS-Unclassified *********************** > > > _______________________________________________ > 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
