Hi Nitin,
RFC4566 is not clear at all about whether statically assigned payload
type numbers may be overridden or not, but RFC3551 provides an
authoritative answer:
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.
It is questionable whether the sender of this particular SDP really
needed to override the default binding as it only offers two formats in
total, but that's not our business, as a recipient, to judge.
So I'd say that a nicely behaving implementation does not *send* such an
SDP itself, unless it really needs to list so many codecs lacking static
payload type definitions in a single offer that it has no option but to
override the static bindings. But when it *receives* an SDP, it must
respect the a=rtpmap format specification for all payload type numbers
for which such a specification is present in the received SDP, and only
use the default bindings for payload type numbers for which no a=rtpmap
specifications have been given.
RFC3264 adds one extra point to that: it permits use of a different
payload type number for the same actual codec in each RTP direction. So
when you receive an SDP offer where G729/8000 is mapped to, say, 0 like
in this case, you must send the G.729 RTP packets with the PT field set
to 0, but you may use the default binding (18) in your own SDP answer,
and if you do so, the recipient of your SDP answer (i.e. the sender of
the SDP offer) must send its G.729 RTP packets to you with the PT field
set to 18.
Pavel
Dne 31.12.2015 v 3:46 NK napsal(a):
Dear All,
I am facing the problem where my far end is sending me the call with
G729 in attribute lines but the payload type for that call in media
description is set to 0 (which is belongs to G711)
When this thing is happening my switch SPS card (in sonus) is coring
the application afaik. Although we already fixed the application by
upgrading this. But the strange part is calls are completing because
as soon as the calls are reaching to switch on the call is accepting
it as G711 not g729.
But i would like to know if this is legal. If anyone have face this
kind of problem earlier? As you can see below.
m=audio 18280 RTP/AVP *0* 101
*a=rtpmap:0 G729/8000*
a=fmtp:0 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
Regards,
Nitin Kapoor
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
