I was trying to prove that if offer contains c=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 think I confused things
with my explanation in my previous email :-)
For the example used
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
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
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.
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
A Re-INVITE with SDP
v=0
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
