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.
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.
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. 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.
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.
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
