[Home]

Summary:ASTERISK-01755: SIP/SDP Payload Type problems
Reporter:gdalgliesh (gdalgliesh)Labels:
Date Opened:2004-06-03 18:30:31Date Closed:2011-06-07 14:10:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Should a sip device use a dymanic payload type that doesn't match the static definitions in rtp.c the payload type may not align properly btw the endpoints when canreinvite=yes.

Example:
(sip a)-> (asterisk) -> (sip b)
(sip a) calls (sip b) and send rtpmap:103 telephone-events to asterisk when asterisk send a invite packet to (sip b) it will send rtpmap:103 telephone-events to (sip b). Once the call is setup (sip a) send rtp telephone-events to (sip b) as 103 but (sip b) was told by asterisk that they would be 101. In this example the call completes but DMTF doesn't work.

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

In situations were a devices chooses to rtpmap an Audio Codec and picks 97 I suspect it would fail because rtp.c staticly defines that as ILBC.

I could be wrong but I think that if a call is started from a SIP device asterisk needs to follow the rtpmap's that the originating device uses with regard to the RTP payload type 96 thru 127 which are defined as dymanic. Otherwise asterisk willn't always work with canreinvite=yes
Comments:By: Brian West (bkw918) 2004-06-03 21:29:18

Its not a question of what you think... its what does the RFC say?  Can you point out the section that covers this?
By: gdalgliesh (gdalgliesh) 2004-06-04 01:33:58

I am not as fluid with the RFC's as I should be but I think this issue actually falls in several org's domain. ie http://www.iana.org/assignments/rtp-parameters which lays out payload type and the number which are well-defined and dynamic and asterisk handle the dynamic range in a static way from what I can tell. I am not proclaiming, this is just my interpretation.
By: gdalgliesh (gdalgliesh) 2004-06-04 10:22:44

Snippit from RFC 3551  http://www.ietf.org/rfc/rfc3551.txt?number=3551

  This profile reserves payload type numbers in the range 96-127
  exclusively for dynamic assignment.  Applications SHOULD first use
  values in this range for dynamic payload types.  Those applications
  which need to define more than 32 dynamic payload types MAY bind
  codes below 96, in which case it is RECOMMENDED that unassigned
  payload type numbers be used first.  However, the statically assigned
  payload types are default bindings and MAY be dynamically bound to
  new encodings if needed.  Redefining payload types below 96 may cause
  incorrect operation if an attempt is made to join a session without
  obtaining session description information that defines the dynamic
  payload types.

  Dynamic payload types SHOULD NOT be used without a well-defined
  mechanism to indicate the mapping.  Systems that expect to
  interoperate with others operating under this profile SHOULD NOT make
  their own assignments of proprietary encodings to particular, fixed
  payload types.

  This specification establishes the policy that no additional static
  payload types will be assigned beyond the ones defined in this
  document.  Establishing this policy avoids the problem of trying to
  create a set of criteria for accepting static assignments and
  encourages the implementation and deployment of the dynamic payload
  type mechanisms.
By: gdalgliesh (gdalgliesh) 2004-06-04 12:22:55

I am leaving for Dublin and London VON be back 6/14 but in the mean time you can also contact tschroer@golinx.net about questions relating to this issues
Thanks
By: Mark Spencer (markster) 2004-06-04 16:23:10

The short answer to this is that there *is* no solution because once they've been negotiated, we can't change them.  We could in the short term try to carry the RTP map from one side to the other but I *really* don't like that idea and it would break our general ability to make arbitrary channels talk to one another.

This is yet another shortcoming of the SIP architecture.
By: tschroer (tschroer) 2004-06-05 17:49:32

Let me go through one scenario with a Veraz softswitch sending an INVITE to * which is setup with canreinvite=yes in order to release the rtp streams.  The Veraz sends an INVITE with a media format of  103 (for some reason it has selected to use payload type 103) defined by the Veraz as
rtpmap:103 telephone-event/8000
fmtp: 103 0-15

* forwards on an INVITE to the UA with the following media format of 101 defined as
rtpmap: 101 telephone-event/8000
fmtp: 101 0-16

* then sends an OK with SDP back to Veraz with media format of 103 defined as
rtpmap:103 telephone-event/8000
fmtp: 103 0-16

* sends re-INVITEs out to the Veraz with SDP with media format of 103 defined as
rtpmap:103 telephone-event/8000
fmtp: 103 0-16

Since * releases the RTP streams, shouldn't it pass through to the UAs the media format with same dynamic payload type number and definition that it recieves on the INVITE.  I have noticed that when this does not occur, dtmf events don't always get interpreted as they should i.e. dtmf events are disregarded by the gateway or user agent or media server depending on the direction of the call.  

In the reverse example of a call when the * initiates the INVITE to a pstn gateway it uses the media format 101 as defined by
rtpmap: 101 telephone-event/8000
fmtp: 101 0-16

in the Veraz as the pstn gateway example, the Veraz responds back with the same payload type and media format definition in its OK response to the INVITE from *.  
rtpmap: 101 telephone-event/8000
fmtp: 101 0-16

When the RTP stream is released, dtmf events proceed without any anomolies.  I think what we are saying here is that for dynamic payload types, they should be propagated across * based on the originators dynamic payload type, especially in the scenario where * releases the rtp streams.  Right now it only handles dynamic payload type 101.  As an alternative, if I know I will always be recieving payload type 103 with the above definition from my pstn gateway, is there a way to modify the rtp.c file to properly map that particular payload type across the *.  I would think, however, that since there are multiple softswitch vendors out there possibly using different dynamic payload types for dtmf events and differing rtpmap and fmtp descriptions, there should be the flexibility to pass those through * in order that when the rtp streams are released, the endpoints would be using the same payload type for dtmf events.  Thanks

tschroer
By: Mark Spencer (markster) 2004-06-05 18:00:47

In order to be able to support this, we would have to carry the entire RTP payload map from the incoming call to the outgoing call, and even if we did that, it would only work in the case where you were using Dial.  You would still not be able to bridge arbitrary channels together in the "asterisk way".  In other words, to fix this requires tying the outbound channel to the inbound channel in a non-natural way.  It's possible to fix in the case of Dial, but not in general.
By: tschroer (tschroer) 2004-06-06 11:10:22

My take would be that it would be very benfeficial for the specific case of Dial for the sake of ensuring that dtmf events are propagated consistently to the end points regardless of direction of the call.  In this specific case, it would not appear that the modification would be detrimental to anything else even though it only applied to Dial. Just my two cents.

tschroer
By: Olle Johansson (oej) 2004-06-06 14:08:56

Markster, could we disable re-invites if the RTP maps doesn't match? The same way we do disable re-invite if one call leg has NAT=yes. That would not solve this issue, but avoid it totally.
By: tschroer (tschroer) 2004-06-06 21:50:23

The re-INVITE capability is great and it reduces the load on the server.  In addition, it appears that while some of UA's use payload type 101, they may have different fmtp event values, i.e. 0-15 instead in of 0-16 as * uses.  I don't know if this would be considered a mismatch and thus disable re-INVITE.  

As a side note, when RTP events get released there is another benefit.  To demonstrate, I want to outline what happens when * doesn't release the rtp.  In that situation, it seems *, regardless of the duration of the incoming dtmf event, will process the dtmf event with four 101 packets (either after the incoming dtmf event has ended or 2.5 seconds after the start of the event while the event continues if it still is for some reason).  Example of an incoming dtmf event (user presses on pstn presses digit 7):

First packet: event=7, end of event = 0, event duration=0
Second packet: event=7, end of event = 1, event duration=800
Third packet: event=7, end of event = 1, event duration=800
Fourth packet: event=7, end of event = 1, event duration=800

While this seems to be fine for sip aware UA clients and media servers that can interpret the payload directly, it appears it is too short for some gateways that can't or don't play out the dtmf tones long enough for IVR devices on the PSTN side to recognize the sent digits.

When rtp streams are released, dtmf events can propagate between end points with (depending on the devices of course) longer durations.  Holding onto the rtp streams would not be ideal since various implementations use dynamic payload types other than 101 (with fmtp=0-16 I would assume), however, it may help whichever way is decided, to at least extend the duration of the dtmf events when * holds onto the rtp streams to more than an instantaneous event currently being sent.  Forgive me if there is a way to modify this from a parameter that I am not aware of.  I did look before I responded both on the web site and the mailing lists to see if there was something already written about this.  Thanks

tschroer
By: tschroer (tschroer) 2004-06-10 07:08:29

Any more feedback on this????
By: Mark Spencer (markster) 2004-06-11 10:32:02

If I feel inspired to do the rtp numbers thing, i will, but right now it's not really high on my priority.  If anybody else wants to do it, I'll be happy to look at it.
By: Malcolm Davenport (mdavenport) 2004-06-21 13:27:34

Closing.  If someone has some feedback or wants to reopen, let me know.
By: David Woolley (davidw) 2014-09-03 12:20:30.079-0500

This problem was still present in 1.6.1.0, so it was premature to mark it fixed on 2004!  I haven't checked if it has been fixed since 1.6.1.0, but if so someone didn't do a proper search for duplicate bugs.