Subbu Rajendran wrote: > I was trying to prove that if offer contains c=0.0.0.0 <http://0.0.0.0> > and any one of the a=recvonly/sendonly/sendrecv/inactive attribute then > the client can safely process this offer in the same manner as for hold.
I don't know what you mean when you say "the client can safely process this offer in the same manner as for hold". I have the following confusion with that simple statement: - do you mean "client" or "server"? From context I think you mean server. - or do you really mean "answerer"? While the server is often the answerer, not always. - even if you meant both server and answerer, I don't know what you mean, because while the offerer can know that the intent was "hold" the answerer cannot ever know that. > I think I confused things with my explanation in my previous email :-) > > For the example used below, the gateway GW2 supports call hold using > both RFC 3261 (c=0.0.0.0 <http://0.0.0.0>) and RFC 3264 (a=inactive) > methods. > > Say SIP gateway GW1 sends an offer in reinvite to another gateway GW2 > with SDP containing c=0.0.0.0 <http://0.0.0.0> and a=recvonly. I don't understand the <http://0.0.0.0> above! This informs GW2 that GW1 does support the a=<direction> attributes. It is also an odd case - its not the normal "hold", which is typically with a=sendonly. This is compatible with "mute", but AFAIK that is normally handled locally and not signaled. (Though I don't know why.) > As per > O/A model, GW2 can generate answer with SDP containing valid IP & > a=sendonly or inactive. If fact, is is required to put a compatible attribute in the response, regardless of the c= value. > Since GW2 can neither send any RTP/RTCP as the > destination media address is not known nor receive any RTP/RTCP from > 0.0.0.0 <http://0.0.0.0>, it would be more appropriate that the answer > contains a=inactive. That is a value judgment on your part. You may use a=inactive, but you could use sendonly if you wish. But since you can't send, it makes little difference. > The '0.0.0.0 <http://0.0.0.0>' is a reserved value > and is seldom used as a packet address, and is not normally valid. The > valid c= address in the answer from GW 2 serves no purpose here or does it? A valid c= address in the response would mean very little in this particular case, since GW1 wouldn't be permitted to send to it. However it could send you RTCP, for whatever that is worth under the circumstances. > Similarly, GW1 sends an offer in reinvite to GW2 with SDP containing > c=0.0.0.0 <http://0.0.0.0> and a=sendonly. This is at least compatible with a "hold". > As per O/A model GW2 can > generate answer with SDP containing valid IP & a=recvonly or inactive. > Since GW2 can neither receive any RTP/RTCP from 0.0.0.0 <http://0.0.0.0> > nor send any RTP/RTCP as the destination media address is not known, it The 0.0.0.0 is not necessarily the source address for media that GW1 might send to GW2. So responding with a=recvonly is a meaningful thing to do. > would be appropriate that the answer contains a=inactive. Again, the > valid c= address in the answer from GW 2 serves no purpose here or does it? Again, a=inactive is a choice you can make. It might be a good choice if you intend to ignore any media that isn't from the media address that GW1 provided. So the c= can be useful for a couple of reasons. But if you prefer to respond with c=0 that is also acceptable. Thanks, Paul > If this c=address in the answer from GW2 has no purpose then it can as > well send c=0.0.0.0 <http://0.0.0.0>. Eventually making the answer > contain c=0.0.0.0 <http://0.0.0.0> and a=inactive which is nothing but > the answer, from a GW that supports both RFC 2543 and RFC 3264, for an > offer to put the call on hold. > > So I'm trying to find out if my first statement is proved to be right? > > Thanks > Subbu > > On Thu, Oct 30, 2008 at 8:30 AM, Paul Kyzivat <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Subbu Rajendran wrote: > > Hi, > Thanks for your responses. > > In my opinion, there are three options to handle this Re-INVITE > 1. Respond to Re-INVITE with 4xx say 403 Forbidden > However as, Paul pointed out, reinviting with c=0 and/or > a=sendonly is > all legal. > > > This is very bad response. > > > 2. Give precedence to c=0.0.0.0 <http://0.0.0.0> over a=recvonly > Put the call on hold and answer SDP contains c=0.0.0.0 > <http://0.0.0.0> and a=inactive. > > > I have no idea what you mean by "give precedence. > You can honor both, though in some ways the cases are degenerate. > > By honoring the offer with sendonly/recvonly (I forget which you > said it was), you assume the inverse. If that means you should > receive, then be prepared to do so. If it means you should send, > then consider you have the *option* to do so. > > But then the c=0 puts constraints on what you can do. Namely you > can't send, media or rtcp. But you can still receive. (Unless of > course you insist on symmetric RTP, in which case you will reject > incoming media. Unless of course it originates from 0.0.0.0 > <http://0.0.0.0> :-) > > > 3. Give precedence to a=recvonly attribute > Since c=0.0.0.0 <http://0.0.0.0>, it is not safe to assume > that media could be received > from the last valid remote media connection address. > > > O/A doesn't require symmetric RTP, so its possible that legitimate > media is being sent from some other address. But its now common to > require symmetric RPT. In that case see above. > > > Put the media on hold > and send a=sendonly or a=inactive in answer. However as the > local media is > put on hold, it would make more sense to send a=inactive in the > answer. > > > Deciding to "put the local media on hold" (whatever that means) is > up to you. You cannot assume that the offer *means* "hold". You are > just doing what you do when the media flows are arranged that way. > > (What does it mean to you to put the local media on hold?) > > > Next, should we publish a valid IP in the c= line in the 200 OK? > My opinion > is no, because when the remote end is ready to > exchange/accept/send media > another Re-INVITE must be send to inform it's media connection > address to > the local end, then the media connection address for the local > end can be > send in the answer. > > > Don't make unnecessary assumptions about the other end. They are > likely to get you in trouble. See the offer/answer draft for > discussion of this. You should send an answer that best expresses > what your UA wants to do, constrained by what the O/A rules let you > answer. > > In this case, if you are willing to accept media even though the > other end has given you no media address, then you should probably > provide an address. If you are not willing to accept media, then you > might as well respond with inactive and you *may* give 0 as your > address. > > Thanks, > Paul > > Therefore the answer SDP in response to the Re-INVITE based on > points 2 & > 3 shall be the same as below: > v=0 > o=user1 53655765 2353687637 IN IP4 192.168.1.101 > <http://192.168.1.101> > s=- > c=IN IP4 0.0.0.0 <http://0.0.0.0> > t=0 0 > m=audio 7001 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=inactive > > The above argument looks to be valid for cases where offer SDP in > Re-INVITE contains c=0.0.0.0 <http://0.0.0.0> and any a= > attribute. So, my question is can we > generalize that if c=0.0.0.0 <http://0.0.0.0> is present then > a=sendonly/recvonly/sendrecv/inactive can be ignored and be > processed as > call being put on hold? > > Thanks, > Subbu > > On Fri, Oct 24, 2008 at 8:26 AM, Paul Kyzivat > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > You are asking two different questions. More inline. > > Subbu Rajendran wrote: > > Hi, > SIP RFC 2543 uses c=0.0.0.0 <http://0.0.0.0> method to > put a call on hold. RFC 3264 has > introduced a=sendonly/recvonly/inactive/sendrecv > attributes that can be > used > put media to one way, hold and 2-way. However what > should be the > precedence > to be followed? Consider the case below > > The current recommendation for putting a call on hold is to > use sendonly or > inactive, rather than c=0. But that isn't normative > behavior. We haven't > standardized "putting on hold". > > However reinviting with c=0 and/or a=sendonly is all legal. > There are > reasons to do so that have nothing to do with hold. > > A Re-INVITE with SDP > > v=0 > o=user1 53655765 2353687637 IN IP4 192.168.1.100 > <http://192.168.1.100> > s=- > c=IN IP4 0.0.0.0 <http://0.0.0.0> > t=0 0 > m=audio 6001 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=recvonly > > How should the SIP endpoint receiving this Re-INVITE > interpret the SDP, > w.r.t the flow of media. Which method should be given > preference. > Any help in this context is very much appreciated. > > When on the receiving side, you need to respond > appropriately to what has > been offered, taking it at face value. You cannot draw any > reliable > conclusion about the feature that led to this signaling. It > *might* mean you > have been put on hold. Or it might simply mean that the > offerer can't handle > the media right now for some other reason. > > In this case, since the IP address of the media is 0, which > is unusuable > for sending media, you definitely won't be able to send > media, or even RTCP. > Because of the a=sendonly, you still have the opportunity to > respond with > either a=recvonly or a=inactive depending on whether you > want to receive > media in this case. > > Thanks, > Paul > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > <mailto:Sip-implementors@lists.cs.columbia.edu> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
