Dale Worley wrote:
MessageMy interpretation is that it is always acceptable for one UA to send
a re-INVITE to request to change the media status in any way it wishes. In
this case, one UA is requesting that (in PSTN terms) the call be taken off
hold by the other UA.
I'm with you so far.
However, if the other UA is unable or unwilling to to
this, it should reject the re-INVITE on the grounds that it does not like
the SDP, which according to RFC 3261 section 13.3.1.3 means it should send a
488 (Not Acceptable Here) response.
You *could* do this, but it seems far more severe than necessary. It is
entirely sufficient for it to respond the directionality it desires.
IMO an offerer should *always* offer the directionality it desires,
rather than try to second guess what the other side desires. The
answerer can then always respond as it desires.
Paul
Dale
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Chadha Retesh-A19894
Sent: Tuesday, August 02, 2005 6:26 AM
To: [email protected]; [email protected]
Subject: [Sip] question rgding call hold
I have a query regarding call hold. I am not really sure if this is
already discussed, but wanted an advice from the experts here.
Is the following call flow acceptable??
Make Call
Invite -->
200 ok <--
ACK -->
Hold --->
INVITE(sendonly) -->
200 ok(recvonly) <---
ACK -->
INVITE(sendrecv) <--- ??????
What should be the response to this INVITE request - 200ok with sendonly
or 400 bad request?
Wont this INVITE mean, that the remote is trying to release local hold,
which is unacceptable?
Also, i have not seen any rules regarding this in RFC 3261 or the sipping
examples draft. Please redirect me to any other references, which talk about
attribute modes in subsequent requests after call hold.
Thanks in advance
Retesh
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
