8 Jun
2018
8 Jun
'18
3:02 p.m.
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
8 Jun
8 Jun
4 p.m.
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
4:08 p.m.
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
6:06 p.m.
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
11:26 p.m.
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
9 Jun
9 Jun
12:12 a.m.
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
4:58 a.m.
Hello again Pan and Thank You for looking at this!! Here is the pcap for the call that is
not showing video on either side of the call. As I mentioned I do get two way Audio, the
call stays connected, but just no Video. The Video ports look to be correct. Video
packets appear to go out (at least packets are going out over the Video ports). The screen
on the Caller (A WebRTC Client) and the Called (A Provider Phone) are both blank. The
WebRTC client is Registered in Kamailio
Note: when I sanitized the file using tcprewrite an extra RTP packet appeared (Unknown RTP
packet version 0), this was not here in the original.
I use Kamailio 5.2.0 and Asterisk 15.3
Thank you again!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 5:12 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
1:20 p.m.
I have to admit that I don't have much experience with video calls, but as far as I
can tell VP8 is negotiated with WebRTC client. Nothing is negotiated with softphone.
WebRTC client offers:
Media Description, name and address (m): video 55185 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
102 123 127 122 125 107 108 109 124
Asterisk offers to softphone:
Media Description, name and address (m): video 15112 RTP/AVP 99
Why is it advertising only 99?
Softphone answers with:
Media Description, name and address (m): video 36140 RTP/AVP 115 113 34 31
No match with offer, video is not negotiated for this call leg.
Asterisk answers WebRTC with:
Media Description, name and address (m): video 10328 UDP/TLS/RTP/SAVPF 96 100
96 is chosen for this call leg.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Wilkins, Steve
Sent: lørdag 9. juni 2018 03:59
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello again Pan and Thank You for looking at this!! Here is the pcap for the call that is
not showing video on either side of the call. As I mentioned I do get two way Audio, the
call stays connected, but just no Video. The Video ports look to be correct. Video
packets appear to go out (at least packets are going out over the Video ports). The screen
on the Caller (A WebRTC Client) and the Called (A Provider Phone) are both blank. The
WebRTC client is Registered in Kamailio
Note: when I sanitized the file using tcprewrite an extra RTP packet appeared (Unknown RTP
packet version 0), this was not here in the original.
I use Kamailio 5.2.0 and Asterisk 15.3
Thank you again!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 5:12 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
2:56 p.m.
Thank you Pan. I am going to continue to look at this this weekend. I'm not sure why
Asterisk is only offering 99.
I'll take a look at it with fresh eyes today, although I've been on this for two
weeks now.
It is strange that the call works if I by-pass Kamailio; Kamailio is just relaying (I
think?).
Thank you SO much again Pan,
Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Saturday, June 9, 2018 6:20 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
I have to admit that I don't have much experience with video calls, but as far as I
can tell VP8 is negotiated with WebRTC client. Nothing is negotiated with softphone.
WebRTC client offers:
Media Description, name and address (m): video 55185 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
102 123 127 122 125 107 108 109 124
Asterisk offers to softphone:
Media Description, name and address (m): video 15112 RTP/AVP 99
Why is it advertising only 99?
Softphone answers with:
Media Description, name and address (m): video 36140 RTP/AVP 115 113 34 31
No match with offer, video is not negotiated for this call leg.
Asterisk answers WebRTC with:
Media Description, name and address (m): video 10328 UDP/TLS/RTP/SAVPF 96 100
96 is chosen for this call leg.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: lørdag 9. juni 2018 03:59
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello again Pan and Thank You for looking at this!! Here is the pcap for the call that is
not showing video on either side of the call. As I mentioned I do get two way Audio, the
call stays connected, but just no Video. The Video ports look to be correct. Video
packets appear to go out (at least packets are going out over the Video ports). The screen
on the Caller (A WebRTC Client) and the Called (A Provider Phone) are both blank. The
WebRTC client is Registered in Kamailio
Note: when I sanitized the file using tcprewrite an extra RTP packet appeared (Unknown RTP
packet version 0), this was not here in the original.
I use Kamailio 5.2.0 and Asterisk 15.3
Thank you again!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 5:12 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
3:49 p.m.
Hi Pan,
I once again compared the call through the Proxy and without the Proxy; the Offers appear
to be exactly the same, so I think the negotiation must be working?, even though one is 99
and one is 115 does not appear to matter as the call just through Asterisk works. I just
can't figure out why the Proxy has any effect. Is there a chance that the '200
OK' is not being relayed to the softphone when going through the proxy? I asked this
because I see the '200 OK' coming into Kamailio, but I'm not so sure it is
getting relayed. Is this correct thinking?
These are the same with or without Proxy =>
Asterisk (INVITE)
Media Description, name and address (m): video 15112 RTP/AVP 99
Media Attribute (a): rtpmap:99 H264/90000
Media Attribute (a): fmtp:99
level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
Softphone (200 OK)
Media Description, name and address (m): video 36140 RTP/AVP 115 113 34 31
Media Attribute (a): rtpmap:115 H264/90000
Media Attribute (a): fmtp:115 profile-level-id=42000b;packetization-mode=1;max-mbps=23760
Thanks!!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Saturday, June 9, 2018 6:20 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
I have to admit that I don't have much experience with video calls, but as far as I
can tell VP8 is negotiated with WebRTC client. Nothing is negotiated with softphone.
WebRTC client offers:
Media Description, name and address (m): video 55185 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
102 123 127 122 125 107 108 109 124
Asterisk offers to softphone:
Media Description, name and address (m): video 15112 RTP/AVP 99
Why is it advertising only 99?
Softphone answers with:
Media Description, name and address (m): video 36140 RTP/AVP 115 113 34 31
No match with offer, video is not negotiated for this call leg.
Asterisk answers WebRTC with:
Media Description, name and address (m): video 10328 UDP/TLS/RTP/SAVPF 96 100
96 is chosen for this call leg.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: lørdag 9. juni 2018 03:59
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello again Pan and Thank You for looking at this!! Here is the pcap for the call that is
not showing video on either side of the call. As I mentioned I do get two way Audio, the
call stays connected, but just no Video. The Video ports look to be correct. Video
packets appear to go out (at least packets are going out over the Video ports). The screen
on the Caller (A WebRTC Client) and the Called (A Provider Phone) are both blank. The
WebRTC client is Registered in Kamailio
Note: when I sanitized the file using tcprewrite an extra RTP packet appeared (Unknown RTP
packet version 0), this was not here in the original.
I use Kamailio 5.2.0 and Asterisk 15.3
Thank you again!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 5:12 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
3:57 p.m.
Pan,
I did verify the '200 OK' is making it to the softphone because I see the
'ACK' to it. So that isn't the issue.
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Saturday, June 9, 2018 6:20 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
I have to admit that I don't have much experience with video calls, but as far as I
can tell VP8 is negotiated with WebRTC client. Nothing is negotiated with softphone.
WebRTC client offers:
Media Description, name and address (m): video 55185 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
102 123 127 122 125 107 108 109 124
Asterisk offers to softphone:
Media Description, name and address (m): video 15112 RTP/AVP 99
Why is it advertising only 99?
Softphone answers with:
Media Description, name and address (m): video 36140 RTP/AVP 115 113 34 31
No match with offer, video is not negotiated for this call leg.
Asterisk answers WebRTC with:
Media Description, name and address (m): video 10328 UDP/TLS/RTP/SAVPF 96 100
96 is chosen for this call leg.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: lørdag 9. juni 2018 03:59
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello again Pan and Thank You for looking at this!! Here is the pcap for the call that is
not showing video on either side of the call. As I mentioned I do get two way Audio, the
call stays connected, but just no Video. The Video ports look to be correct. Video
packets appear to go out (at least packets are going out over the Video ports). The screen
on the Caller (A WebRTC Client) and the Called (A Provider Phone) are both blank. The
WebRTC client is Registered in Kamailio
Note: when I sanitized the file using tcprewrite an extra RTP packet appeared (Unknown RTP
packet version 0), this was not here in the original.
I use Kamailio 5.2.0 and Asterisk 15.3
Thank you again!,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 5:12 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Dear Steve.
Asterisk is a B2BUA. It doesn't just route SIP messages like Kamailio does. Most of
the time, it answers the call, sets up a new call to the other party and then bridges the
two calls, making two separate call IDs (depending on your configuration).
Additional comments in blue inline below:
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk probably sends 183/200 back to callee, finalizing this codec negotiation.
VP8 is chosen for this call leg.
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* yes
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
* No. I assume that the callee didn't accept VP8 because it doesn't support
it. It instead chose the highest priority codec it supported among the codecs that
Asterisk advertised.
* Asterisk accepts this codec because it supports it. There is no test checking
which codec was chosen on the caller side and there is no renegotiation. Hence, video is
broken forever.
Again, if you could show us the details (like attaching the SDPs that I asked for
previously), then we wouldn't have to guess what's happening. We could tell you
for sure.
Med vennlig hilsen
Pan B. Christensen
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 22:27
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi Pan,
If the Registered caller is a WebRTC client (Caller) whose preferred coded is VP8, calls a
Phone (Called) whose preferred Video is H264, I should see
* INVITE from Caller to Kamailio (this is where the Caller is Registered) offering
VP8
* Kamailio will relay the INVITE to Asterisk
* Asterisk will INVITE Called
* Called sends '200 OK' to Asterisk requesting H264
* Asterisk Sends '200 OK' back to Kamailio to be relayed to Caller accepting
VP8
Is this correct? Then I think one of the issues is that there is no fmtp line in the VP8.
The only codecs that have fmtp lines is for the H264 codecs.
Thank you,
-Steve
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
12:21 a.m.
I forgot to mention that if I by-pass Kamailio, the call works. I would like to send the
pcap, but it has IP-Address that can't be shared.
Thank you!
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
12:34 a.m.
Sorry Pan, but one other thing I noticed. When Asterisk send the 200 OK, Kamailio does
see it, but I don't see where it is relaying it to the WebRTC client that made the
call. However, it must, otherwise the call would disconnect in 30 seconds and also, I do
have two-way Audio.
Thanks again for you input on this. It's seems a bit confusing as to where an issue
lies.
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 11:06 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
That's not strange. The soft phone probably doesn't advertise support for VP8, so
it's not chosen.
Calling from WebRTC, I assume that VP8 is the preferred codec and Asterisk accepts it.
Asterisk then finds out that the soft phone doesn't support VP8 and negotiates a
different codec with that client.
If you show us the SDPs of INVITE and 183/200 on both sides of Asterisk (in the order they
are sent), we can tell you exactly what happens. Failing that, I'd say that the
culprit is Asterisk, which probably negotiates two different codecs without the ability to
transcode.
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 15:09
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Yes, for example a WebRTC Client (VP8) calls a Soft-Phone (H264). What is strange is that
if it is the other way around and the Soft-Phone calls the WebRTC client, it works.
Thank you
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Pan Christensen
Sent: Friday, June 8, 2018 9:00 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hello Steve.
Does Asterisk negotiate different codecs with each client? If so, it needs to transcode,
which I believe is currently not supported for video. What does Asterisk send back to
device A?
With kind regards
Pan B. Christensen
Developer
Phonect AS
From: sr-users
<sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>>
On Behalf Of Wilkins, Steve
Sent: fredag 8. juni 2018 14:03
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Peculiar Kamailio Asterisk behavior on outbound calls
Hi All,
Issue: when a Call is made through Kamailio and Asterisk. Asterisk uses incorrect Video
RTP Payload Type when sending Video packets.
I have a situation where I make a call from Device A to Device B and Device A is
Registered in Kamailio. When Device A Calls Device B, Kamailio sends an 'INVITE'
to Asterisk, Asterisk then 'INVITES' Device B. I get two-way Audio, the call
stays connected, however, when Video packets are sent to Device B, the RTP Payload Type is
incorrect. The port is correct, but just not the Payload Type.
Here is where I think Kamailio is involved. In the first Invite from Kamailio to Asterisk,
one of the offered Video codecs is '100 H264'; interesting enough, Device B wants
to use '115 H264' and when Asterisk sends out Video packets, it is using
'100' instead of '115', and of course I have no Video. I don't know
if this is just a coincidence but it sure seems like that is where the issue may lie.
Has anyone ever seen this behavior? The Asterisk teams does not think it's an
Asterisk issue.
Thank you,
-Steve
2361
days inactive
2362
days old
12 comments
2 participants
participants (2)
-
Pan Christensen -
Wilkins, Steve