Gotcha. For the below example, the UAS will answer in 200 OK with Media Server parameters (INVITE had offer)
When user answers, the UAS will wait for ACK, then initiate a reINVITE for user media. Correct? -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Friday, October 28, 2005 7:13 PM To: Niranjan Gopalakrishnan Cc: Ben Gatewood; [email protected] Subject: Re: [Sip-implementors] Offer-Answer in SIP Niranjan Gopalakrishnan wrote: > I have a question on the same lines. > > Lets say INVITE and 183 had an offer and answer. > Is it possible for 200 response to have a new offer? > For example 183 has SDP of a Media server (different IP)which plays an > announcement. > Then user answers with 200 OK, can this be a new SDP -offer? Its a good question. The answer is NO. For details, see draft-sawada-sipping-sip-offeranswer-00.txt. Note: that draft is not intended to break any new ground - in theory all this should be derivative to the referenced RFCs. But it turns out that things are not so clear, and reasonable people can differ in interpretation. Over a year ago there were extensive discussions on the subject which resulted in a number of agreed upon interpretations. Those were never documented anywhere. Sawada has now written that all down in the draft referenced above. Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ben > Gatewood > Sent: Friday, October 28, 2005 10:28 AM > To: 'Paul Kyzivat' > Cc: [email protected] > Subject: RE: [Sip-implementors] Offer-Answer in SIP > > > Inline and snipped. > > > > >>Trying to respond to all the discussers in one response - inline. >>(BTW, I'm not seeing the blue. Would prefer conventional quoting.) > > > I just guessed which bits were blue ;-) > > >>It turns out that there are some PSTN features that seem to require >>this. In particular, there are some features that prompt for a PIN >>before permitting the call to proceed. Two-way audio before answer is >>one way to handle those in sip. > > > I considered that scenario but for some reason assumed that the call would > normally be "answered" by some kind of media server to provide that service. > Now I think about it, your way makes more sense. > > B > > > > _______________________________________________ > 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
