AC, Note this line from RFC 3264:
The offer will contain zero or more media streams ... Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. I would argue that the scenarios you're describing, where the initial offer contains incomplete connection information (either the address or port are missing), are similar to the above. The offerer wishes to communicate, but the connection information for the media streams will be added at a later time through a modified offer. Now, we can debate whether it makes sense to send incomplete information in the offer, and there may be better ways to do whatever it is you're trying to do, But from a protocol perspective, I don't see why the UAS would construe this as an error scenario and prematurely close the session by sending a BYE request (unless of course the called party hung up the phone because he couldn't hear anyone on the line :). If anyone else is aware of some clause or special case in the specs that would contradict this view, then please correct me. -- Gary Cote Award Solutions, Inc. www.awardsolutions.com On 10/11/06, chozhan A <[EMAIL PROTECTED]> wrote: > > Hi, > So i think i can assume that when a useragent receives a offer with > port set to 0 in all the m= lines they may not generate a bye but try > re-notiating the media and continue with the call. > > I have another question related to this, will the answerer generate a > BYE on receiving a offer with the ip in c= line set to 0 or can they again > re-negotiate and continue the call. > > Thanks in advance. > AC > > Paul Kyzivat <[EMAIL PROTECTED]> wrote: > First, IMO it is entirely valid to send an offer where all media lines > have the port set to zero. It is however somewhat of a strain to find a > good reason why someone would do this. (But I expect we can come up with > something.) > > Its also quite ok to send an answer with all the ports set to zero, and > if the offer had them that way then the answer must. > > While an answer may want to refuse an INVITE if all media have been > rejected, I don't believe it is required to do so. Its quite all right > to have a call with no media. I don't see why it should matter how you > get into that state: > - an initial offer with no m-lines > - because the answerer rejected all the m-lines in the offer > - because the offerer started out with port=0 in all the > m-lines of the initial offer > - because the offerer in a re-INVITE sets the port=0 in > all the m-lines. > > Some of these may make more sense than others, but they all seem ok, and > likely to eventually find a use. > > Retesh Chadha wrote: > > RFC doesnt put any restriction regarding this. > > > > It doesnt make much sense apart from the following scenario i can think > of. > > While the following is possible, it might make more sense to achieve the > intended results by using a non-zero port number and c=0.0.0.0 (a "black > holed" media address.) > > Paul > > > Say, UAC just wants to check if the UAS is available or not, and then > > when UAS responds with 200 ok, UAC negotiates the capabilities; ie UAC > > doesnt want to negotiate media unless it knows for sure UAS is > > available. Here we may think that INVITE without sdp may do the same > > but not actually because, then UAS may send sdp in 200 ok which will > > force UAC to negotiate. > > > > Dont know if the above is a practical scenario. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > --------------------------------- > Find out what India is talking about on - Yahoo! Answers India > Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get > it NOW > _______________________________________________ > 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
