gmane.ietf.sipping

[Technical Errata Reported] RFC6035 (3375)

RFC Errata System — 2012-10-09T14:36:46

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
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6035 (draft-ietf-sipping-rtcp-summary-13)
--------------------------------------
Title

[Technical Errata Reported] RFC3665 (3295)

RFC Errata System — 2012-07-26T16:41:09

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

ACK sip:bob< at >biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:alice< at >atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob< at >biloxi.example.

ISDN/SIP interworking [ETSI TS 183 036]

Javi Muñoz — 2011-11-30T17:59:21

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). T

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

Brett Tate — 2011-11-29T18:35:17

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

[Technical Errata Reported] RFC5628 (2995)

RFC Errata System — 2011-10-13T19:44:44

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

SIP certificate management (RFC 6072) and SIP outbound

Olle E. Johansson — 2011-10-10T20:05:37

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

[Editorial Errata Reported] RFC6157 (2987)

RFC Errata System — 2011-10-10T18:47:52

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 m

RFC 6157 actually updates RFC 3263 too - dual stack DNSlookups

Olle E. Johansson — 2011-10-03T17:58:15

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

[Editorial Errata Reported] RFC3398 (2980)

RFC Errata System — 2011-09-27T16:42:40

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          +------------>+
      |                 +-+--------+------+-------+

[Editorial Errata Reported] RFC3398 (2977)

RFC Errata System — 2011-09-21T17:27:16

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, th

[Technical Errata Reported] RFC4235 (2861)

RFC Errata System — 2011-07-14T05:23:38

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>

[draft-ietf-sipping-sip-offeranswer-18] Mention BYE notjust CANCEL

Iñaki Baz Castillo — 2011-06-29T13:33:17

Hi, draft-ietf-sipping-sip-offeranswer-18 in page 6 states:

  In addition, there is a possibility for UAC to receive a 488 response
  for an PRACK request.  In that case, UAC may send again a PRACK
  request without an offer or send a CANCEL request to terminate the
  INVITE transaction.

It should also mention the posibility of sending a BYE which, as per
RFC 3261, is also valid to terminate an early-dialog.

Regards.

media-policy-dataset:

Worley, Dale R (Dale — 2011-05-23T18:49:27

draft-ietf-sipping-media-policy-dataset defines a <local-ports> restriction which a policy server can use to inform a UA what ports it may use for sending/receiving media.  I'd like to make two changes to the current definition:

1) Allow specifications in which the "start" port is greater than the "end" port.  These specifications permit *no* ports to be used, and hence no sessions are in conformance with the policy.  This is not a useful facility for configured policies, but it makes it possible to to construct the logical AND of two policies that make incompatible restrictions on the local port numbers.

2) Change the merging rule from "the local policy controls" to "the intersection of the two specified ranges".  In practice, we expect only the most local policy to restrict what ports can be used.  But it would help to make the merging process more consistent if it was specified as a "logical AND" of all the specified restrictions.

Dale
_______________________________________________
Sipping mailing lis

draft-ietf-sipping-media-policy-dataset:media-intermediaries

Worley, Dale R (Dale — 2011-05-20T20:25:06

The media policy dataset defines an XML element <media-intermediaries> for specifying intermediary
relays that should be used for sending media.  The current draft has some odd features with regard
to this element:

- It can be specified for a session-info but not a session-policy.  Whereas it seems to me that it should
be possible to put a media intermediary specification into a policy.

- <media-intermediaries> is specified as a child of <session-info>, with various complexities to allow
particular intermediaries to be specified for particular streams.  But it seems simpler to me to demote
<media-intermediaries> to a child of <stream>, so that the intermediaries for each stream can be
specified directly.

- The handling of media streams that use multiple ports is not specified clearly.  My impression is that the
only such protocol is RTP, which uses one port for the media (RTP proper) and one port for control information
(RTCP).  Are there any other protocols that use multiple ports?

Dale
________________

session-info value

Worley, Dale R (Dale — 2011-05-18T16:33:30

There is a "token" value which is passed from a policy server to a UA.  The token value is the content of a <token> element in the session-info document, so in general it is a sequence of Unicode characters.  The UA uses it when it makes certain requests by adding a Policy-Info header of the form:

Policy-Info: sip:foo< at >example.com;token=xyzzy

where the value of the "token" parameter is the content of the <token> element in the session-info that it was given.

The question is what characters are permitted in the token value?

The only limitation on the session-info document is that it consist of Unicode characters.  But in order to put it in a parameter value, it must be representable there.  Parameter values use %-escaping, so characters from U+0020 (space) to U+007E (~) can easily be accommodated.  If we use %80 to %FF to represent the characters from U+0080 to U+00FF, we can add the Latin-1 set.  Or we could assume that %-escaping is used to encode *bytes* used in the *UTF-8* representation of characters,

draft-ietf-sipping-media-policy-dataset: Bandwidthlimitations

Worley, Dale R (Dale — 2011-05-09T19:26:25

The media-policy-dataset provides 3 different bandwidth limitations:

max-bw
max-session-bw
max-stream-bw

Comparing the description of these (section 7.3 et seq.) with the description of
the b= line in SDP (RFC 4566 section 5.8) turns up a lot of ambiguity in the
definitions.

It seems to me to be clear that the max-stream-bw number corresponds to the "b=AS:..." line
in an SDP media description -- the bandwidth used by one direction of one media
stream.

The max-session-bw seems to correspond to the "b=AS:..." line in the *session* description,
the total bandwidth used (in one direction) by the whole session.

The max-bw number is less clear.  It seems to be intended to limit the total bandwidth used
by an agent (across all of the sessions it participates in).  As such, it can't be translated to
an SDP attribute.

Conversely, the "b=CT:..." line in an SDP session description seems to be intended to
describe the total bandwidth used by a "conference" (whatever that is).  It's not clear
what the significance

Late comment on draft-ietf-sippping-sip-offeranswer-14

Elwell, John — 2011-04-26T13:37:37

I know last call finished already, but the following has just been brought to my attention:

In section 5.2.5
"Changing the o-line,
      except version number value, during the session is an error case.
      The behavior when receiving such a non-compliant offer/answer SDP
      body is implementation dependent. "
I would content this is NOT an error situation, or at least not an error in the case where a NEW session is being signalled.

Consider a 3PCC situation along the lines described in section 7 of RFC 3725. The controlling B2BUA converts a session between UA A and UA B into a session between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C).

SDP C is likely to be completely different from SDP A. Therefore just a change of version number in the o-line is insufficient and would probably violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only one m-line, the change from 2 m-lines to 1 m-line

draft-bakker-sipping-3gpp-ims-xml-body-handling-06

John-Luc Bakker — 2011-03-11T16:23:30

Dear all,

 

I have received some editorial suggestions in the past and a request to
take into account of addressing the MIME body's use for indicating the
need to re-register with the IMS.

This has been documented and updated in the successive versions of the
draft.

 

Can I ask the list if this draft resolve all the outstanding comments
and if the draft can now move forward.

 

Kind regards,

 

                John-Luc


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission

draft-ietf-sipping-media-policy-dataset: Bandwidthdirectionality

Worley, Dale R (Dale — 2011-03-07T22:11:00

One problem I'm noticing is that the session-policy XML allows specifying the bandwidth in each direction, but SDP does not (as far as I can tell).  How should we resolve this?  Should we define directional bandwidth modifiers in SDP?  Or should we restrict bandwidth in a stream based on the directionality attributes of the stream?

That is, if the sending bandwidth is limited to 10,000 and the receiving bandwidth is limited to 100,000, then an a=sendrecv stream would be have b=10000 but an a=recv stream would have b=100000.

Dale
_______________________________________________
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

[Technical Errata Reported] RFC3665 (2740)

RFC Errata System — 2011-03-02T15:04:34

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=2740

--------------------------------------
Type: Technical
Reported by: Niels Widger <nwidger< at >iol.unh.edu>

Section: 3.8

Original Text
-------------
   F11 CANCEL Proxy 1 -> Proxy 2

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


Corrected Text
--------------
   F11 CANCEL Proxy 1 -> Proxy 2

   CANCEL sip:bob< at >biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Max-Forwards: 70
   From: Alice <sip:alice< at >atlanta.example.c

I-D Action:draft-ietf-sipping-media-policy-dataset-11.txt

2011-02-02T23:00:02

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.


Title           : A User Agent Profile Data Set for Media Policy
Author(s)       : V. Hilt, et al.
Filename        : draft-ietf-sipping-media-policy-dataset-11.txt
Pages           : 41
Date            : 2011-02-02

This specification defines a document format for the media properties
of Session Initiation Protocol (SIP) sessions.  Examples for media
properties are the codecs or media types used in a session.  This
document format is based on XML and can be used to describe the
properties of a specific SIP session or to define policies that are
then applied to SIP sessions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME