locked
RFC3261 compatibility RRS feed

  • Question

  • RFC3261 says - an application or device must support both SIP over UPD and SIP over TCP.

     

    OCS2.7 doesn't support SIP over UDP. Why?

    Saturday, June 30, 2007 8:23 AM

Answers

  • What you need and what you will get may not be the same ;-) From what I understand, OCS does TCP only - no SIP over UDP is included.  As ever, you can ask for it - please consider filing a bug on Connect.

    But for now at least, this is 'by design' and unlikely to change for OCS 2007.

    Sorry if that is not the answer you wanted.
    Monday, July 2, 2007 10:48 AM

All replies

  • My understanding is that it's a security issue. You can't run TLS over UDP, but you can over TCP. Hence no UDP.

    In some cases, strict adherence to RFCs is not the best idea. It feels like this is one of those, hopefully rare, cases.
    Sunday, July 1, 2007 8:07 PM
  • It may be... In such case I wish that I can choose the security level at my own.

     

    RFC fully compatible product is what I need also. But in the case of OCS we have partially-compatible (like D-Link or other worthless appliances) and proprietary-technology-locked product.

     

    Monday, July 2, 2007 6:56 AM
  • What you need and what you will get may not be the same ;-) From what I understand, OCS does TCP only - no SIP over UDP is included.  As ever, you can ask for it - please consider filing a bug on Connect.

    But for now at least, this is 'by design' and unlikely to change for OCS 2007.

    Sorry if that is not the answer you wanted.
    Monday, July 2, 2007 10:48 AM
  • Microsoft isn't alone in its partial implementation of the SIP spec.  While testing OCS 2007 Speech Server with a variety of SIP devices and VOIP gateway terminators, we found that nobody gets it completely right.  We were forced to write our own back-to-back user agent (basically a SIP proxy that bends the rules by modifying SDP and redirecting RTP/RTCP traffic) so that we could interact with endpoints that only speak UDP, and do not implement REFER for transfers.  Each time we tested against a new 3rd party device or service, we found new bugs and inconsistencies that we had to code around to get things working.

     

    We can currently run OCS 2007 confidently with xSipPhone (a soft phone), Grandstream devices (the budget tone phones have worked well for testing), Gafachi and iCall.  We have partial functionality with Bandwidth.com.

     

    Don't expect anyone to change their implementations anytime soon.  If the vast majority of their target audience is being served and they are making money with an incomplete implementation, why change it?  Besides, the SIP spec is complex enough to have many arguable sections, and is hard enough to code to even when you can agree on what you're supposed to be doing.  And check this page out to see the mind boggling list of extensions you have to keep up with: http://jdrosen.net/papers/draft-rosenberg-sip-hitchhikers-guide-00.txt

     

    EZB

    www.loopfx.com

     

    Monday, July 2, 2007 2:22 PM
  • Did you need any additional coding to get the Grandstream devices to work correctly? 
    Thursday, January 10, 2008 1:55 PM
  • Yes.  And we have found that the grandstream devices are unreliable.  I would only recommend them for developer testing, not actual use in an office for regular users.

     

    Thursday, January 10, 2008 2:10 PM
  • Are there any devices that you would recommend?  We are looking for fairly simple devices that we can deploy into classrooms, possibly with speaker phone functionality.

    I appreciate any advice you have to offer.
    Thursday, January 10, 2008 2:20 PM
  • I'm not sure.  You might check the official list of equipment that MSFT has blessed for use with OCS.  I have found that if you are using a speech server application over a speakerphone, it needs to be a high quality device, or the noise level makes it impossible to do good reco.

     

    Thursday, January 10, 2008 2:30 PM