Hi all. Considering a case in which the session initiator negotiates a dynamic payload and the receiver answers with the same payload but with a different identifier value, what is the proper function to modify the payload id on the initiator? Thanks in advance. Regards.

2011/10/25 Miguel Ángel <miguelangel@yuilop.com>: > Hi all. > > Considering a case in which the session initiator  negotiates a dynamic payload and the receiver answers with the same payload but with a different identifier value, what is the proper function to modify the payload id on the initiator? Thanks in advance. > That violates SDP negotiation rule, and the best way for caller is to disconnect the call IMO. Benny

Then you mean, for instance, that if an endpoint A offers a payload of type iLBC/16000/1 with an id value of 102 and an endpoint B responds offering the same payload but with an id of 109 this should be considered as a violation? There's no way possible of establishing an id equivalence or translation between both endpoints? As far as i know iLBC has a dynamic payload type and there should exist some kind of mechanism to set a bridge between ids. Isn't right? Thanks. Regards. On Wed, Oct 26, 2011 at 7:50 AM, Benny Prijono <bennylp@teluu.com> wrote: > 2011/10/25 Miguel Ángel <miguelangel@yuilop.com>: > > Hi all. > > > > Considering a case in which the session initiator negotiates a dynamic > payload and the receiver answers with the same payload but with a different > identifier value, what is the proper function to modify the payload id on > the initiator? Thanks in advance. > > > > That violates SDP negotiation rule, and the best way for caller is to > disconnect the call IMO. > > Benny > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

2011/10/26 Miguel Angel Ortuño <miguelangel@yuilop.com>: > Then you mean, for instance, that if an endpoint A offers a payload of type > iLBC/16000/1 with an id value of 102 and an endpoint B responds offering the > same payload but with an id of 109 this should be considered as a violation? No, this is legal, although not recommended by RFC 3264. I thought you meant an offer of ilbc/8000 with PT=102 which is answered with the same PT=102 but different name, e.g. speex/8000. The latter is illegal. > There's no way possible of establishing an id equivalence or translation > between both endpoints? As far as i know iLBC has a dynamic payload type and > there should exist some kind of mechanism to set a bridge between ids. Isn't > right? Thanks. > That's correct. For dynamic PT it's the name that matters, and pjmedia should be able to handle it correctly. Cheers Benny

But for receiving Payload there is no NAME identifier in RTP Packets, and so, you need to tell PJMedia that a certain ID like 105 is ilbc in clockrate 8000. An application cannot decide which ID the other endpoint will use for a certain dynamic payload. Isn't it? Regards. On Thu, Oct 27, 2011 at 6:22 AM, Benny Prijono <bennylp@teluu.com> wrote: > 2011/10/26 Miguel Angel Ortuño <miguelangel@yuilop.com>: > > Then you mean, for instance, that if an endpoint A offers a payload of > type > > iLBC/16000/1 with an id value of 102 and an endpoint B responds offering > the > > same payload but with an id of 109 this should be considered as a > violation? > > No, this is legal, although not recommended by RFC 3264. > > I thought you meant an offer of ilbc/8000 with PT=102 which is > answered with the same PT=102 but different name, e.g. speex/8000. The > latter is illegal. > > > There's no way possible of establishing an id equivalence or translation > > between both endpoints? As far as i know iLBC has a dynamic payload type > and > > there should exist some kind of mechanism to set a bridge between ids. > Isn't > > right? Thanks. > > > > That's correct. For dynamic PT it's the name that matters, and pjmedia > should be able to handle it correctly. > > Cheers > Benny > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Hi Miguel, Honestly, I think I can't understand the question right. If you are about to tell pjmedia stream about the codec used in the incoming RTP (payload type and generic codec info), tell it via pjmedia_stream_info in pjmedia_stream_create(). BR, nanang 2011/10/27 Miguel Angel Ortuño <miguelangel@yuilop.com>: > But for receiving Payload there is no NAME identifier in RTP Packets, and > so, you need to tell PJMedia that a certain ID like 105 is ilbc in clockrate > 8000. An application cannot decide which ID the other endpoint will use for > a certain dynamic payload. Isn't it? > Regards. > > On Thu, Oct 27, 2011 at 6:22 AM, Benny Prijono <bennylp@teluu.com> wrote: >> >> 2011/10/26 Miguel Angel Ortuño <miguelangel@yuilop.com>: >> > Then you mean, for instance, that if an endpoint A offers a payload of >> > type >> > iLBC/16000/1 with an id value of 102 and an endpoint B responds offering >> > the >> > same payload but with an id of 109 this should be considered as a >> > violation? >> >> No, this is legal, although not recommended by RFC 3264. >> >> I thought you meant an offer of ilbc/8000 with PT=102 which is >> answered with the same PT=102 but different name, e.g. speex/8000. The >> latter is illegal. >> >> > There's no way possible of establishing an id equivalence or translation >> > between both endpoints? As far as i know iLBC has a dynamic payload type >> > and >> > there should exist some kind of mechanism to set a bridge between ids. >> > Isn't >> > right? Thanks. >> > >> >> That's correct. For dynamic PT it's the name that matters, and pjmedia >> should be able to handle it correctly. >> >> Cheers >>  Benny >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >

hello, Signaling level need notify low level media engine what codec is using. As you said, A uses pt 102 as iLBC offer, and B answer pt 109. Your application could tell pjmedia stream to send out at pt 109, and receiving at pt 102. As I remember, you can do this way pjmedia_stream_info info; info.tx_pt = 109; info.fmt.pt = 102; regards, Gang 2011/10/27 Miguel Angel Ortuño <miguelangel@yuilop.com>: > But for receiving Payload there is no NAME identifier in RTP Packets, and > so, you need to tell PJMedia that a certain ID like 105 is ilbc in clockrate > 8000. An application cannot decide which ID the other endpoint will use for > a certain dynamic payload. Isn't it? > Regards. > > On Thu, Oct 27, 2011 at 6:22 AM, Benny Prijono <bennylp@teluu.com> wrote: >> >> 2011/10/26 Miguel Angel Ortuño <miguelangel@yuilop.com>: >> > Then you mean, for instance, that if an endpoint A offers a payload of >> > type >> > iLBC/16000/1 with an id value of 102 and an endpoint B responds offering >> > the >> > same payload but with an id of 109 this should be considered as a >> > violation? >> >> No, this is legal, although not recommended by RFC 3264. >> >> I thought you meant an offer of ilbc/8000 with PT=102 which is >> answered with the same PT=102 but different name, e.g. speex/8000. The >> latter is illegal. >> >> > There's no way possible of establishing an id equivalence or translation >> > between both endpoints? As far as i know iLBC has a dynamic payload type >> > and >> > there should exist some kind of mechanism to set a bridge between ids. >> > Isn't >> > right? Thanks. >> > >> >> That's correct. For dynamic PT it's the name that matters, and pjmedia >> should be able to handle it correctly. >> >> Cheers >>  Benny >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >

That was just what i was looking for. thank you so much Gang. Regards. On Wed, Nov 2, 2011 at 7:35 AM, Gang Liu <gangban.lau@gmail.com> wrote: > hello, > Signaling level need notify low level media engine what codec is > using. > As you said, A uses pt 102 as iLBC offer, and B answer pt 109. > Your application could tell pjmedia stream to send out at pt > 109, and receiving at pt 102. > As I remember, you can do this way > pjmedia_stream_info info; > info.tx_pt = 109; > info.fmt.pt = 102; > > regards, > Gang > > 2011/10/27 Miguel Angel Ortuño <miguelangel@yuilop.com>: > > But for receiving Payload there is no NAME identifier in RTP Packets, and > > so, you need to tell PJMedia that a certain ID like 105 is ilbc in > clockrate > > 8000. An application cannot decide which ID the other endpoint will use > for > > a certain dynamic payload. Isn't it? > > Regards. > > > > On Thu, Oct 27, 2011 at 6:22 AM, Benny Prijono <bennylp@teluu.com> > wrote: > >> > >> 2011/10/26 Miguel Angel Ortuño <miguelangel@yuilop.com>: > >> > Then you mean, for instance, that if an endpoint A offers a payload of > >> > type > >> > iLBC/16000/1 with an id value of 102 and an endpoint B responds > offering > >> > the > >> > same payload but with an id of 109 this should be considered as a > >> > violation? > >> > >> No, this is legal, although not recommended by RFC 3264. > >> > >> I thought you meant an offer of ilbc/8000 with PT=102 which is > >> answered with the same PT=102 but different name, e.g. speex/8000. The > >> latter is illegal. > >> > >> > There's no way possible of establishing an id equivalence or > translation > >> > between both endpoints? As far as i know iLBC has a dynamic payload > type > >> > and > >> > there should exist some kind of mechanism to set a bridge between ids. > >> > Isn't > >> > right? Thanks. > >> > > >> > >> That's correct. For dynamic PT it's the name that matters, and pjmedia > >> should be able to handle it correctly. > >> > >> Cheers > >> Benny > >> > >> _______________________________________________ > >> Visit our blog: http://blog.pjsip.org > >> > >> pjsip mailing list > >> pjsip@lists.pjsip.org > >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > > _______________________________________________ > > Visit our blog: http://blog.pjsip.org > > > > pjsip mailing list > > pjsip@lists.pjsip.org > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >