[Home]

Summary:ASTERISK-00669: [request] Add SIP support for RFC3264
Reporter:atacomm (atacomm)Labels:
Date Opened:2003-12-15 17:30:53.000-0600Date Closed:2004-09-25 02:45:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Snom recently updated their phones and broke MoH support with Asterisk.  I'm looking to atleast bring attention to this and start a discussion on whether or not RFC3264 should be supported by Asterisk.  I would assume since SDP is used by SIP, it should be supported and am marking it as a bug since its not.

****** ADDITIONAL INFORMATION ******

Snom recently said they will make a firmware update that will have legacy support, but relying on a legacy mode in all future products would not be a good idea, making Asterisk RFC complaint would probably be a better game plan.
Comments:By: Olle Johansson (oej) 2003-12-18 14:18:11.000-0600

Please explain RFC3264 with a few words. Thank you!
By: Olle Johansson (oej) 2004-01-01 05:05:32.000-0600

Hello, anyone here? :-)
By: stredicke (stredicke) 2004-01-03 09:22:55.000-0600

RFC3264 is at http://ietf.org/rfc/rfc3264.txt?number=3264. snom now uses RFC3264-tyle a= tags only if they have been received from the other side. This way, we always stay backward compatible with RFC2543 implementaions.
By: Olle Johansson (oej) 2004-01-03 10:34:40.000-0600

From the RFC:
--
This document defines a mechanism by which two entities can make use
  of the Session Description Protocol (SDP) to arrive at a common view
  of a multimedia session between them.  In the model, one participant
  offers the other a description of the desired session from their
  perspective, and the other participant answers with the desired
  session from their perspective.  This offer/answer model is most
  useful in unicast sessions where information from both participants
  is needed for the complete view of the session.  The offer/answer
  model is used by protocols like the Session Initiation Protocol
  (SIP).
---
How did this break the MessageOnHold support?
By: stredicke (stredicke) 2004-01-03 10:50:06.000-0600

Well, the authors thought it would be backward compatible but its not. Old user agents detect MOH by looking at the address (which was 0.0.0.0). The new RFC indicates this with a=sendonly (or a=recvonly or a=inactive), the IP address is still valid.

This is important so that for example RTCP information can be send also during a MOH session (the media server might be interested in how good it sounds). The RFC is clearly a step forward; however it does have some problems with old RFC2543-style implementations.
By: lwc (lwc) 2004-03-09 12:50:03.000-0600

I would also like * to support Offer/answer (i.e. RFC3264). Mid-call changed offers (with answers coming back as confirmation) is generally useful.
Focussing on the SDP sendonly/recvonly switches, it would make my life easier (i.e. I only need small hacks for an explicit PTT-driven half-duplex call) - in case you're wondering, I'm playing with connections to a radio TRX. Thus it's not JUST for hold/release :).
By: Olle Johansson (oej) 2004-04-25 02:54:49

Trying to understand this, help me...

To start a new offer/answer during a sip call, would one send a re-invite?
By: lwc (lwc) 2004-04-25 13:02:20

Yes. The unit that wants to change the media sessions sends a (re-) Invite with SDP including the new offer.

Note that the slightly odd thing here is that either the callee or the caller can send an Invite in mid-call.

Also, the original sessions remain current until the Invite/200/ACK exchange has been completed on the (re-) Invite. If the "answerer" doesn't agree with the change, it can reject the (re-) Invite, in which case the original media sessions continue.
By: Mark Spencer (markster) 2004-05-19 18:07:50

We already do this, or am I missing something?  If can-reinvite is "yes" then we send reinvites mid-call.
By: Mark Spencer (markster) 2004-05-25 01:11:05

Believed to be supported in CVS head