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.

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

Hadriel Kaplan — 2011-12-05T06:41:03

Yes I knew most of that, and normally I wouldn't have mentioned it - there's nothing wrong with defining a private header for private use in an info RFC, as far as I'm concerned.  And I think RFC 5727 even lets you keep the "P-" portion if it's just documenting known usage or is grandfathered.

But it's the "ATIS is looking at this" part that would make one think perhaps it should NOT be a vendor-specific private-use header.  And that was the spirit in which I was responding to Richard's email, since he mentioned the FCC.  What two consenting adults wants to do is up to them - what the government mandates of all is a bigger deal. ;)

So anyway... to answer your question of how to get it moving faster, it depends on what you want it for - if you just want to document what's been done and not get any input from others, the fastest way is probably to bypass the IETF.  You can just request it be published by the RFC Editor independently, outside of the IETF.  The designated expert reviewer would hopefully pick

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

Dan York — 2011-12-05T04:24:28

Hadriel,

Soooo... a little background... this P-Charge-Info draft began life in February *2008* as a simple attempt to register a SIP header with IANA per RFC 3427 and to document the then *current practice* where the P-Charge-Info header was being used by my employer at the time (Voxeo, who I recently left in September 2011) and then subsequently how it was being used by people using Sonus Networks equipment. (See http://tools.ietf.org/html/draft-york-sipping-p-charge-info-01 ) 

That was it... a simple attempt to document how the P-Charge-Info header had been used for several *years* inside *existing* private networks so that it could be registered with IANA per RFC 3427.

We (Voxeo) wanted to register the usage so that when we indicated to carriers that we wanted to use P-Charge-Info to exchange billing info, we could point them to a published RFC that defined the header.  The exchange would happen on the private connection between our SIP cloud and theirs, but we wanted easy documentation we could point

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

Hadriel Kaplan — 2011-12-04T16:06:33

If the goal is to make it an interoperable header to be used outside of a private network, rather than to just document a private header used by a particular vendor, then I would suggest this discussion be moved to DISPATCH rather than this supposedly-dead SIPPING mailing list.

Further, it would probably require changing the header name (per RFC 5727), and getting consensus on the syntax and semantics.  It would hopefully NOT require a new mini-WG, but could be an individual submission handled by the AD or an independent submission to the RFC Editor.

Lastly, I should note that this draft in its current form contradicts some actual deployed usage of this header - in particular, I can't remember where Sonus encodes the noa/npi fields, but I believe Dialogic encodes them as header-params in a "P-Charge-Info" header, not userinfo-params.  IF two vendors use the same header name but in different ways, then I think it argues even more strongly to use a brand-new header name for this draft. (and don't use "Charg

Re: I-D Action:draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt

Paul Kyzivat — 2011-12-03T18:11:20

I'm commenting on this on the (now obsolete) sipping list because this 
has sipping in its name. This may not be the best place. I suppose an 
alternative is rai.

ISTM that there are three degrees of freedom here for identifying how to 
process these bodies:
- content-disposition
- content-type
- the actual content of the body

Of these, the content-disposition is the most heavy weight in terms of 
mechanism, while the actual content of the body is the least heavy-weight.

So, I wonder why you have chosen to use one content-type, that seems to 
already contain distinct representations for the differing behaviors of 
interest, and yet use distinct content-dispositions. I think you could 
use a single content-disposition and get the same effect.

I guess multiple content-dispositions might make sense if they are 
processed by different entities, so that only the intended entities need 
decode the body. It would also make sense if the same identical body 
representation was processed differently based on the

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

Paul Kyzivat — 2011-12-02T04:48:20

I have lost track, but I think there were prior proposals to incorporate 
the above parameters into the syntax of the tel URI. But AFAICT that was 
never done. (There were issues with it, raised by me among others.) (If 
they were valid in tel, then they would be valid in sip URIs too, since 
the sip uri can contain telephone-subscriber from the tel uri.)

IIUC, here you are trying to introduce these parameters into the user 
part of a sip uri, when used in P-Charge-Info, without extending them 
for other uses of the sip uri or tel uri. Is that right?


Yes, that is what it would have required. Whether that is correct or 
incorrect is an open question. But I guess it is contrary to your intent.


Technically the parameters you want are already *syntactically* valid, 
in two different ways:

They fit the definition of 'parameter' in tel (RFC 3966),

they are consistent within the definition of 'user' in 3261.

So in some sense you don't need to extend the syntax definitions at all. 
But that doesn't say anyt

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

Brett Tate — 2011-12-01T20:01:45

See http://www.ietf.org/mail-archive/web/sipping/current/msg17796.html for more information.

The following is a potential change for RFC 3966's Telephone-Subscriber.  There is no need to add a new expandable parameter; Telephone-Subscriber already has "parameter".  Any new ones should comply with "parameter"; this includes npi-param and noa-param.

   parameter            = ";" pname ["=" pvalue ]
   pname                = 1*( alphanum / "-" )
   pvalue               = 1*paramchar

       npi-param = ";npi" EQUAL npi-value
       npi-value = p-value
       noa-param = ";noa" EQUAL noa-value
       noa-value = p-value

The Telephone-Subscriber's par is expanded to include two new values: npi-param and noa-param.  The following is the resulting ABNF; I don't recall if currently requires IANA registration:

par = parameter / extension / isdn-subaddress / npi-param / noa-param


The following is the recommended change for user; don't do it. :)  However if you need to do it and remain consistent with the "histo

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

Dan York — 2011-12-01T16:00:44

Brett,

On Nov 30, 2011, at 3:41 PM, Brett Tate wrote:


DY> Do you have a suggestion for how I would change this to a more limited parameter within the ABNF?  

DY> Alternatively, what if the ABNF remained as is but the formal syntax included a statement below the ABNF that UTF8-NONASCII is not allowed in the "generic-param" due to limitations in the SIP and tel URIs?    Would that not be sufficient enough for implementors to understand?

Thanks,
Dan

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

Brett Tate — 2011-12-01T14:22:21



If the draft's change was requested by Tolga, it sounds there is some disagreement concerning the intended change or interpretation.


Yes; after reaching agreement upon where charge-param is supposed to be placed, be more explicit concerning how it fits into the existing ABNF of the specific URI (if not changing back to being a header parameter).

The following is snippet from section 7:
---
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.

charge-param is used as a userinfo parameter in P-Charge-Info.
---

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

Dan York — 2011-12-01T14:08:38

Paul,

Many thanks as always for your helpful comments.  The question seems to be that we want to define ABNF that describes an example like this:

P-Charge-Info: <sip:6835555555;npi=001;noa=3< at >10.10.7.21>

The optional npi and noa parameters are parameters that are on the left side of the < at > symbol in a SIP URI.

In looking at the original ABNF we had in there, it does seem to me that it *was* incorrect, as it would have required a URI of something like one of these:

P-Charge-Info: <sip:6835555555< at >10.10.7.21;npi=001;noa=3>
P-Charge-Info: <sip:6835555555< at >10.10.7.21>;npi=001;noa=3

I'm guessing the former... but it's irrelevant - the point is that either of these would be wrong.  We need the ABNF to specify that THIS is the correct notation:

P-Charge-Info: <sip:6835555555;npi=001;noa=3< at >10.10.7.21>

So we really do want to specify somehow that "chargeparam" is part of the "userinfo" section of the SIP URI, and perhaps specifically the "user" section given these definitions:



Any ABNF experts out there able t

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

Haluska, John J — 2011-11-30T23:46:30

Dan,

I don't think that it was me who commented about the ABNF. I'm not an ABNF expert so I'm probably not qualified to make a concrete recommendation here. I do agree that it'd be helpful to explicitly point out that the charge-params belong on the left hand side of the "< at >" sign.


Thanks

John



From: Dan York [mailto:dan-ietf< at >danyork.org]
Sent: Tuesday, November 29, 2011 2:38 PM
To: Brett Tate
Cc: Tolga Asveren; sipping< at >ietf.org; Haluska, John J
Subject: Re: draft-york-sipping-p-charge-info-12: ABNF

Brett, (and replying from a slightly different address so that it will go to the SIPPING list)

Thank you for the feedback and question.  The ABNF in the draft has evolved over the past almost-4 years as various people more literate than I in ABNF have given us feedback and we've updated the draft.

In the ABNF section, "chargeparam" is intended to represent that you could optionally have the "noa", "npi" parameters - or any other generic parameters found in RFC 3261(such as "user=phone")

Originally, the A

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

Brett Tate — 2011-11-30T20:41:03

If charge-param remains within userinfo, generic-param should likely be changed to a more limited extention parameter since UTF8-NONASCII is not allowed within SIP-URI and tel URI because of escaping limitations.  RFC 3986 provides a mechanism for escaping UTF8-NONASCII within newer URI schemes.

RFC 3261:

generic-param  =  token [ EQUAL gen-value ]

gen-value      =  token / host / quoted-string

quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE

qdtext     =  LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII

_______________________________________________
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

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

Asveren, Tolga — 2011-11-30T20:18:45

Brett,

 

The answer for your question is "both", at least that was the intention.

 

Thanks,

Tolga

 

From: Haluska, John J [mailto:jhaluska< at >telcordia.com] 
Sent: Wednesday, November 30, 2011 8:11 AM
To: Dan York; Brett Tate
Cc: Asveren, Tolga; sipping< at >ietf.org
Subject: RE: draft-york-sipping-p-charge-info-12: ABNF

 

Dan,

 

I'll take a look and let you know - I'm out of MIPS at the moment.

 

Thanks for continuing with this even though you've moved on.

 

 

John

 

 

 

From: Dan York [mailto:dan-ietf< at >danyork.org] 
Sent: Tuesday, November 29, 2011 2:38 PM
To: Brett Tate
Cc: Tolga Asveren; sipping< at >ietf.org; Haluska, John J
Subject: Re: draft-york-sipping-p-charge-info-12: ABNF

 

Brett, (and replying from a slightly different address so that it will
go to the SIPPING list)

 

Thank you for the feedback and question.  The ABNF in the draft has
evolved over the past almost-4 years as various people more literate
than I in ABNF have given us feedback and we've updated the draft.

 

In the ABNF s

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

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

Haluska, John J — 2011-11-30T13:10:43

Dan,

I'll take a look and let you know - I'm out of MIPS at the moment.

Thanks for continuing with this even though you've moved on.


John



From: Dan York [mailto:dan-ietf< at >danyork.org]
Sent: Tuesday, November 29, 2011 2:38 PM
To: Brett Tate
Cc: Tolga Asveren; sipping< at >ietf.org; Haluska, John J
Subject: Re: draft-york-sipping-p-charge-info-12: ABNF

Brett, (and replying from a slightly different address so that it will go to the SIPPING list)

Thank you for the feedback and question.  The ABNF in the draft has evolved over the past almost-4 years as various people more literate than I in ABNF have given us feedback and we've updated the draft.

In the ABNF section, "chargeparam" is intended to represent that you could optionally have the "noa", "npi" parameters - or any other generic parameters found in RFC 3261(such as "user=phone")

Originally, the ABNF read:


         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)*

                 (SEMI charge-param)

                 ; name-addr and

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

Paul Kyzivat — 2011-11-30T01:59:53

Including generic-param is a mechanism for making the syntax compatible 
with future enhancements. But allowing it syntactically doesn't specify 
how parameters that match generic-param are to be processed if the are 
present on this header. Typically you would specify in the draft that 
they should be ignored unless the behavior is defined by some other 
specification.


That is something very different. What you have above are *header* 
parameters for the P-Charge-Info header.

It sounds like you are talking about TEL-URI parameters when the tel uri 
has been converted to a sip URI. But if so, then you should be defining 
an extension to the tel-uri syntax. And then you would need to define 
the semantics relative to the tel-uri. (It isn't really kosher to define 
the parameters on the tel-uri but then only define their semantics 
relative to the P-Charge-Info header.)

IMO its wrong to make this change. Rather you should go back to defining 
these explicitly as header params for P-Charge-Info.

Thanks,

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

Dan York — 2011-11-29T19:38:02

Brett, (and replying from a slightly different address so that it will go to the SIPPING list)

Thank you for the feedback and question.  The ABNF in the draft has evolved over the past almost-4 years as various people more literate than I in ABNF have given us feedback and we've updated the draft.

In the ABNF section, "chargeparam" is intended to represent that you could optionally have the "noa", "npi" parameters - or any other generic parameters found in RFC 3261(such as "user=phone")

Originally, the ABNF read:

         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)*
                 (SEMI charge-param)
                 ; name-addr and addr-spec are specified in RFC 3261
             charge-param = npi-param / noa-param / generic-param

I thought that was fairly clear and made sense.  However, I changed the ABNF in rev -10 in October 2010 to more simply:

         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
                 ; name-addr and addr-spec are specified in R

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

Richard Shockey — 2011-11-29T19:01:28

Well well isn't this fascinating.

I was just having a conversation with Dan about this today.

This draft now takes on increasing significance as it solves a nasty little
problem of billing in one way SIP traffic (Skype -  Google Voice etal) that
is vexing the FCC and the carriers as they try to deal with what is
legalistically called "phantom traffic".   It's the preference I'm told is
if no calling party number is available use a CIC or OCN code of sorts. In
two way it could state the preference for billing which is either The CPN or
'Charging Number' 

-----Original Message-----
From: sipping-bounces< at >ietf.org [mailto:sipping-bounces< at >ietf.org] On Behalf
Of Brett Tate
Sent: Tuesday, November 29, 2011 1:35 PM
To: dyork< at >lodestar2.com; tasveren< at >sonusnet.com; sipping< at >ietf.org
Subject: [Sipping] 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 n

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