http://blog.gmane.org/gmane.ietf.sipping hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.sipping/16577 <pre> 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&amp;eid=3375 -------------------------------------- Type: Technical Reported by: Henning Christiansen &lt;hc&lt; at &gt;stollmann.de&gt; 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 : Session Initiation Protocol Event Package for Voice Quality Reporting Publication Date : November 2010 Author(s) : A. Pendleton, A. Clark, A. Johnston, H. Sinnreich 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2012-10-09T14:36:46 http://comments.gmane.org/gmane.ietf.sipping/16576 <pre> 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&amp;eid=3295 -------------------------------------- Type: Technical Reported by: David Waiting &lt;dwaiting&lt; at &gt;gmail.com&gt; Section: 3.8. Original Text ------------- F18 ACK Proxy 1 -&gt; Proxy 2 ACK sip:bob&lt; at &gt;biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Max-Forwards: 70 From: Alice &lt;sip:alice&lt; at &gt;atlanta.example.com&gt;;tag=9fxced76sl To: Bob &lt;sip:bob&lt; at &gt;biloxi.example.com&gt;;tag=314159 Call-ID: 2xTb9vxSit55XU7p8&lt; at &gt;atlanta.example.com CSeq: 1 ACK Content-Length: 0 Corrected Text -------------- F18 ACK Proxy 1 -&gt; Proxy 2 ACK sip:bob&lt; at &gt;biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice &lt;sip:alice&lt; at &gt;atlanta.example.com&gt;;tag=9fxced76sl To: Bob &lt;sip:bob&lt; at &gt;biloxi.example.com&gt;;tag=314159 Call-ID: 2xTb9vxSit55XU7p8&lt; at &gt;atlanta.example.com CSeq: 1 ACK Content-Length: 0 Notes ----- Proxy 1 includes an incorrect Via header in the ACK. 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. -------------------------------------- RFC3665 (draft-ietf-sipping-basic-call-flows-02) -------------------------------------- Title : Session Initiation Protocol (SIP) Basic Call Flow Examples Publication Date : December 2003 Author(s) : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers Category : BEST CURRENT PRACTICE 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2012-07-26T16:41:09 http://comments.gmane.org/gmane.ietf.sipping/16556 <pre>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: (1) Why this SDP coding? (2) And why is it optional? Regards, Javi _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Javi Muñoz 2011-11-30T17:59:21 http://comments.gmane.org/gmane.ietf.sipping/16551 <pre>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. charge-param is used as a userinfo parameter in P-Charge-Info." RFC 3261: userinfo = ( user / telephone-subscriber ) [ ":" password ] "&lt; at &gt;" user = 1*( unreserved / escaped / user-unreserved ) RFC 2806: telephone-subscriber = global-phone-number / local-phone-number _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Brett Tate 2011-11-29T18:35:17 http://comments.gmane.org/gmane.ietf.sipping/16550 <pre> 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&amp;eid=2995 -------------------------------------- Type: Technical Reported by: Paul Kyzivat &lt;pkyzivat&lt; at &gt;alum.mit.edu&gt; Section: 5 Original Text ------------- If the notifier includes the &lt;temp-gruu&gt; 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 &lt;temp-gruu&gt; 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 "first-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 "first-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. Notes ----- This replaces '"cseq" attribute' with '"first-cseq" attribute. This is almost a typo, since there is no "cseq" attribute of &lt;temp-gruu&gt;. Following the text as written would yield an invalid xml document. This was reported to me by Ivo Sedlacek: http://www.ietf.org/mail-archive/web/sipcore/current/msg04282.html 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. -------------------------------------- RFC5628 (draft-ietf-sipping-gruu-reg-event-09) -------------------------------------- Title : Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) Publication Date : October 2009 Author(s) : P. Kyzivat 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-10-13T19:44:44 http://comments.gmane.org/gmane.ietf.sipping/16548 <pre>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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Olle E. Johansson 2011-10-10T20:05:37 http://comments.gmane.org/gmane.ietf.sipping/16547 <pre> 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&amp;eid=2987 -------------------------------------- Type: Editorial Reported by: Olle E. Johansson &lt;oej&lt; at &gt;edvina.net&gt; 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 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.) This is an update to RFC 3263, in which the client on a dual stack network queries for either A or AAAA. Notes ----- The RFC actually updates RFC 3263 - locating SIP servers - but doesn't make a clear note about it. 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. -------------------------------------- RFC6157 (draft-ietf-sipping-v6-transition-07) -------------------------------------- Title : IPv6 Transition in the Session Initiation Protocol (SIP) Publication Date : April 2011 Author(s) : G. Camarillo, K. El Malki, V. Gurbani 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-10-10T18:47:52 http://comments.gmane.org/gmane.ietf.sipping/16543 <pre>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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP</pre> Olle E. Johansson 2011-10-03T17:58:15 http://comments.gmane.org/gmane.ietf.sipping/16542 <pre> 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&amp;eid=2980 -------------------------------------- Type: Editorial Reported by: Pablo Varela &lt;pablo.varela&lt; at &gt;telefonica.com&gt; Section: 7.2 Original Text ------------- +---------+ +-----------------------&gt;| Idle |&lt;---------------------+ | +----+----+ | | | | | | INVITE/6.2.1 | | V | | T7/6.2.2 +-------------------------+ REL/6.2.4 | +&lt;----------------+ Trying +------------&gt;+ | +-+--------+------+-------+ | | CANCEL/6.2.3 | | | | | +&lt;----------------+ | E.ACM/ | ACM/ | CON/ANM | | | 6.2.5 |6.2.6 | 6.2.7 | | V | | | | T9/6.2.8 +--------------+ | | | +&lt;----------+ Not alerting | | | | | +-------+------+ | | | | CANCEL/6.2.3 | | | | | |&lt;--------------+ | CPG/ | | | | | 6.2.9 | | | | V V | | | T9/6.2.8 +---------------+ | REL/6.2.4 | +&lt;----------------+ Alerting |-|--------------------&gt;| |&lt;----------------+--+-----+------+ | | | CANCEL/6.2.3 | ^ | | | | CPG/ | | | ANM/ | | | 6.2.9 +--+ | 6.2.7 | | | V V | | +-------------------------+ REL/9.2 | | | Waiting for ACK |------------&gt;| | +-------------+-----------+ | | | | | | ACK/6.2.10 | | V | | BYE/9.1 +-------------------------+ REL/9.2 | +&lt;----------------+ Connected +------------&gt;+ +-------------------------+ 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-09-27T16:42:40 http://comments.gmane.org/gmane.ietf.sipping/16540 <pre> 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&amp;eid=2977 -------------------------------------- Type: Editorial Reported by: Jeff Dyer &lt;jeff.dyer&lt; at &gt;sasktel.com&gt; 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-09-21T17:27:16 http://comments.gmane.org/gmane.ietf.sipping/16538 <pre> 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&amp;eid=2861 -------------------------------------- Type: Technical Reported by: Martin Thomson &lt;martin.thomson&lt; at &gt;commscope.com&gt; Section: 4.4 Original Text ------------- &lt;xs:element name="state"&gt; &lt;xs:complexType&gt; &lt;xs:simpleContent&gt; &lt;xs:extension base="xs:string"&gt; Corrected Text -------------- &lt;xs:element name="state"&gt; &lt;xs:complexType&gt; &lt;xs:simpleContent&gt; &lt;xs:extension base="tns:dialog-state"&gt; ... &lt;xs:simpleType name="dialog-state"&gt; &lt;xs:restriction base="xs:string"&gt; &lt;xs:enumeration value="trying"/&gt; &lt;xs:enumeration value="proceeding"/&gt; &lt;xs:enumeration value="early"/&gt; &lt;xs:enumeration value="confirmed"/&gt; &lt;xs:enumeration value="terminated"/&gt; &lt;/xs:restriction&gt; &lt;/xs:simpleType&gt; 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-07-14T05:23:38 http://comments.gmane.org/gmane.ietf.sipping/16536 <pre>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. </pre> Iñaki Baz Castillo 2011-06-29T13:33:17 http://comments.gmane.org/gmane.ietf.sipping/16533 <pre>draft-ietf-sipping-media-policy-dataset defines a &lt;local-ports&gt; 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 list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Worley, Dale R (Dale 2011-05-23T18:49:27 http://comments.gmane.org/gmane.ietf.sipping/16532 <pre>The media policy dataset defines an XML element &lt;media-intermediaries&gt; 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. - &lt;media-intermediaries&gt; is specified as a child of &lt;session-info&gt;, with various complexities to allow particular intermediaries to be specified for particular streams. But it seems simpler to me to demote &lt;media-intermediaries&gt; to a child of &lt;stream&gt;, 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 _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Worley, Dale R (Dale 2011-05-20T20:25:06 http://comments.gmane.org/gmane.ietf.sipping/16530 <pre>There is a "token" value which is passed from a policy server to a UA. The token value is the content of a &lt;token&gt; 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&lt; at &gt;example.com;token=xyzzy where the value of the "token" parameter is the content of the &lt;token&gt; 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, in which case the entire Unicode set is representable. (Since the semantics of %-escaping is not described anywhere in RFC 3261, either of these is possible.) It seems to me that limiting the characters to U+0020 through U+007E, the ordinary ASCII set, is enough flexibility and avoids all sorts of complications. 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Worley, Dale R (Dale 2011-05-18T16:33:30 http://comments.gmane.org/gmane.ietf.sipping/16527 <pre>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 of that is exactly, since the agent in question may not be the conference focus, and indeed, the session may not be part of a "conference". Thoughts? 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Worley, Dale R (Dale 2011-05-09T19:26:25 http://comments.gmane.org/gmane.ietf.sipping/16519 <pre>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 is not permitted according to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting version numbers, that is insufficient in some cases. The text of 5.2.5 then goes on to say: "The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent." It is not clear what this fails to comply with. I can find nothing in RFC 3264 that stops you sending a new o-line if there is a new session. Yes, it would be non-compliant if only modifying an existing session, but how does the recipient know whether or not it is a new session, and therefore whether or not it is valid? It then goes on to recommend use of Replaces in this situation (i.e. change of session): "If a UA needs to negotiate a 'new' SDP session, it should use the INVITE/Replaces method." But Replaces is not feasible if the UA concerned does not support it (and hence "should", presumably). So there will still be cases where a controlling B2BUA is forced to change the o-line (not just the version) in order to comply with RFC 3264. So there needs to be a mechanism for changing to a 'new' session without relying on Replaces. As far as I can see, there is no standards track RFC that forbids changing the o-line to achieve this, so this new Informational draft should not attempt to make that change, and in particular should not do so without proposing an alternative solution. A simple fix would be to delete the entire bullet beginning "In the o-line, only the version number may change". John _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Elwell, John 2011-04-26T13:37:37 http://comments.gmane.org/gmane.ietf.sipping/16518 <pre>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 by unintended recipients is not authorized and may be unlawful. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP</pre> John-Luc Bakker 2011-03-11T16:23:30 http://comments.gmane.org/gmane.ietf.sipping/16517 <pre>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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> Worley, Dale R (Dale 2011-03-07T22:11:00 http://comments.gmane.org/gmane.ietf.sipping/16513 <pre> 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&amp;eid=2740 -------------------------------------- Type: Technical Reported by: Niels Widger &lt;nwidger&lt; at &gt;iol.unh.edu&gt; Section: 3.8 Original Text ------------- F11 CANCEL Proxy 1 -&gt; Proxy 2 CANCEL sip:alice&lt; at &gt;atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice &lt;sip:alice&lt; at &gt;atlanta.example.com&gt;;tag=9fxced76sl To: Bob &lt;sip:bob&lt; at &gt;biloxi.example.com&gt; Call-ID: 2xTb9vxSit55XU7p8&lt; at &gt;atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 Corrected Text -------------- F11 CANCEL Proxy 1 -&gt; Proxy 2 CANCEL sip:bob&lt; at &gt;biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice &lt;sip:alice&lt; at &gt;atlanta.example.com&gt;;tag=9fxced76sl To: Bob &lt;sip:bob&lt; at &gt;biloxi.example.com&gt; Call-ID: 2xTb9vxSit55XU7p8&lt; at &gt;atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 Notes ----- The Request-URI of message F11 is incorrect according to RFC 3261 Section 9.1: "The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags". 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. -------------------------------------- RFC3665 (draft-ietf-sipping-basic-call-flows-02) -------------------------------------- Title : Session Initiation Protocol (SIP) Basic Call Flow Examples Publication Date : December 2003 Author(s) : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers Category : BEST CURRENT PRACTICE 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&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP </pre> RFC Errata System 2011-03-02T15:04:34 http://comments.gmane.org/gmane.ietf.sipping/16511 <pre>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 compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors&lt; at &gt;cs.columbia.edu for questions on current sip Use sip&lt; at &gt;ietf.org for new developments of core SIP</pre> Internet-Drafts< at >ietf.org 2011-02-02T23:00:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.sipping