Subject: [Sip] question rgding call hold

From: Chadha Retesh-A19894 <[email-masked]>
Date: Tue, 2 Aug 2005 15:56:24 +0530

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 mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Aug 2005 07:41:49 -0400

Chadha Retesh-A19894 wrote:
> 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.
>  
> What should be the response to this INVITE request - 200ok with sendonly 
> or 400 bad request?

IMO this is clearly a valid request. Barring other issues, the response 
should be 200. The direction in the response could be 
sendrecv/sendonly/recvonly/inactive since all are compatible with the 
offer. If the end answering that offer wants to preserve the status quo, 
then it should simply respond with a=sendonly.

> Wont this INVITE mean, that the remote is trying to release local hold, 

All this has done then is that the party on the right has indicated a 
*willingness* or *desire* to go off hold, while the party on the left 
has indicated it still wants to maintain the call on hold. There is no 
way that the party on the right can *force* the call out of hold state.

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

I'm not aware of much that has been published on this, though it has 
been discussed on this list several times. I think this behavior is 
implicit in the specs, but it clearly isn't especially obvious.

The spec that has anything to say about this is RFC3264.

	Paul

> Thanks in advance
> Retesh
> 
> 
> ------------------------------------------------------------------------
>