[SIPForum-discussion] Proper RFC 3264 Hold Behavior in SDP

[Matt Vlasach]

SIPForum,

I have a B2BUA (SIParator) sitting between a Sonus SBC and ShoreTel PBX.

During external transfers, one-way audio occurs.

It has been found that prior to the REFER, reINVITES are sent by the  
PBX setting the "a=" attribute in the SDP header to "inactive".  This  
behavior is OK.

The REFER occurs, which is handled by the B2BUA by sending reINVITES  
to the Sonus SBC with the new SDP information.  Problem is after the  
REFER, the B2BUA sends a reINVITE to the PBX with the SDP media  
attribute to a=sendonly.  In turn, the PBX sends all following  
reINVITEs with the a=sendonly attribute setting, resulting in one way  
audio.

So where is the problem, and what is the correct behavior?  Below are  
two ideas of correct behavior:

1. The PBX should send a=sendrecv independent of the B2BUA's  
a=sendonly SDP header in the reINVITE because the PBX user wants to  
initiate a bi-directional call after explicitly setting the a= header  
to inactive when the call was put on hold.

2. The B2BUA should send a=inactive on reINVITE after REFER because  
that is what the PBX sent to the B2BUA originally, not a=sendonly.   
Sending sendonly results in the PBX being "confused", causing it to  
simply mirror the a= header on subsequent reINVITEs.

I look forward to your help and thoughts!

Best,

Matt Vlasach
Pacific Swell Networks, Inc.
Innovating IP Telephony and Unified Communications Solutions
http://pacificswell.com

email | matt.vlasach at pacificswell.com
tel | 310.598.3017
fax | 310.426.9586
twitter | http://www.twitter.com/mattvlasach
sip | sip:matt.vlasach at pacificswell.com

-----------------------------------------
IMPORTANT NOTICE: This message is intended only for the addressee and  
may contain confidential, privileged information. If you are not the  
intended recipient, you may not use, copy or disclose any information  
contained in the message. If you have received this message in error,  
please notify the sender by reply e-mail and delete the message.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090721/be2c23dd/attachment-0002.html>