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 over a=recvonly
> Put the call on hold and answer SDP contains c=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 :-)
> 3. Give precedence to a=recvonly attribute
> Since c=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
> s=-
> c=IN IP4 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 and any a= attribute. So, my question is can we
> generalize that if c=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]> wrote:
>
>> You are asking two different questions. More inline.
>>
>> Subbu Rajendran wrote:
>>
>>> Hi,
>>> SIP RFC 2543 uses c=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
>>> s=-
>>> c=IN IP4 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
> 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
