<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,<br>
<br>
After I have re-read the "PJSIP Advanced Codec negotiation"
document, it occurred to me that the desired behavior should
actually happen automatically, just due to the codec negotiation
logic, but it looks like asterisk doesn't actually follow the
described logic which is likely a bug.<br>
<br>
Can you please follow with me through a simple sip call and see if
I'm missing something or asterisk actually doesn't do what it's
supposed to do?<br>
<br>
Here's the codec negotiation config:<br>
CLI> pjsip show endpoint A<br>
...<br>
codec_prefs_incoming_answer : prefer:pending,
operation:intersect, keep:all, transcode:allow<br>
codec_prefs_incoming_offer : prefer:pending,
operation:intersect, keep:all, transcode:allow<br>
codec_prefs_outgoing_answer : prefer:pending,
operation:intersect, keep:all, transcode:allow<br>
codec_prefs_outgoing_offer : prefer:pending,
operation:union, keep:all, transcode:allow<br>
<br>
All endpoints have the same default config above.<br>
<br>
Let's go over simplest scenario: A calls B. <br>
A is configured with g722 and ulaw (allow=!all,g722,ulaw) and B is
configured with ulaw and alaw (allow=!all,ulaw,alaw)<br>
<br>
1. codec_prefs_incoming_offer: A sends INVITE to asterisk with
codecs in SDP g722,g729,g711u,g711a:<br>
...<br>
m=audio 2266 RTP/AVP 9 18 0 8 101.<br>
a=rtpmap:9 G722/8000.<br>
a=rtpmap:18 G729/8000.<br>
a=fmtp:18 annexb=no.<br>
a=rtpmap:0 PCMU/8000.<br>
a=rtpmap:8 PCMA/8000.<br>
a=rtpmap:101 telephone-event/8<br>
<br>
- according to Advanced Codec Negotiation logic now we have:<br>
- pending=g722,g729,ulaw,alaw<br>
- configured=g722,ulaw<br>
Applying operation "intersect" the resulting resolved topology
is "g722,ulaw" which is sent to the core<br>
<br>
2. codec_prefs_outgoing_offer: Outgoing channel driver receives
the offer from the core<br>
- pending=g722,ulaw<br>
- configured=ulaw,alaw<br>
Applying operation "union" the resulting resolved topology
should be "g722,ulaw,alaw" which should be sent<br>
to B in the outgoing INVITE. What I see is actually sent in
outgoing INVITE is "ulaw,alaw":<br>
...<br>
m=audio 41506 RTP/AVP 0 8 101.<br>
a=rtpmap:0 PCMU/8000.<br>
a=rtpmap:8 PCMA/8000.<br>
a=rtpmap:101 telephone-event/8000.<br>
...<br>
So this is the 1st point where codec negotiation doesn't work
as expected<br>
<br>
3. codec_prefs_incoming_answer: B replies with "200 OK" which
contains only ulaw codec:<br>
...<br>
m=audio 2226 RTP/AVP 0 101.<br>
a=rtpmap:0 PCMU/8000.<br>
a=rtpmap:101 telephone-event/8000.<br>
...<br>
- pending: ulaw<br>
- configured: ulaw,alaw (it's result of step 2. it should be
g722,ulaw,alaw but actually is ulaw,alaw as described in step 2)<br>
Applying operation "intersect" the resulting resolved topology
is "ulaw" which is sent to the core<br>
<br>
4. codec_prefs_outgoing_answer: asterisk replies "200 OK" back to
A<br>
- pending: ulaw (from step 3)<br>
- configured: g722,ulaw (from step 1)<br>
Applying operation "intersect" the resulting resolved topology
should be "ulaw". What I see is actually sent in<br>
"200 OK" is "g722,ulaw":<br>
...<br>
m=audio 43004 RTP/AVP 9 0 101.<br>
a=rtpmap:9 G722/8000.<br>
a=rtpmap:0 PCMU/8000.<br>
a=rtpmap:101 telephone-event/8000.<br>
...<br>
<br>
If I understand it correctly the result of codec negotiation in
the above scenario should be ulaw in both call legs, thus avoiding
transcoding, but actual asterisk behavior differs.</p>
<p>Am I missing something. What are your thoughts?</p>
<p>Thanks,<br>
</p>
<div class="moz-signature"><span style="font-size:10pt"><b>Michael
Ulitskiy</b><br>
Ace Innovative Networks, Inc.<br>
Main/SMS: 212-868-2366<br>
Direct/SMS: 212-812-1203<br>
<a href="https://www.aceinnovative.com"
class="moz-txt-link-freetext">https://www.aceinnovative.com</a><br>
</span></div>
<div class="moz-cite-prefix">On 7/5/23 11:58, Michael Ulitskiy
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b5ccdb99-e2ef-3071-1bae-14861c503e88@acedsl.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hello,</p>
<p>Anyone? I have hard time to believe this is not possible with
chan_pjsip.</p>
<p>Anyway, may I ask how people handle the following scenario
which I imagine should be quite common:</p>
- I have internal extensions talk to each other using g722. so
their codec setting (with chan_sip now) is "allow=g722,ulaw"<br>
- I have carriers trunks that handle ulaw only (allow=ulaw)<br>
- calls between internal extensions naturally happen over g722 as
its their preferred codec<br>
- for external calls I now set SIP_CODEC_INBOUND=ulaw to influence
codec selection on calling channel and the calls set up using ulaw
end-to-end
<p>Can somebody please advise how to achieve the same with
chan_pjsip?</p>
<p>Thanks,</p>
<p>Michael<br>
</p>
<div class="moz-signature"><span style="font-size:10pt"> </span></div>
<div class="moz-cite-prefix">On 6/30/23 09:30, Michael Ulitskiy
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:167fd103-8f55-4403-ad5a-9eddd35359e8@acedsl.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<p>Hello,<br>
</p>
<p>I finally got to look at chan_sip to chan_pjsip migration
again. This time I’m having problems with influencing codec
selection on originating (calling) channel. It looks like
PJSIP_MEDIA_OFFER only works on outbound (called) channel and
has no affect on calling channel. My experiments and function
documentation (which says “Media and codec offerings to be set
on an outbound SIP channel prior to dialing.”) seem to confirm
it.<br>
So PJSIP_MEDIA_OFFER is supposed to be (and it works)
chan_pjsip’s equivalent of ${SIP_CODEC_OUTBOUND}, but what is
chan_pjsip’s equivalent of ${SIP_CODEC_INBOUND}? Or, in other
words, what are we supposed to do to influence <em>calling</em>
channel codec selection from dialplan?<br>
I’m working with asterisk 20.3.0.<br>
</p>
<p>Thank you,<br>
Michael</p>
<div class="moz-signature"><br>
<span style="font-size:10pt"></span></div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>