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

[Matt Vlasach]

James,

Hope you are doing well!

I just wanted to let you know that this issue was resolved!

The problem was not replicable when using a Sonus switch (thank you  
for being RFC compliant!!) but only occurred when using some specific  
switches in the bandwidth.com cloud.

The issue was fixed with a patch on the inGate SIParator which "took  
care of" the interoperability with the conflicting RFC standards.  I'm  
not sure if the patch has yet been publicly released, but it  
absolutely does the trick.

Once again thank you very much for your insight and assistance with  
this problem!

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
contacts |  http://mattvlasach.tel

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



On Jul 27, 2009, at 4:52 AM, Garron, James wrote:

> Matt, sorry for just getting back to you on this issue.
>
> I agree that there is an issue starting at packet 5614, B2BUA sent  
> an INVITE with a=inactive the only response is to answer with  
> a=inactive (omission of the a-line implies sendrecv).  I would also  
> like to point out that this is not coming from a piece of Sonus  
> equipment.  I am assuming that the 216.82.224.202 address is some  
> kind of proxy or something and not an IP assigned to a Sonus GSX/ 
> NBS.  If you take a look at the o-line of packet 5614 you will see  
> “o: PVG” which I believe is Nortel (CS2000 ?).
>
> I think the best bet is to clarify with Bandwidth what this device  
> is.  I think that once this is addressed the rest of the call flow  
> will fall into place.
>
> Jim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090903/17046017/attachment-0002.html>