Hi Paul, I am definately not saying that people should put their SDPs wherever they want.
I am saying that people should look at this issue from a o/a state machine perspective, and not only focus on whether there is an SDP body in a message or not. For example, you say that if the offer was sent in a reliable 18x, you find no rationale to include a copy of it again in 200. I am not sure I think it's that clear, but that we could argue about forever. The important thing is that IF a SDP has already been sent reliable in 18x, it should not matter what/if you include in 200. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 11. huhtikuuta 2007 22:57 > To: Christer Holmberg (JO/LMF) > Cc: Bu, Wenfei (Leo); [EMAIL PROTECTED] > Subject: Re: VS: [Sip-implementors] SDP offer/answer for delay media > > Christer, > > Your comments indicate how including SDP in extra places > would not constitute offers or answers and so how it ought > not cause problems. > > But regardless of that, SDP in those places does not seem to > be allowed by existing standards. There is already enough > problem with redundant SDP that was grandfathered in by the > wording of the specs, and it has proven to cause trouble. So > I would not want to explicitly allow this in other places. > > If you want to put SDP in these places, in a non-conformant > way, with the expectation that others will not be bothered by > it, they you are free to try that. But don't complain if > somebody handles it in a way different from what you expect. > > Paul > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > >>> All, > >>> > >>> This was talked before but it still looks not clear: > >>> > >>> UAC UAS > >>> > >>> ----------->F1 INVITE w/o SDP > >>> > >>> <-----------F2 18X w/ SDP1 > >>> > >>> ----------->F3 PRACK w/ SDP2 > >>> > >>> <-----------F4 200 for PRACK > >>> > >>> <-----------F5 200 for INVITE w/ SDP1 > >>> > >>> ----------->F6 ACK (w/ SDP2 ???) > >>> > >>> > >>> > >>> My questions: > >>> > >>> 1. Could 200 for INVITE in F5 carry an SDP? > > > >> No. There has already been one o/a in the transaction initiated F1. > >> There cannot be another offer in the same transaction. > > As far as I understand, the 200 for INVITE does not carry a > new offer. It carries the same answer that was carried in 18x (F2). > > > > > >> In the case where the invite carries an offer sdp, and > there is SDP > >> in a provisional response that same sdp can be in the 200. That > >> wording in > >> 3261 that specifies this is intended for unreliable > provisionals, but > >> has been interpreted to also be possible when there was a reliable > >> response with an answer. But I can find no rationale for > allowing an > >> offer that was sent in a reliable provisional to be sent > again in the > >> 200 response to the invite. > > > > Since SIP only allows at most one o/a exchange per SIP > transaction, I think the o/a state machine should know that > the SDP in 200 is of no meaning - no matter if it's a copy of > a previously sent (in a reliable 18x) offer or anwer. > > > > It's the same thing if you send an offer, or answer, in a > reliable 18x, and then copy it in subsequent reliable 18x > responses for the same transaction - from an o/a perspective > they have no meaning. > > > > > >> Also I can find no rationale for allowing a *new* offer to be > >> included in the 200 response to an invite if the initial > o/a has been completed. > > > > Correct. Again, at most one o/a exchange per SIP > transaction. Keeping > > that in mind will take you pretty far, I think :) > > > > > >>> 2. If 200 in F5 carries the same SDP with that in 18X, should UAC > >>> send an ACK with SDP? > >>> > >> Definitely not. > > > > Agree. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > 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
