[asterisk-bugs] [JIRA] (ASTERISK-1755) SIP/SDP Payload Type problems

[David Woolley (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222535#comment-222535 ] 

David Woolley commented on ASTERISK-1755:
-----------------------------------------

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.

> SIP/SDP Payload Type problems
> -----------------------------
>
>                 Key: ASTERISK-1755
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-1755
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Core/General
>            Reporter: gdalgliesh
>            Severity: Minor
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2#6252)