PJSIP codec negotiation issue

I found some time to dig a little deeper into the codec negotioation issues I am seeing between Asterisk 13.11.2/PJSIP and a Gigaset S850A GO IP-phone. I ran some simple tests by calling an extension that only plays back ‘hello-world’, with a varying list of codecs and preferred order on both sides and observed the SIP messages being exchanged.

What’s happening basically boils down to this:

  1. Gigaset phone sends INVITE to asterisk and presents it’s codec list and preffered order as configured.
  2. Asterisk challenges the Gigaset phone for authentication by replying with ‘401 Unauthorized’
  3. Gigaset phone replies with an ACK message.
  4. Gigaset phone sends INVITE with authentication information and list of codecs again as in initial INVITE.
  5. Asterisk responds with ‘100 Trying’
  6. Asterisk responds with ‘200 OK’ and sends it’s list of codecs and preferred order.
  7. Gigaset phone replies with ACK.

So far there’s not much unusual here. But the phone internally seems to pick the first codec from asterisk’s list of codecs that it also supports, even if this codec is the phone’s own last preference. Now the interesting part happens when asterisk is trying to send RTP to the phone, encoded in another (but announced as supported by the phone) format than what the phone has picked:

  1. Gigaset phone sends another INVITE to asterisk, containing only the single codec it has picked.
  2. Asterisk responds with ‘200 OK’ and confirms the single codec in the sdp.
  3. Gigaset phone responds with ACK

In case of the playback test-extension the only impact is asterisk choosing the appropriate sound file (I have sound files installed in gsm, alaw and g722 format) and then ending up (needlessly) transcoding the file, cause the phone insisted on using a different format.

Where things totally start to fall apart is when asterisk and the gigaset phone are both configured to use g722, alaw and ulaw in that order of preference, ‘direct_media’ is disabled on all endpoints, and I then initiate a call from the Gigaset phone to another locally connected softphone which I have deliberately configured to only support alaw and ulaw. What happens then is this:

  1. Asterisk thinks it’s ok to send alaw encoded data to the gigaset, as it has announced support for it.
  2. Gigaset phone sends (re)INVITE, saying ‘no, no, i want g722 and nothing else’
  3. Asterisk replies with ‘200 OK’ and confirms exclusive use of g722 in the sdp.
  4. Gigaset phone replies with an ACK.

And from that point on, steps 2,3 and 4 repeat until the connection is torn down, presumably cause asterisk continues sending non-g722 encoded RTP to the gigaset phone. On the gigaset phone you cannot hear the other side, but the other side gets audio from the gigaset.

As for the problem, I guess there are two sides at play here. Personally I don’t consider it ‘expected behaviour’ of the Gigaset S850A GO to insist on using a single format although more are supported, on the other hand asterisk seems to confirm that it is doing as the phone wishes, but then does not seem to (fully) obey to it. But then again I’m no SIP protocol expert, so these are just my $0.05.

If anyone has any ideas/theories about who’s to blame here and how this problem could possibly be resolved, I would be glad to hear about it. If it’s clearly a problem of the Gigaset S850A GO, I willl probably take their support up on it.

I would suggest filing an issue on the issue tracker[1] with this including full logs. Some phones don’t seem to like to accept what they say they can and will either choke or reinvite themselves. We should probably revisit only doing a single codec.

[1] https://issues.asterisk.org/jira

I was just trying to get a full log by enabling it in the ‘logger.conf’ file and then using ‘pjsip set logger on’ and ‘rtp set debug on’, but it looks like some log messages in the output file get truncated in the middle of the sdp by the next log message. Am I doing something wrong here?

Also is there a way to programatically set the codec on a channel with pjsip? I have tried reading/writing SIP_CODEC, but it seems this is only supported for chan_sip?

Can you provide an example of the output?

As for codec control PJSIP has the PJSIP_MEDIA_OFFER[1] dialplan function which controls it. There is also PJSIP_SEND_SESSION_REFRESH[2] which can be used to send a re-invite to control codecs more tightly after call setup.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Function_PJSIP_MEDIA_OFFER
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Function_PJSIP_SEND_SESSION_REFRESH

Here is an excerpt from what i got in the ‘full’ log. It somehow looks as if the response is truncating the output of the request received:

[Sep 24 18:50:05] VERBOSE[100772] res_pjsip_logger.c: <--- Received SIP request (1142 bytes) from UDP:10.6.6.64:5060 --->
INVITE sip:400@rakanishu.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;branch=z9hG4bK114de721392ca8bc3a716841e9b99851;rport
From:  <sip:S850A-1@rakanishu.de>;tag=3447539811
To: <sip:400@rakanishu.de;user=phone>
Call-ID: 3245731910@10_6_6_64
CSeq: 3 INVITE
Contact: <sip:S850A-1@10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", qop=auth, algorithm=md5, uri="sip:400@rakanishu.de;user=phone", nonce="1474735805/918539f74f51906504923393982a74ab", nc=00000001, cnonce="73c9ac81191336bd1dd30660daa89cbc", opaque="1e83daac6289a380", response="7b0e228e78b473423bf0b4b9f56c5242"
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow-Events: message-summary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 241

v=0
o=S850A-1 5008 21 IN IP4 10.6.[Sep 24 18:50:05] VERBOSE[100094] res_pjsip_logger.c: <--- Transmitting SIP response (301 bytes) to UDP:10.6.6.64:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK114de721392ca8bc3a716841e9b99851
Call-ID: 3245731910@10_6_6_64
From: <sip:S850A-1@rakanishu.de>;tag=3447539811
To: <sip:400@rakanishu.de;user=phone>
CSeq: 3 INVITE
Server: ACME
Content-Length:  0

Thanks for the pointer to those dialplan functions. I will take a closer look at them and see whether this could be a way to limit asterisk’s codec list in situations where g.722 is not needed/desireable.

Should there be callerid information in that INVITE?

I presume that is what the phone’s firmware calls ‘display name’, which I left blank, so I guess this is normal.
What’s missing is the rest of the sdp from the phone’s INVITE, where it announces support for G722, PCMA and PCMU. This part gets truncated by the log message following thereafter. I can only attribute this to some problem with the logging, as I can see the complete SIP message exchange on the interface using tcpdump.

AFAIK, this is a known issue with many brands, including Yealink and Grandstream.

It has been discussed here as well on the FreePBX forum (I refer to it so that you know you are not alone):

Apparently, the phone firmware is at fault. However, this does not happen on CHANSIP, only PJSIP. It seems that very few people are actually running PJSIP in production so this issue is not getting much attention from anyone.

Yealink for instance, only now released a preliminary firmware which is supposed to fix it. Not on any stable firmware yet, tough. Grandstream as far as I know has not bothered (typical of GS by the way).

I think it is unlikely PJSIP will be changed in any way (should it?), specially because the affected brands are the “usual suspects”, none of the major brands seem to be affected.

I would go complain with Gigaset if your phone model is still being supported. Or just use CHANSIP which is what everyone with some asterisk experience is recommending for now.

For maximum compatibility I certainly think this is something we should revisit. If it works under chan_sip we should, within reason, try to achieve the same in chan_pjsip. If an issue has not already been created please file one[1].

[1] https://issues.asterisk.org/jira

I have been through that thread in full length and was somehow hoping that Gigaset is not among the manufacturers with crappy firmware. Still this problem obviously has two sides, and the buggy firmware is only one of these, the other being pjsip. And I was wondering what the supposed solution to this problem is going to be? Wait for a number of manufacturers to recognize the problem, fix their firmware and deploy said firmware to probably millions of phones out there? Does anyone think is going to happen anytime soon? I guess a temporary fix in form of some tunable pjsip configuration knob would be the better alternative.

[quote=“mbello, post:8, topic:68119, full:true”]
Apparently, the phone firmware is at fault. However, this does not happen on CHANSIP, only PJSIP. It seems that very few people are actually running PJSIP in production so this issue is not getting much attention from anyone.

Yealink for instance, only now released a preliminary firmware which is supposed to fix it. Not on any stable firmware yet, tough. Grandstream as far as I know has not bothered (typical of GS by the way).

I think it is unlikely PJSIP will be changed in any way (should it?), specially because the affected brands are the “usual suspects”, none of the major brands seem to be affected.[/quote]
IMO PJSIP is partly at fault here too, cause from what I’ve seen, it acknowledges the phone’s wish to exclusively use G722, but continues to send alaw encoded data. That’s not nice, and also what’s causing the phone to send reINVITEs all over again and again.
Also I think there needed to be some more intelligence on PJSIP’s side regarding codec negotiation. For example when PJSIP already knows that the incoming call leg does not support G722, it could remove G722 from the offered codec list when creating the outbound call leg, or at least change the codec order, so that the codec used on the incoming call leg is on top of the codec list offered on the outbound call leg. If the phone follows that preference (as seems to be the case with the S850A GO) this would eliminate needless transcoding.

Guess I will contact their support hotline again this week, but from my previous experience with that, it will probably end up with writing an email that they forward to their development department, which at least gives some hope.

After reading so much about ‘The SIP stack of the future’, I was under the impression it’s the other way round. But if everything else fails, chan_sip is probably a workable alternative.

For reference, here is what happens during a short call from the S850A GO (IP: 10.6.6.64) to my ekiga softphone client (extension 301, IP: 10.6.8.6) through asterisk/pjsip (IP: 10.6.6.1). All endpoints are configured for g722, alaw, ulaw and have direct_media disabled: The ekiga softphone client is deliberately configured to only allow for alaw and ulaw. Same symptoms occur when placing an outbound call through my ITSP to PSTN.

No.   Timestamp  (Dir) Address                  SIP Message                                                         
===== ========== ============================== ===================================
00000 1475913733 * <== 10.6.6.64:5060           INVITE sip:301@rakanishu.de;user=phone SIP/2.0
00001 1475913733 * ==> 10.6.6.64:5060           SIP/2.0 401 Unauthorized
00002 1475913733 * <== 10.6.6.64:5060           ACK sip:301@rakanishu.de;user=phone SIP/2.0
00003 1475913733 * <== 10.6.6.64:5060           INVITE sip:301@rakanishu.de;user=phone SIP/2.0
00004 1475913733 * ==> 10.6.6.64:5060           SIP/2.0 100 Trying
00005 1475913733 * ==> 10.6.8.6:5060            INVITE sip:ekiga@10.6.8.6 SIP/2.0
00006 1475913733 * <== 10.6.8.6:5060            SIP/2.0 100 Trying
00007 1475913733 * <== 10.6.8.6:5060            SIP/2.0 180 Ringing
00008 1475913733 * ==> 10.6.6.64:5060           SIP/2.0 180 Ringing
00009 1475913736 * <== 10.6.8.6:5060            SIP/2.0 200 OK
00010 1475913736 * ==> 10.6.8.6:5060            ACK sip:ekiga@10.6.8.6 SIP/2.0
00011 1475913736 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00012 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00013 1475913737 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00014 1475913737 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00015 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00016 1475913737 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00017 1475913737 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00018 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00019 1475913737 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00020 1475913737 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00021 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00022 1475913737 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00023 1475913737 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00024 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00025 1475913737 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00026 1475913737 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00027 1475913737 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00028 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00029 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00030 1475913738 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00031 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00032 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00033 1475913738 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00034 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00035 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00036 1475913738 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00037 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00038 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00039 1475913738 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00040 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00041 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00042 1475913738 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00043 1475913738 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00044 1475913738 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00045 1475913739 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00046 1475913739 * <== 10.6.6.64:5060           INVITE sip:10.6.6.1:5060 SIP/2.0
00047 1475913739 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00048 1475913739 * <== 10.6.6.64:5060           ACK sip:10.6.6.1:5060 SIP/2.0
00049 1475913739 * <== 10.6.6.64:5060           BYE sip:10.6.6.1:5060 SIP/2.0
00050 1475913739 * ==> 10.6.6.64:5060           SIP/2.0 200 OK
00051 1475913739 * ==> 10.6.8.6:5060            BYE sip:ekiga@10.6.8.6 SIP/2.0
00052 1475913739 * <== 10.6.8.6:5060            SIP/2.0 200 OK

As you can see, from the moment the call is answered there are lots of reINVITEs being sent by the S850A GO.
This is what the initial INVITE from the S850A GO to asterisk looks like:

<--- History Entry 3 Received from 10.6.6.64:5060 at 1475913733 --->
INVITE sip:301@rakanishu.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKade1c634dd173d62f8c3eb3780f35d36
From: <sip:S850A-1@rakanishu.de>;tag=1659051246
To: <sip:301@rakanishu.de;user=phone>
Call-ID: 4125927375@10_6_6_64
CSeq: 3 INVITE
Contact: <sip:S850A-1@10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97"$
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow-Events: message-summary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 240
Content-Type: application/sdp
Content-Length:   240

v=0
o=S850A-1 5012 4 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5012 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

And asterisk’s reply:

<--- History Entry 11 Sent to 10.6.6.64:5060 at 1475913736 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKade1c634dd173d62f8c3eb3780f35d36
Call-ID: 4125927375@10_6_6_64
From: <sip:S850A-1@rakanishu.de>;tag=1659051246
To: <sip:301@rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
CSeq: 3 INVITE
Server: ACME
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Contact: <sip:10.6.6.1:5060>
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:   261

v=0
o=- 5012 6 IN IP4 78.51.220.96
s=ACME
c=IN IP4 10.6.6.1
t=0 0
m=audio 5006 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

Both sides offer the same set and order of codecs, but the S850A GO internally seems to pick the first codec from asterisk’s list of codecs for which it also has support, to be the one codec it expects to be used. In this case this is G722. And as soon and as long as asterisk sends RTP encoded with a different format the S850A GO keeps sending reINVITEs, which asterisk confirms:

<--- History Entry 13 Received from 10.6.6.64:5060 at 1475913737 --->
INVITE sip:10.6.6.1:5060 SIP/2.0                                                                                    Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK370b7b836bef75f99801f70229a94f07
From: <sip:S850A-1@rakanishu.de>;tag=1659051246                                                                     To: <sip:301@rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
Call-ID: 4125927375@10_6_6_64
CSeq: 4 INVITE
Contact: <sip:S850A-1@10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97"$
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 192
Content-Type: application/sdp
Content-Length:   192

v=0
o=S850A-1 5012 5 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5012 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

<--- History Entry 14 Sent to 10.6.6.64:5060 at 1475913737 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK370b7b836bef75f99801f70229a94f07
Call-ID: 4125927375@10_6_6_64
From: <sip:S850A-1@rakanishu.de>;tag=1659051246
To: <sip:301@rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
CSeq: 4 INVITE
Contact: <sip:10.6.6.1:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: ACME
Content-Type: application/sdp
Content-Length:   213

v=0
o=- 5012 7 IN IP4 78.51.220.96
s=ACME
c=IN IP4 10.6.6.1
t=0 0
m=audio 5006 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- History Entry 15 Received from 10.6.6.64:5060 at 1475913737 --->
ACK sip:10.6.6.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKa1f03562b7d4df1ecde9e8251f06d528
From: <sip:S850A-1@rakanishu.de>;tag=1659051246
To: <sip:301@rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
Call-ID: 4125927375@10_6_6_64
CSeq: 4 ACK
Contact: <sip:S850A-1@10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97"$
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Content-Length: 0
Content-Length:  0

And this is what happens on the RTP side of things. Although exclusive use of G722 has been acknowledged, asterisk continues to send alaw encoded data (type 08) to the S850A GO:

[2016-10-08 10:02:18.919] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000176, ts 17428160, len 000160)
[2016-10-08 10:02:18.923] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.939] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000177, ts 17428320, len 000160)
[2016-10-08 10:02:18.943] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.963] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.983] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.003] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.023] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.039] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000178, ts 17428480, len 000160)
[2016-10-08 10:02:19.042] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.059] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000179, ts 17428640, len 000160)
[2016-10-08 10:02:19.063] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.079] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000180, ts 17428800, len 000160)
[2016-10-08 10:02:19.083] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.099] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000181, ts 17428960, len 000160)
[2016-10-08 10:02:19.103] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.119] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000182, ts 17429120, len 000160)
[2016-10-08 10:02:19.123] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.143] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.163] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.183] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.203] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.223] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.226] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000183, ts 17429280, len 000160)
[2016-10-08 10:02:19.243] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.246] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got  RTP packet from    10.6.6.64:5012 (type 09, seq 000184, ts 17429440, len 000160)
[2016-10-08 10:02:19.264] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.291] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.303] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)

I agree that PJSIP should at least have a config knob to make it compatible with the way CHAN_SIP decides what codecs to use.

With regards to the ‘The SIP stack of the future’, unfortunately if you read the changelog for past asterisk 13 releases you will see that PJSIP is still being fixed big time (and recent changes in 13.10 have introduced some very serious bugs, suggesting that it is not only being fixed, but also refactored/reworked which is always a source of new bugs).

I wonder why asterisk do not explicitly say PJSIP is beta software.

Totally agree. ¨PJSIP is not ready to production.

Regards

Can you provide the information on which things you are referring to as being fixed big time or broken?

We have quite a few users using PJSIP who are happy, and we are ourselves are exclusively using PJSIP in Switchvox.

As well we have over 375 tests for PJSIP to verify things and when we do uncover stuff we’re adding more, helping to make it more stable and to ensure it continues to work properly in the future.

1 Like

@jcolp, I am referring to the long list of PJSIP isses fixed on the last releases of Asterisk 13 (reading the change logs) and also referring to the existing deadlock issue with PJSIP which makes it quite unstable and unsuitable for use in production at the moment (at least for me). The fix for that deadlock is supposed to be shipped with 13.12.

By the way, on FreePBX list again a long thread was opened and it turned out that many new users were being burned by this PJSIP codec behavior. I have myself seen too many people waste time and run away from PJSIP just because of this issue. It is clear to me that a solution should be provided.

1 Like

Understood, that specific codec issue only just recently got an issue created and it is in queue. It has not been brought up previously. As for 13.12.0 it should have quite a few fixed issues as it’s been awhile since we’ve done a release.

That pretty much nails it. After unsuccessfully trying to set PJSIP_MEDIA_OFFER from the dialplan, I’m somewhat out of ideas for now. For the time being I’ve configured the phone to allow for PCMA only, but that’s hardly a solution either, and I’m still waiting for someone with a ‘deeper understanding’ from Gigaset support to call me back. I was thinking about switching to chan_sip, but after having read through the example configuration file again, it seems like I will inevitably be running into the same set of problems with chan_sip, as I was facing with PJSIP, so I don’t feel like going down that road.

Some progress in this matter. I’ve finally talked to two persons from Gigaset support who understood the nature of the problem and will now forward it to their development department. Additionally I was aked to provide SIP traces that can help identify the problem.