Hi,
One IS allowed to send SDP in unreliable 18x responses, but the same SDP MUST ALSO be sent in a reliable response (200 OK). Regards, Christer Holmberg Ericsson Finland [EMAIL PROTECTED] wrote: > Hi Bhagat, > > Regarding your query, the offer/answer model prohibits > any unreliable 1xx to contain SDP information. Any answer > to an offer can only be given in a *reliable* response to > the message (In case of an offer in the INVITE, this is > either a reliable provisional or a 200 OK response). I > think you are referring to normal provisional responses > as being reliable since its a loss-less environment. But, > it may so happen that the peer may not be ready for > understading SDP from non-reliable provisional responses, > as its not expected there. > > That said, there are 2 scenarios : > > a) INVITE contained SDP: > The UAS cannot send 2 different answers to the offer. > The first reliable provisional response contained the > answer, a second one cannot change the answer (!) > > b) INVITE did not contain SDP: > The UAS sends an offer in its response. However, there > can be only one outstanding SDP offer at any time from > the UAS. So, the first reliable provisional response > contained the offer which must be responded to by the UAC. > Another offer cannot anyways be made till that time as > the UAC sends a PRACK (or an ACK) with the answer. > > Hence, the scenario you mentioned cannot be held good for > SDP in particular at least. > > The second part of the question was regarding whether the > same provisional response code can be used with different > application information (I understand you mean different > application headers here)... again, I believe this is not > normally done in a SIP-SIP call. (Others may correct me > if I'm incorrect... or if some other scenario desires this) > > Isn't it easier to look for more application data if you > know the response is different in some way from the previous > response; rather than find out looking at the entire message > to see if there's any new information? Though, I believe, > if you are implementing peers on both ends (UAC and UAS) of > the call, nothing in the spec stops you from doing the > scenario you mentioned (for application data, that is :) > > Regards, > Siddharth. > > ------------------- > Siddharth Toshniwal @ Hughes Software Systems > Bangalore, India. > http://www.hssworld.com > > "Janarthanan, Bhagatram" <[EMAIL PROTECTED]> on 07/09/2002 > 06:11:12 AM > > To: [EMAIL PROTECTED] > cc: (bcc: Siddharth J Toshniwal/HSSBLR) > > Subject: [Sip-implementors] 1xx responses to INVITE > > Hi , > > In a loss-less environment, where UAs is not using reliable 1xx messages, > is > it valid for the UaS to send two 1xx response with the same response code, > but with different sdp/appln information. > > For eg, is the following allowed ? > > ----INV------------> > <---182--appln-part1--- > <---182--appln-part2--- > > Thanks > Bhagat > > _______________________________________________ > 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
