[cisco-voip] SIP Load and Re-Invite

Sat Apr 23 16:05:51 EDT 2011

All kidding aside SIP is moving towards supporting renegotiation better.  I
sit on most of the SIP IETF lists (if you want some people that can go into
weeds on details – watch those lists) and a great number of conversations
lately revolve around this very subject.

While many systems today loosely support renegotiation you can expect your
mileage to vary until the standards reach a better level of detail and
specificity.  As I’ve been coming to learn lately (especially when it comes
to VoIP and Video) – SIP related RFC’s can have quite a wide array of
meanings even when the creator thinks they are being specific.  I’ve seen
whole conversations on the IETF lists that pertain to proverbially dotting
I’s and crossing T’s because of how inexact some of the RFC’s are.

Expect the situation to improve – but in the meantime pick and test your
vendors carefully.

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Friday, April 15, 2011 7:44 PM
To: Mike Lydick; Dennis Heim
Cc: cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] SIP Load and Re-Invite

I think H323 v7 is due out soon to replace SIP J Replaces ASN.1 with Creole.

Mwen palé on ti kal Kreyol

From: Mike Lydick [mailto:mike.lydick at gmail.com] 
Sent: Friday, April 15, 2011 2:19 PM
To: Dennis Heim
Cc: Jason Aarons (AM); cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] SIP Load and Re-Invite

The field test was Verizon introducing CMG tones a few seconds after the
call was established to a Cisco 7931 phone. The Cube logged: "Failed to
negotiate media: 488".

In our example we have CUBE and CM8.5 in place but the call fails to switch
the Media stream codec after a CMG tone is sent.

We are not  using 'Require MTP', but tried the Dynamic MTP option in the SIP
Profile on UCM but the call still fails after the codec change is sent and
this option appears to alway enable the MTP.

Tac is questioning if this supported and what scenario would require this.
The only one that I can think is an Analog port that has a multifunction
Fax, or a line that is being shared for voice an modem. We are going to
retest on a FXS port on Monday.

I see an option for modifying SDP for mid call codec changes, we did not
enable at the time of testing. Do not have any documentation that states
that this is required?

This SIP stuff is a fad anyways I am going to tell the customer to move back
to H323...

Best Regards,

Mike Lydick

On Fri, Apr 15, 2011 at 1:35 PM, Dennis Heim <Dennis.Heim at cdw.com> wrote:

Do you have a cube in place?

Dennis Heim
Network Voice Engineer
CDW  Advanced Technology Services
11711 N. Meridian Street, Suite 225
Carmel, IN  46032

317.569.4255 Single Number Reach
317.569.4201 Fax 
 <mailto:dennis.heim at cdw.com> dennis.heim at cdw.com
cdw.com/content/solutions/unified-communications/
<http://www.cdw.com/content/solutions/unified-communications/> 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Aarons (AM)
Sent: Friday, April 15, 2011 12:51 PM
To: cisco-voip (cisco-voip at puck.nether.net)
Subject: [cisco-voip] SIP Load and Re-Invite

Is it normal for sip providers (say Verizon) to want to change codec
mid-call or require your equipment can do it?  I understand CallManager 8.5
/ SIP 7945 can’t do this.  Is it a CallManager limitation or a phone load
limitation or both for reinvite to change codec mid-call?

I’m a fan of codecs that dynamically change bandwidth (Silk, iLBC) but not
G.722 to G711 to G.729 if the call degrades, but I guess with SIP you could
possible do this based on the spec for re-invite. Or switch from G.729 to
G.711 for faxes, etc.

  _____  

Disclaimer: This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the designated
addressee(s) named above only. If you are not the intended addressee, you
are hereby notified that you have received this communication in error and
that any use or reproduction of this email or its contents is strictly
prohibited and may be unlawful. If you have received this communication in
error, please notify us immediately by replying to this message and deleting
it from your computer. Thank you. 

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110423/d4d83976/attachment.html>