Hi, >>Unfortunately I don't have a reference to the thread Paul is refering to. >> >>However, I can't remember any technical reason why the rule could not be relaxed (apart from "because the RFC says so" >>type of comments). >> >>So, unless there IS a technical reason why the rule can't be relaxed, I really think we should do that. > >My recollection is that nobody could find any compelling >technical reason why this rule is there. But it was also the >position of some (I think maybe Rohan was among them) that >since the rule is enshrined in an RFC it takes a compelling >argument to change it. A good argument would be if there was >no reasonable work-around. But such work-arounds were >demonstrated, so eventually the discussion dried up. > >Personally, I don't have a strong position on this, but tend >to agree with those resisting the change. Suppose this change >were made. That would seem to create interop problems with >UAs that haven't implemented the change.
The question is: how many UAs are we really talking about? It would have to be a UA that: 1. Accepts INVITEs without SDP (ok, I guess there are quite many of those) AND: 2. Supports PRACK (a decent number of those out there also, I guess) AND: 3. Supports offer/answer with PRACK (now the number starts to decrease, I'm pretty sure of) AND: 4. Cares whether the answer (when the offer is sent in a reliable 18x) actually comes in the PRACK AND: 5. Are deplyed in environments where initial INVITEs are sent without SDP AND: 6. It would be impossible to, in a relatively easy way, update the software in those terminals that actually do everything listed above >Dealing with that would be more trouble than dealing with the current situation. Maybe we should try to figure out whether it really would be a problem. We did that when we removed the comment part from the Via header. Another thing would be to either only indicate 100rel as supported in the INVITE, and assume the receiver uses it only when needed, or to allow a UAS to send 18x unreliably even if required by the UAC. But, that would probable not be a good idea, because there may be other reasons than SDP why a 18x must be sent reliably. Regards, Christer > > Because, defining this send-dummy-SDP-and-then-UPDATE hack, > just because an RFC says something, is a really bad thing to > do (again, assuming that there is no real technical reason > behind the RFC text). > > > > (And, one COULD maybe also end up in similar situations as those I > > described in the thread about rejecting offers received in PRACK.) > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > To: Ramesh > > Cc: [email protected] > > Sent: 3.11.2005 22:38 > > Subject: Re: [Sip-implementors] PRAck and H323 Slow start. > > > > A long time ago there was a long discussion thread about > these cases > > where an immediate answer is required. There were arguments > that the > > rules mandating this needed to be relaxed, and there were > > counterarguments providing reasonable workarounds. > > > > Does anybody still have a reference to that thread? > > > > One possible solution is to is to return an answer with all > the media > > streams set to inactive, or black holed. Then later, when > you have the > > info, send an UPDATE. > > > > Paul > > > > Ramesh wrote: > > > >>Hi, > >>The PRAck RFC states that if a 100-rel message is received with SDP > > > > (offer) > > > >>the PRAck message for that MUST contain an Answer. A problem arises > > > > when > > > >>dealing with interop of H323 slow start, wherein we don't > get the SDP > > > > until > > > >>the call gets connected. So, Do we turn off PRAck for situation > > > > wherein we > > > >>deal with H323 slow start or is there another solution to this issue > > > > where > > > >>we can use PRAck and Slow start. > >> > >>-- > >>cheers > >>ramesh > >>_______________________________________________ > >>Sip-implementors mailing list > >>[email protected] > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
