headers
RFC Errata System | 9 Oct 2012 16:36
Favicon

[Technical Errata Reported] RFC6035 (3375)


The following errata report has been submitted for RFC6035,
"Session Initiation Protocol Event Package for Voice Quality Reporting".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6035&eid=3375

--------------------------------------
Type: Technical
Reported by: Henning Christiansen <hc <at> stollmann.de>

Section: 4.7.2

Original Text
-------------
CSeq: 4331 PUBLISH

Corrected Text
--------------
CSeq: 4331 NOTIFY

Notes
-----
The message format for the NOTIFY message (F13) seems to contain an invalid CSeq header.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Errata System | 26 Jul 2012 18:41
Favicon

[Technical Errata Reported] RFC3665 (3295)


The following errata report has been submitted for RFC3665,
"Session Initiation Protocol (SIP) Basic Call Flow Examples".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3665&eid=3295

--------------------------------------
Type: Technical
Reported by: David Waiting <dwaiting <at> gmail.com>

Section: 3.8.

Original Text
-------------
F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob <at> biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Max-Forwards: 70
From: Alice <sip:alice <at> atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob <at> biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8 <at> atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Corrected Text
--------------
F18 ACK Proxy 1 -> Proxy 2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Javi Muñoz | 30 Nov 2011 18:59
Picon

ISDN/SIP interworking [ETSI TS 183 036]

Three questions about it:

(a) ISDN/SIP interworking spec [ETSI TS 183 036] proposes that in the 
Q.931/SIP interworking, some EIs Q.931 are codec to SDP and/or inserted 
in the SIP body as a PSTN XML element.
Under what criteria, an Q.931 EI should be?:

(1) Coding to SDP

AND / OR  (this is also important)

(2) Inserted in the SIP body as a PSTN XML element

or

(3) Coding to the URI SIP or and SIP header

or

(4) None (only interpreted by the AGW, without being carried over SIP)

(b) Why does [ETSI TS 183 036]define the mapping of the IE "User to 
user" to the SIP header User-to-User [draft-johnston-sipping-cc-uui-09], 
instead of transporting it over an PSTN XML element? (the IE "User to 
user" must be transported transparently by the nerwork)

(c) Although as optional, [ETSI TS 183 036]defines the coding to SDP of 
the "High Layer Characteristics Identification" field of the IE 
HLC[Q.931].According to Q.931, this EI HLC should be used by the 
end-to-end terminals, not by the LEs (or AGWs in NGN). Then:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brett Tate | 29 Nov 2011 19:35
Favicon

draft-york-sipping-p-charge-info-12: ABNF

Howdy,

Draft-york-sipping-p-charge-info-12 includes the following ABNF without explicitly indicating if
the charge-param is part of user, telephone-subscriber, or both.  I'm not sure how to interpret the
charge-param statement since userinfo has no parameters (although user and telephone-subscriber can
have them).

Is charge-param part of user, telephone-subscriber, or both?  I recommend updating section 7 to remove the ambiguity.

Thanks,
Brett

------

Draft-york-sipping-p-charge-info-12:

"The syntax of the P-Charge-Info header is described as follows:

         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
                 ; name-addr and addr-spec are specified in RFC 3261
             charge-param = npi-param / noa-param / generic-param
             npi-param = ";npi" EQUAL npi-value
                 ; generic-param is specifed in RFC 3261
             npi-value = gen-value
             noa-param = ";noa" EQUAL noa-value
             noa-value = gen-value

   The SIP URI contained in the name-addr/addr-spec is the billing
   indicator that is passed between the parties.
(Continue reading)

Permalink | Reply | 15 comments |
headers
RFC Errata System | 13 Oct 2011 21:44
Favicon

[Technical Errata Reported] RFC5628 (2995)


The following errata report has been submitted for RFC5628,
"Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User
Agent URIs (GRUUs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5628&eid=2995

--------------------------------------
Type: Technical
Reported by: Paul Kyzivat <pkyzivat <at> alum.mit.edu>

Section: 5

Original Text
-------------
   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   It MUST also populate the element with a "cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact.  The value of the "cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned.

Corrected Text
--------------
   If the notifier includes the <temp-gruu> element, it MUST populate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olle E. Johansson | 10 Oct 2011 22:05
Gravatar

SIP certificate management (RFC 6072) and SIP outbound

After reading RFC 6072 I can't help to wonder how this works with an outbound proxy configured in the UA.

For instance, using SIP Outbound we have two proxys that we keep an active flow to. RFC 6072 says that
the UA is required to have a direct connection to the certificate service in order to publish a key and certificate.
This is in order to be able to examine the servers certificate. 

Does this mean that a UA that follows RFC 6072 should override the pre-defined route in the UA and thus
also ignore the SIP outbound mechanism for this transaction? 

/O
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
RFC Errata System | 10 Oct 2011 20:47
Favicon

[Editorial Errata Reported] RFC6157 (2987)


The following errata report has been submitted for RFC6157,
"IPv6 Transition in the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6157&eid=2987

--------------------------------------
Type: Editorial
Reported by: Olle E. Johansson <oej <at> edvina.net>

Section: 3.1

Original Text
-------------
Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RRs), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific network.)

Corrected Text
--------------
Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olle E. Johansson | 3 Oct 2011 19:58
Gravatar

RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups

Hi!

I notice that RFC 6157 updates RFC 3264, but does not mention changes to RFC 3263.

RFC 3263 - locating SIP servers - repeatedly says: "the client performs an A or AAAA record lookup of the domainvname". Note the "or"


RFC 6157, section 3.1 says:

Furthermore, there SHOULD exist both IPv6 and IPv4 DNS entries for outbound proxy servers. This allows the user agent to query DNS and obtain an IP address most appropriate for its use (i.e., an IPv4-only user agent will query DNS for A resource records (RRs), an IPv6-only user agent will query DNS for AAAA RRs, and a dual-stack user agent will query DNS for all RRs and choose a specific network.)



The clause about a dual-stack user agent clearly doesn't follow RFC 3263, since it implies "and" instead of "or". There's no MUST, SHOULD or MAY language applied here, so it seems like this is an oversight - not that RFC 6157 is wrong, but that there should have been a more clear update to RFC 3263.

Nitpicking, but I think it's important to clarify the DNS functionality in regards to dual stacks. In addition, I think there's a need for a BCP to explain how a domain can indicate
preference of address family - ipv4 or ipv6 - by using SRV entries.

/O

 



_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 3 comments |
headers
RFC Errata System | 27 Sep 2011 18:42
Favicon

[Editorial Errata Reported] RFC3398 (2980)


The following errata report has been submitted for RFC3398,
"Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2980

--------------------------------------
Type: Editorial
Reported by: Pablo Varela <pablo.varela <at> telefonica.com>

Section: 7.2

Original Text
-------------
                               +---------+
      +----------------------->|  Idle   |<---------------------+
      |                        +----+----+                      |
      |                             |                           |
      |                             | INVITE/6.2.1              |
      |                             V                           |
      |      T7/6.2.2   +-------------------------+   REL/6.2.4 |
      +<----------------+         Trying          +------------>+
      |                 +-+--------+------+-------+             |
      |    CANCEL/6.2.3 | |        |      |                     |
      +<----------------+ | E.ACM/ | ACM/ | CON/ANM             |
      |                   | 6.2.5  |6.2.6 | 6.2.7               |
      |                   V        |      |                     |
      | T9/6.2.8  +--------------+ |      |                     |
      +<----------+ Not alerting | |      |                     |
      |           +-------+------+ |      |                     |
      |  CANCEL/6.2.3 |   |        |      |                     |
      |<--------------+   | CPG/   |      |                     |
      |                   | 6.2.9  |      |                     |
      |                   V        V      |                     |
      |    T9/6.2.8     +---------------+ |    REL/6.2.4        |
      +<----------------+    Alerting   |-|-------------------->|
      |<----------------+--+-----+------+ |                     |
      |  CANCEL/6.2.3      |  ^  |        |                     |
      |               CPG/ |  |  | ANM/   |                     |
      |              6.2.9 +--+  | 6.2.7  |                     |
      |                          V        V                     |
      |                 +-------------------------+    REL/9.2  |
      |                 |     Waiting for ACK     |------------>|
      |                 +-------------+-----------+             |
      |                               |                         |
      |                               | ACK/6.2.10              |
      |                               V                         |
      |     BYE/9.1     +-------------------------+    REL/9.2  |
      +<----------------+        Connected        +------------>+
                        +-------------------------+

Corrected Text
--------------

Notes
-----
References in figure to 6.2 should point to 7.1.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3398 (draft-ietf-sipping-isup-06)
--------------------------------------
Title               : Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
Publication Date    : December 2002
Author(s)           : G. Camarillo, A. B. Roach, J. Peterson, L. Ong
Category            : PROPOSED STANDARD
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
RFC Errata System | 21 Sep 2011 19:27
Favicon

[Editorial Errata Reported] RFC3398 (2977)


The following errata report has been submitted for RFC3398,
"Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2977

--------------------------------------
Type: Editorial
Reported by: Jeff Dyer <jeff.dyer <at> sasktel.com>

Section: 7.2.4.1

Original Text
-------------
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403
becomes 603)

Corrected Text
--------------
(+) If the cause location is 'user' then the 6xx code could be given rather than the 4xx code (i.e., 403
becomes 603)

Notes
-----
Than is used for comparisons.  Then is used to denote something follows in sequence.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3398 (draft-ietf-sipping-isup-06)
--------------------------------------
Title               : Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
Publication Date    : December 2002
Author(s)           : G. Camarillo, A. B. Roach, J. Peterson, L. Ong
Category            : PROPOSED STANDARD
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
RFC Errata System | 14 Jul 2011 07:23
Favicon

[Technical Errata Reported] RFC4235 (2861)


The following errata report has been submitted for RFC4235,
"An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4235&eid=2861

--------------------------------------
Type: Technical
Reported by: Martin Thomson <martin.thomson <at> commscope.com>

Section: 4.4

Original Text
-------------
  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">

Corrected Text
--------------
  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="tns:dialog-state">
...

  <xs:simpleType name="dialog-state">
    <xs:restriction base="xs:string">
      <xs:enumeration value="trying"/>
      <xs:enumeration value="proceeding"/>
      <xs:enumeration value="early"/>
      <xs:enumeration value="confirmed"/>
      <xs:enumeration value="terminated"/>
    </xs:restriction>
  </xs:simpleType>

Notes
-----
The RFC is rather coy about defining the exact syntax for the state element.  The schema permits any content. 
It's fairly clear from the description in Section 3.7.1 what the permitted values are, but the case of the
values is never explicitly stated.  The text and diagram use title case consistently, and all the examples
use lower case exclusively.

This is bad for interoperability.  In practice, this is probably moot, since most implementations will use
the lowercase form.  Arguably, it would be valid to produce a value of "Early".  An implementation seeking
maximum interoperability would have to use case insensitive comparison to avoid a misinterpretation of
the value.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4235 (draft-ietf-sipping-dialog-package-06)
--------------------------------------
Title               : An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
Publication Date    : November 2005
Author(s)           : J. Rosenberg, H. Schulzrinne, R. Mahy, Ed.
Category            : PROPOSED STANDARD
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |

Gmane