Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Michael Ulitskiy
FYI: i've created a feature request to add SIP_CODEC_INBOUND equivalent 
functionality to chan_pjsip:


https://github.com/asterisk/asterisk-feature-requests/issues/9

Let's see where it goes

*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
https://www.aceinnovative.com
On 7/5/23 11:58, Michael Ulitskiy wrote:


Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- 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


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael

On 6/30/23 09:30, Michael Ulitskiy wrote:


Hello,

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.
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 /calling/ channel codec selection from 
dialplan?

I’m working with asterisk 20.3.0.

Thank you,
Michael



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Joshua C. Colp
On Thu, Jul 6, 2023 at 2:22 PM Michael Ulitskiy 
wrote:

> Oh, that's great. It wasn't clear from that page, at least not for me. :-(
>
> Having it clearly stated on the document would save me (and probably
> others) lots of time.
>
The wiki is read-only now and documentation has moved to
https://docs.asterisk.org/, I have updated the page[1] and it will deploy
in a few minutes.

> Thanks for clarifying it. Any idea on the timeframe of implementation?
>
There is no timeframe on such a thing.

[1]
https://docs.asterisk.org/20/Development/Roadmap/Asterisk-18-Projects/Advanced-Codec-Negotiation-ACN/?h=advanced+codec

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Michael Ulitskiy

Oh, that's great. It wasn't clear from that page, at least not for me. :-(

Having it clearly stated on the document would save me (and probably 
others) lots of time.


Thanks for clarifying it. Any idea on the timeframe of implementation?

*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
https://www.aceinnovative.com
On 7/6/23 12:47, Joshua C. Colp wrote:
On Thu, Jul 6, 2023 at 1:43 PM Michael Ulitskiy  
wrote:


Hello,

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.


That functionality is not implemented as of this time.

--
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com  and 
www.asterisk.org 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Joshua C. Colp
On Thu, Jul 6, 2023 at 1:43 PM Michael Ulitskiy 
wrote:

> Hello,
>
> 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.
>
>
That functionality is not implemented as of this time.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Eric Wieling
I suspect most people simply don't care.   Transcoding between ulaw and 
g722 is not CPU intensive and Direct Media doesn't work when NAT is 
involved (which would the case for most people).


On 7/5/23 17:22, Michael Ulitskiy wrote:

Well, I'm trying to migrate to chan_pjsip so that I don't have to do that.

It's so surprising that the issue so seemingly obvious and trivial 
hasn't been addressed yet that I wanted to query the collective wisdom 
of this list to verify my observations.


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-06 Thread Michael Ulitskiy

Hello,

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.


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?


Here's the codec negotiation config:
CLI> pjsip show endpoint A
 ...
 codec_prefs_incoming_answer    : prefer:pending, 
operation:intersect, keep:all, transcode:allow
 codec_prefs_incoming_offer : prefer:pending, 
operation:intersect, keep:all, transcode:allow
 codec_prefs_outgoing_answer    : prefer:pending, 
operation:intersect, keep:all, transcode:allow
 codec_prefs_outgoing_offer : prefer:pending, operation:union, 
keep:all, transcode:allow


All endpoints have the same default config above.

Let's go over simplest scenario: A calls B.
A is configured with g722 and ulaw (allow=!all,g722,ulaw) and B is 
configured with ulaw and alaw (allow=!all,ulaw,alaw)


1. codec_prefs_incoming_offer: A sends INVITE to asterisk with codecs in 
SDP g722,g729,g711u,g711a:

...
m=audio 2266 RTP/AVP 9 18 0 8 101.
a=rtpmap:9 G722/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8

  - according to Advanced Codec Negotiation logic now we have:
    - pending=g722,g729,ulaw,alaw
    - configured=g722,ulaw
    Applying operation "intersect" the resulting resolved topology is 
"g722,ulaw" which is sent to the core


2. codec_prefs_outgoing_offer: Outgoing channel driver receives the 
offer from the core

    - pending=g722,ulaw
    - configured=ulaw,alaw
    Applying operation "union" the resulting resolved topology should 
be "g722,ulaw,alaw" which should be sent
    to B in the outgoing INVITE. What I see is actually sent in 
outgoing INVITE is "ulaw,alaw":

...
m=audio 41506 RTP/AVP 0 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
...
    So this is the 1st point where codec negotiation doesn't work as 
expected


3. codec_prefs_incoming_answer: B replies with "200 OK" which contains 
only ulaw codec:

...
m=audio 2226 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
...
   - pending: ulaw
   - 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)
   Applying operation "intersect" the resulting resolved topology is 
"ulaw" which is sent to the core


4. codec_prefs_outgoing_answer: asterisk replies "200 OK" back to A
   - pending: ulaw (from step 3)
   - configured: g722,ulaw (from step 1)
   Applying operation "intersect" the resulting resolved topology 
should be "ulaw". What I see is actually sent in

   "200 OK" is "g722,ulaw":
...
m=audio 43004 RTP/AVP 9 0 101.
a=rtpmap:9 G722/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
...

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.


Am I missing something. What are your thoughts?

Thanks,

*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
https://www.aceinnovative.com
On 7/5/23 11:58, Michael Ulitskiy wrote:


Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- 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


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael

On 6/30/23 09:30, Michael Ulitskiy wrote:


Hello,

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.
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 /calling/ channel codec selection from 
dialplan?

I’m working with asterisk 20.3.0.

Thank you,
Michael



-- 
_

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-05 Thread Michael Ulitskiy

Well, I'm trying to migrate to chan_pjsip so that I don't have to do that.

It's so surprising that the issue so seemingly obvious and trivial 
hasn't been addressed yet that I wanted to query the collective wisdom 
of this list to verify my observations.


Thanks for github pointer.

Michael

On 7/5/23 16:46, aster...@phreaknet.org wrote:

On 7/5/2023 4:19 PM, Michael Ulitskiy wrote:


Hi Michael,

Thanks for the reply.

I was referring to the scenario you named as 'outbound broken'. I 
didn't get to look at inbound call behavior yet, as I got stuck with 
inability to avoid transcoding on outbound calls.


To be more specific the scenario is as follows:

1. a phone initiates a call offering g722,g711 to asterisk
2. asterisk creates outbound call to carrier offering g711 only 
(carrier only supports g711)

3. carrier accepts the call and outbound call leg is now running on g711
4. asterisk accepts a phone's call with g722 since it's allowed on 
phone's endpoint and was indicated as preferred in phone's INVITE and 
now initial call leg is running on g722, resulting in transcoding


This is very disappointing. Since developers announced their plans to 
drop chan_sip from future asterisk versions



It's already been removed and won't be in any future major releases.
If you still need chan_sip after removal, you can continue adding it 
from out of tree and building it. I maintain a working version of it 
out of tree.


I was under impression that chan_pjsip has reached feature paritiy 
with chan_sip.



It has mostly, but not completely, no.


What is needed is an ability to tell asterisk which codecs are 
allowed to be included in "200 OK" asterisk sends back to the phone. 
I guess we need to submit a feature request. How do we go about it 
these days?


I'm not sure about the particulars of this issue at all, but to answer 
the question at hand, there's a repo for it: 
https://github.com/asterisk/asterisk-feature-requests.-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-05 Thread Michael Ulitskiy

Hi Michael,

Thanks for the reply.

I was referring to the scenario you named as 'outbound broken'. I didn't 
get to look at inbound call behavior yet, as I got stuck with inability 
to avoid transcoding on outbound calls.


To be more specific the scenario is as follows:

1. a phone initiates a call offering g722,g711 to asterisk
2. asterisk creates outbound call to carrier offering g711 only (carrier 
only supports g711)

3. carrier accepts the call and outbound call leg is now running on g711
4. asterisk accepts a phone's call with g722 since it's allowed on 
phone's endpoint and was indicated as preferred in phone's INVITE and 
now initial call leg is running on g722, resulting in transcoding


This is very disappointing. Since developers announced their plans to 
drop chan_sip from future asterisk versions I was under impression that 
chan_pjsip has reached feature paritiy with chan_sip. What is needed is 
an ability to tell asterisk which codecs are allowed to be included in 
"200 OK" asterisk sends back to the phone. I guess we need to submit a 
feature request. How do we go about it these days?


Thanks,
Michael

On 7/5/23 14:59, Michael Maier wrote:

Hello Michael,

you are referring to the following behavior - did I get it correctly?:

outbound broken: asterisk offers g722 / g711 to provider (callee), 
callee answers g711. Asterisk now transcodes between caller and callee 
(g722 <-> g711).


inbound works: call from provider: g711 -> asterisk drops g722 and 
passes g711 to internal callee -> no transcoding.



As far as I know, there is no working solution as of now. I discussed 
this problem years ago already here but unfortunately nothing usable 
happened so far (which I would know off). The priority is not high 
enough. I need a solution, too. I understand that this behavior is a 
nogo if you have a lot of calls because transcoding is expensive.



Thanks
Michael



On 05.07.23 at 17:58 Michael Ulitskiy wrote:

Hello,

Anyone? I have hard time to believe this is not possible with 
chan_pjsip.


Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- 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


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-05 Thread Michael Maier

Hello Michael,

you are referring to the following behavior - did I get it correctly?:

outbound broken: asterisk offers g722 / g711 to provider (callee), 
callee answers g711. Asterisk now transcodes between caller and callee 
(g722 <-> g711).


inbound works: call from provider: g711 -> asterisk drops g722 and 
passes g711 to internal callee -> no transcoding.



As far as I know, there is no working solution as of now. I discussed 
this problem years ago already here but unfortunately nothing usable 
happened so far (which I would know off). The priority is not high 
enough. I need a solution, too. I understand that this behavior is a 
nogo if you have a lot of calls because transcoding is expensive.



Thanks
Michael



On 05.07.23 at 17:58 Michael Ulitskiy wrote:

Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- 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


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

2023-07-05 Thread Michael Ulitskiy

Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- 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


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael

On 6/30/23 09:30, Michael Ulitskiy wrote:


Hello,

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.
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 /calling/ channel codec selection from 
dialplan?

I’m working with asterisk 20.3.0.

Thank you,
Michael


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users