I would take a look at the contact header in the INVITE and both PRACKs.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
Yes, the only things that's different is the branch-id in the Via header.
And the RAck sequence number in the PRACK for the 180. That's 0 1
because there's no RSeq to copy from. I suspect that's the problem,
and the PBX is the problem here, but I'm not sure.
On Thu, Jun 11, 2015 at 4:35 PM, Joel
I'd have to dig up the RFC for PRACKs to comment on that. If the problem is at
that level though, I don't believe that a 481 response is quite right.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original
Is this assumption correct:
If UAC sends 100rel required, then UAC controls PRACK.
If UAS sends 100rel supported, then UAS controls PRACK by sending
100rel required with proper RSeq?
If that's correct I think the PBX is the problem here by sending PRACK
to the 180 ringing.
The 180 ringing only
On 6/11/15 10:28 AM, Roger Wiklund wrote:
Is this assumption correct:
If UAC sends 100rel required, then UAC controls PRACK.
If UAS sends 100rel supported, then UAS controls PRACK by sending
100rel required with proper RSeq?
If that's correct I think the PBX is the problem here by sending
Do the Request-URIs line up?
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
From RFC 3262
…
3. UAS Behaivor
The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header
Thanks guys for confirming this!
I will have a chat with the PBX guys instead =)
/Roger
On Thu, Jun 11, 2015 at 4:46 PM, Brett Tate br...@broadsoft.com wrote:
Hi,
As you noticed (and indicated by the following snippet), the UAS did not
send the 180 reliably. Thus the UAC should not have
INVITE
Contact: Ville Mex
sip:+46840921234@192.168.254.10:5060;transport=TCP;tag=120e096f
PRACK on 183
Contact: Ville Mex
sip:+46840921234@192.168.254.10:5060;transport=TCP;tag=120e096f
PRACK on 180
Contact: Ville Mex
sip:+46840921234@192.168.254.10:5060;transport=TCP;tag=120e096f
They are
Hi,
As you noticed (and indicated by the following snippet), the UAS did not
send the 180 reliably. Thus the UAC should not have sent PRACK; UAS
returning 481 is correct.
RFC 3262 section 3:
The provisional response to be sent reliably is constructed by the
UAS core according to the procedures
Call flow - outgoing call from PBX to ITSP.
-- INVITE with 100rel supported
-- 100 trying
-- 183 session progress with 100rel required
-- PRACK
-- 200 OK on PRACK
-- 180 ringing with 100rel supported
-- PRACK
-- 481 Call leg/transaction does not exist
I've checked the To/From tags and
11 matches
Mail list logo
