Mixing
Duplicate payload type for same codec but different fmtp line is it valid scenario?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am developing a voip application. In one of the scenario, I'm receiving following SDP from network:
`m=audio 10660 RTP/AVP 18 18 8 0 108
a=fmtp:18 annexb=yes
a=fmtp:18 annexb=no
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20`
There are 2 instances of payload type 18 for different fmtp line.
Is it valid scenario as per rfc?
sip codec sdp
edited Jan 3 at 11:03
Botje
2,549915
asked Jan 3 at 9:38
sskssk
7618
add a comment |
I am developing a voip application. In one of the scenario, I'm receiving following SDP from network:
`m=audio 10660 RTP/AVP 18 18 8 0 108
a=fmtp:18 annexb=yes
a=fmtp:18 annexb=no
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20`
There are 2 instances of payload type 18 for different fmtp line.
Is it valid scenario as per rfc?
sip codec sdp
edited Jan 3 at 11:03
Botje
2,549915
asked Jan 3 at 9:38
sskssk
7618
add a comment |
I am developing a voip application. In one of the scenario, I'm receiving following SDP from network:
`m=audio 10660 RTP/AVP 18 18 8 0 108
a=fmtp:18 annexb=yes
a=fmtp:18 annexb=no
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20`
There are 2 instances of payload type 18 for different fmtp line.
Is it valid scenario as per rfc?
sip codec sdp
edited Jan 3 at 11:03
Botje
2,549915
asked Jan 3 at 9:38
sskssk
7618
I am developing a voip application. In one of the scenario, I'm receiving following SDP from network:
`m=audio 10660 RTP/AVP 18 18 8 0 108
a=fmtp:18 annexb=yes
a=fmtp:18 annexb=no
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20`
There are 2 instances of payload type 18 for different fmtp line.
Is it valid scenario as per rfc?
sip codec sdp
sip codec sdp
edited Jan 3 at 11:03
Botje
2,549915
asked Jan 3 at 9:38
sskssk
7618
edited Jan 3 at 11:03
Botje
2,549915
asked Jan 3 at 9:38
sskssk
7618
edited Jan 3 at 11:03
Botje
2,549915
edited Jan 3 at 11:03
Botje
2,549915
edited Jan 3 at 11:03
Botje
2,549915
2,549915
asked Jan 3 at 9:38
sskssk
7618
asked Jan 3 at 9:38
sskssk
7618
asked Jan 3 at 9:38
sskssk
7618
7618
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://tools.ietf.org/html/rfc7261
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019630%2fduplicate-payload-type-for-same-codec-but-different-fmtp-line-is-it-valid-scenar%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://tools.ietf.org/html/rfc7261
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
add a comment |
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://tools.ietf.org/html/rfc7261
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
add a comment |
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://tools.ietf.org/html/rfc7261
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://tools.ietf.org/html/rfc7261
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
edited Mar 5 at 11:46
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
answered Feb 20 at 15:06
ViriatvsViriatvs
48457
48457
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
add a comment |
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
Agreed with last line that it should send with yes, and answerer can reject with No. In your SDP m line should contain only one 18 payload type.
– ssk
Mar 1 at 6:14
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019630%2fduplicate-payload-type-for-same-codec-but-different-fmtp-line-is-it-valid-scenar%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
