[SIPForum-discussion] SIP Call Hold & Retrieval

Venkata Ramesh B bvrameshbv at gmail.com
Thu Jun 11 04:01:17 UTC 2009


Hi,

I have a few questions about the SIP call hold. I am new to this forum.
Please redirect me if I am posting to a wrong group.

We have a interworking node between the PSTN network and SIP network. The
PSTN network keeps call on hold. So the interworking node sends "a=sendonly"
in a ReInvite SDP. The SIP responds with "a=recvonly" in the 200 OK SDP.

1. Can the SIP user do the codec re-negotiation while it is kept on hold
(During codec re-negotiation, SIP user maintains "a=recvonly" so that media
stream maintains the same direction attribute) ?

2. Can the SIP user send a new Reinvite with attribute "a=sendonly" ? If it
sends, what is the expected behaviour at interworking node ? What happens to
the previous "sendonly" received from PSTN ?
As per the RFC 3264, "If the stream to be placed on hold was previously a
recvonly media stream, it is placed on hold by marking it inactive.". Of
course the SIP user is not following RFC. But, what is the expected
behaviour at the interworking node ? Any standards reference ?

3. Can the SIP user send a new Reinvite with attribute "a=sendrecv" ? i.e.
PSTN user keeps the call on hold and IMS user retrieves it ? Is this
possible at all ? If that happens, what is the expected behaviour at the
interworking node ? Any standards reference ?

Thanks & Regards,
Ramesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090611/d40ff55e/attachment-0002.html>


More information about the discussion mailing list