[SIPForum-discussion] Cisco 7941 on ACME SBC

[Chet Curry]

The out-manipulation is on the Access side.  The 7941 phones are not being nated either as they are behind edgemarc ALG’s.  All other phone types have no issues.
I was able to get a debug from the phone.  It appears to be another buggy issue with the 7941.  The phone is fragmenting the udp packet when it puts the call on hold and is not marking the last fragmented packet as the end packet(regarding fragmentation).  Therefore the router is waiting to forward the packet to the WAN yet never receives the marking in the last fragmented packet.


From: Samuel Fernandez [mailto:samuel_fdz at yahoo.com]
Sent: Friday, January 07, 2011 7:32 PM
To: Chet Curry
Subject: Re: [SIPForum-discussion] Cisco 7941 on ACME SBC

Hi.
Be sure that no out-manipulation is applied in the inside realm in the SBC configuration. Probably you have the NAT_IP manipulation applied as stated in the Broadworks PartnerConfigGuide document.....it should be applied only at the access realm.

Regards.


--- On Mon, 1/3/11, Chet Curry <CCurry at telovations.com<mailto:CCurry at telovations.com>> wrote:

From: Chet Curry <CCurry at telovations.com<mailto:CCurry at telovations.com>>
Subject: Re: [SIPForum-discussion] Cisco 7941 on ACME SBC
To: "Sam" <u2nsam at gmail.com<mailto:u2nsam at gmail.com>>
Cc: "discussion at sipforum.org<mailto:discussion at sipforum.org>" <discussion at sipforum.org<mailto:discussion at sipforum.org>>
Date: Monday, January 3, 2011, 4:30 PM

We did take pcaps and the phone does not send an invite out to put the call on hold.  It is definatly a bug with the phone.  Cisco will not support the phones because they are not connecting to Call Manager.  I am trying to get a debug from the phone yet since we cannot duplicate this in our lab it is very difficult to get these debugs from a customer network.



From: Sam [mailto:u2nsam at gmail.com]
Sent: Friday, December 31, 2010 2:27 AM
To: Chet Curry
Subject: Re: [SIPForum-discussion] Cisco 7941 on ACME SBC



Cisco phones normally send a invite for hold operations try doing the pcap trace over the link between broadvox and phone.

Regards
sam

On Thu, Dec 30, 2010 at 4:22 AM, Chet Curry <CCurry at telovations.com<http://us.mc355.mail.yahoo.com/mc/compose?to=CCurry@telovations.com>> wrote:

I have been running cisco 7941 sip phones on our broadworks network for the last 4 years.  I have seen some bugs with these phones yet have always been able to overcome the issues.  Most of the time it was due to firmware bugs.

We have just migrated from Covergence SBC’s to ACME SBC’s.  We are experiencing an issue were the 7941 will not transfer or hold properly.  Yet when moved back to our convergence sbc’s will work fine.



In all failure cases the phone will not send a new invite out when hold or transfer is selected.  We have tried 8-2-2 and 8-5-2S firmware with no fix.



I have tried to duplicate this in my lab with no failures.  Same firmware on ALG router, cisco phone, same subnet.



1st has anyone tried running cisco 7941 phones in a broadworks network?

2nd has anyone witnessed hold and transfer issues like this on cisco 7941 phones using sip in a broadworks network?



[https://mail.google.com/mail/?ui=2&ik=789451c4e3&view=att&th=12d3b4829f60490a&attid=0.0.1&disp=emb&zw]



_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<http://us.mc355.mail.yahoo.com/mc/compose?to=discussion@sipforum.org>



-----Inline Attachment Follows-----
_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<http://us.mc355.mail.yahoo.com/mc/compose?to=discussion@sipforum.org>


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