Hi Peter,
One followup that may change everything I said about Broadsoft being
wrong: rfc 6044.
Looks like this informational rfc addressed the odd syntax you found in
rfc 5806:
3.2. Diversion Header Syntax
The following text is restating the exact syntax that the production
rules in
The From header can be more useful to the called party than the P-Asserted-Id,
in case the call is originated from an ISDN PBX. In this case, after
application of DSS.1 to SIP interworking, the From header field will typically
contain the actual caller id while the P-Asserted-Id will contain
Thank you for your help in this matter Marianne. I'm a bit confused when
you say:
HCOLON is cleaner than :
COMMA is cleaner than ;
Reminder of the RFC5806 syntax: Diversion = Diversion : 1# (name-addr *(
; diversion_params ))
COMMA should represent , rather than SEMI ; right? I think the
Just remmembering, the dialog shall end after timeout expires (64*T1), not just
after receiving the first BYE. Before it, if BYE arrives, a 200 OK shall be
sent.
:)
Leonardo
De: Nataraju A.B nataraju@gmail.com
Para: M. Ranganathan mra...@gmail.com
Cc:
-Message d'origine-
De : MOHALI Marianne RD-CORE [mailto:marianne.moh...@orange.com]
Envoyé : mercredi 4 avril 2012 15:21
À : Brandon W. Yuille; sip-implementors@lists.cs.columbia.edu
Cc : CHATRAS Bruno RD-CORE-ISS
Objet : RE: [Sip-implementors] TR: BroadSoft's use of Diversion Header
Comments inline...
On Wed, Apr 4, 2012 at 4:57 PM, Leo Leo lafa...@yahoo.com.br wrote:
Just remmembering, the dialog shall end after timeout expires (64*T1), not
just after receiving the first BYE. Before it, if BYE arrives, a 200 OK
shall be sent.
[ABN] Soon after sending 200-BYE, the
If you are operating in an environment where a more specialized
standard/profile holds (such as 3gpp/IMS) then you should look there for
guidance on what to do.
If not, then you will need to make up your own policies.
Thanks,
Paul
On 4/3/12 9:07 PM, Romel Khan wrote:
ITU
Discussion about the compliance of some particular vendor to this is
probably pointless. The draft was never a standard. It existed as a
personal draft for a long time, and finally was moved directly from that
to Historic status, without ever having been a standards track RFC. The
move to
For those unaware of the #rule which is used by RFC 5806...
Draft-levy-sip-diversion was originally based upon RFC 2543 (or
draft-ietf-sip-rfc2543bis-00). The BNF was unintentionally never correctly
updated to comply with RFC 4485 and RFC 3261.
The following are RFC 2543 snippets concerning
On 4/4/12 5:38 AM, bruno.chat...@orange.com wrote:
Sent on behalf of Marianne MOHALI (author of RFC6044) as she is not on this
mailing list.
BC
---
-Message d'origine-
De : MOHALI Marianne RD-CORE [mailto:marianne.moh...@orange.com]
Envoyé : mercredi 4 avril 2012 11:32
À :
Brett,
Thanks for this. I should have checked 2543. (Its been a long time since
I looked at it!!!) It explains a lot.
Thanks,
Paul
On 4/4/12 10:27 AM, Brett Tate wrote:
For those unaware of the #rule which is used by RFC 5806...
Draft-levy-sip-diversion was originally based
On 4/3/12 2:51 PM, James Ryan wrote:
We are currently having an argument with a vendor regarding how the handle
media streams during the REFER process. We are issuing a REFER request to
our peer after placing them on sendonly hold per the standard practice in
RFC3515. In processing the
From: James Ryan [jr...@computer-talk.com]
Our implementation continues to stream silence to the transferee while
the transferee begins to play out the early media data. In this
scenario, the UA interleaves our silence packets with the early media
packets from the third party.
There have
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat
Sent: April-04-12 11:22
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Question about SIP Refer
14 matches
Mail list logo
