Thanks Gents,
I'm sorry my terminology has caused confusion. However The responses received
have clarified things for me.
Seems the vendor is not in violation of the standard, just not implementing the
solution well. I'll try another tack to get the way they handle the codec
negotiation
de 2011 20:45
Assunto: Re: [Sip-implementors] Re-Invite codec renegotiation.
Sorry Dale,
I thought it was clear.
The PBX (Mitel) that sends the re-invite without SDP, that then accepts the
offered G.729 codec from the ISP, despite not being able support the codec is
the device I believe
-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Leo Leo
Sent: Friday, July 01, 2011 8:49 AM
To: Johnson, Michael A; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Re-Invite codec renegotiation.
Hi,
Just adding some information, RFC3261 allows sending re-invite
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
The PBX (Mitel) that sends the re-invite without SDP, that then
accepts the offered G.729 codec from the ISP, despite not being able
support the codec is the device I believe is as fault. The
manufacturer however disagrees.
On 07/01/2011 02:24 PM, Worley, Dale R (Dale) wrote:
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
The PBX (Mitel) that sends the re-invite without SDP, that then
accepts the offered G.729 codec from the ISP, despite not being able
support the codec is the device I believe is
On 7/1/2011 5:12 PM, Kevin P. Fleming wrote:
On 07/01/2011 02:24 PM, Worley, Dale R (Dale) wrote:
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
The PBX (Mitel) that sends the re-invite without SDP, that then
accepts the offered G.729 codec from the ISP, despite not being
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
Thanks Dale,
The problem I have is that I cannot find anything definitive in RFC3261 that
explicitly states that the system cannot accept the 200OK despite the fact it
has no capability to
@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Re-Invite codec renegotiation.
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
Thanks Dale,
The problem I have is that I cannot find anything definitive in RFC3261
that explicitly states that the system
Sorry Dale,
I thought it was clear.
The PBX (Mitel) that sends the re-invite without SDP, that then accepts the
offered G.729 codec from the ISP, despite not being able support the codec is
the device I believe is as fault. The manufacturer however disagrees.
As per the comment
Although it
I apologise if I have been unclear in the posting.
A point to mention is that this vendor (Mitel) do not support 'hold' in the
correct sense. They use 'consultation-hold' or the first stage of a transfer as
their hold mechanism. While I disagree with this approach, it is not the issue
I am
Hold invite:
[re-INVITE without SDP]
Hold OK with SDP (incoming from ISP) This is sent 3 times.
SIP/2.0 200 OK
[...]
v=0
o=BroadWorks 13783 2 IN IP4 192.168.175.132
s=-
c=IN IP4 10.2.1.108
t=0 0
m=audio 16460 RTP/AVP 18 101
a=rtpmap:18 G729a/8000
a=fmtp:18 annexb=no
Thanks Dale,
The problem I have is that I cannot find anything definitive in RFC3261 that
explicitly states that the system cannot accept the 200OK despite the fact it
has no capability to handle the codec. The best I see in the RFC is 'SHOULD'.
To get the code corrected, I really need a clearly
I have an issue with a vendor where a call placed from a phone that negotiates
G.729 (ISP supports both G.729 G.711)
200 OK with SDP:
t=0 0
m=audio 9000 RTP/AVP 8 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
When I place the call on-hold,
: [Sip-implementors] Re-Invite codec renegotiation.
I have an issue with a vendor where a call placed from a phone that
negotiates G.729 (ISP supports both G.729 G.711)
200 OK with SDP:
t=0 0
m=audio 9000 RTP/AVP 8 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
You're not being very clear about this -- you talk of a phone, a PBX, and an
ISP. You say I send without making clear which of these devices is sending
and which is receiving.
What is the offer? What is the answer? In what way do you believe that the
answer is incorrect?
Dale
15 matches
Mail list logo
