Re: Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

Iñaki,

I don't understand what the point is of sending, or forwarding, this 
CANCEL. There is nothing left to cancel. The only possibility would be 
if the INVITE had been forked somewhere along the path. But if it had, 
the forking proxy would have seen the 200 and sent a CANCEL on its own. 
So there is no reason for the UAC to send a CANCEL in this case.

	Thanks,
	Paul

Iñaki Baz Castillo wrote:
> Hi, RFC 3261 clearly states that an INVITE transaction is terminated
> upon receipt of a 200. So let's imagine a proxy between alice and bob:
> 
> - alice sends INVITE to the proxy.
> - The proxy relays it to bob.
> - bob replies 200.
> - The proxy relays the 200 to alice and terminates the INVITE transaction.
> - For some reason alice sends now a CANCEL.
> - The proxy doesn't match a transaction for this CANCEL so it would
> relay it statelessly as section 16.10 states:
> 
>    If a response context is not found, the element does not have any
>    knowledge of the request to apply the CANCEL to.  It MUST statelessly
>    forward the CANCEL request (it may have statelessly forwarded the
>    associated request previously).
> 
> 
> This makes sense because such "response context" doesn't exist after

Re: Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

2010/5/2 Paul Kyzivat <pkyzivat <at> cisco.com>:
> Iñaki,
>
> I don't understand what the point is of sending, or forwarding, this CANCEL.
> There is nothing left to cancel. The only possibility would be if the INVITE
> had been forked somewhere along the path. But if it had, the forking proxy
> would have seen the 200 and sent a CANCEL on its own. So there is no reason
> for the UAC to send a CANCEL in this case.

Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
could occur (race conditions, 200 reply lost in the network...). So
the proxy must know how to behave when a CANCEL arrives for an INVITE
transaction in "Accepted" state, something that doesn't make sense in
the original 3261 specification as the proxy terminates the INVITE
transaction when the 200 arrives (immediately).

I think innfix draft should clarify it: what should do a proxy when a
CANCEL arrives and matches an INVITE transaction in "Accepted" state?

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Re: Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

Iñaki Baz Castillo wrote:
> 2010/5/2 Paul Kyzivat <pkyzivat <at> cisco.com>:
>> Iñaki,
>>
>> I don't understand what the point is of sending, or forwarding, this CANCEL.
>> There is nothing left to cancel. The only possibility would be if the INVITE
>> had been forked somewhere along the path. But if it had, the forking proxy
>> would have seen the 200 and sent a CANCEL on its own. So there is no reason
>> for the UAC to send a CANCEL in this case.
> 
> Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
> could occur (race conditions, 200 reply lost in the network...). So
> the proxy must know how to behave when a CANCEL arrives for an INVITE
> transaction in "Accepted" state, something that doesn't make sense in
> the original 3261 specification as the proxy terminates the INVITE
> transaction when the 200 arrives (immediately).
> 
> I think innfix draft should clarify it: what should do a proxy when a
> CANCEL arrives and matches an INVITE transaction in "Accepted" state?

Ok, if you are only concerned with being clear about this, and not that 
it is something of general utility. It seems it doesn't really matter 
whether the CANCEL is propagated by the proxy or not, since it is 
destined to be a no-op. It would be more efficient to block its 
propagation, but given the rarity of the situation I don't think it 
really matters.

	Thanks,
	Paul

Re: Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

2010/5/2 Paul Kyzivat <pkyzivat <at> cisco.com>:
>> Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
>> could occur (race conditions, 200 reply lost in the network...). So
>> the proxy must know how to behave when a CANCEL arrives for an INVITE
>> transaction in "Accepted" state, something that doesn't make sense in
>> the original 3261 specification as the proxy terminates the INVITE
>> transaction when the 200 arrives (immediately).
>>
>> I think innfix draft should clarify it: what should do a proxy when a
>> CANCEL arrives and matches an INVITE transaction in "Accepted" state?
>
> Ok, if you are only concerned with being clear about this, and not that it
> is something of general utility. It seems it doesn't really matter whether
> the CANCEL is propagated by the proxy or not, since it is destined to be a
> no-op. It would be more efficient to block its propagation, but given the
> rarity of the situation I don't think it really matters.

The problem I've seen is in an existing SIP proxy which mantains the
INVITE transaction in memory after 200 arrives. It does it even before
invfix draft exists (this is, the proxy already fixes the bug in RFC
3261). However when such proxy receives a CANCEL for an INVITE
transaction for which the proxy has already sent a 200, it replies 200
to the CANCEL. This doesn't make sense (as it has canceled nothing
because the transaction was already confirmed by the UAS).

So I would like to know the correct behavior of the proxy in this case
in order to improve/report it. However I would like such behavior to
be clarified in draft invfix as with the original 3261 specification
there was no place to this ambiguity (a CANCEL would never match an
INVITE transaction as the proxy terminated it upon receipt of a 200

I-D Action:draft-ietf-sip-ipv6-abnf-fix-05.txt

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

	Title           : Essential correction for IPv6 ABNF and URI comparison in RFC3261
	Author(s)       : V. Gurbani, et al.
	Filename        : draft-ietf-sip-ipv6-abnf-fix-05.txt
	Pages           : 8
	Date            : 2010-05-03

This document corrects the Augmented Backus-Naur Form (ABNF)
production rule associated with generating IPv6 literals in RFC3261.
It also clarifies the rule for Uniform Resource Identifier (URI)
comparison when the URIs contain textual representation of IP
addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-05.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.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

New version of draft-ietf-sip-ipv6-abnf-fix

Folks: A new version (-05) of draft-ietf-sip-ipv6-abnf-fix
is ready to be sent to the IESG.

The summary of changes is as follows:

1) Minor typo and grammatical fixes.
2) Added a new S4 in -05 to serve as a reference point to
    draft-ietf-6man-text-addr-representation-07, a draft on
    how to generate a canonical IPv6 textual representation.

    draft-...-addr-representation is now referenced using a
    normative SHOULD and has been made a normative reference.
    This should not delay the release of draft-...-ipv6-abnf-fix
    since draft-...-addr-representation is now in RFC Ed Queue.

The relevant links are:
New version (-05):
http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-05.txt

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-ipv6-abnf-fix-05

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg <at> {alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

I-D Action:draft-ietf-sip-domain-certs-07.txt

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

	Title           : Domain Certificates in the Session Initiation Protocol (SIP)
	Author(s)       : V. Gurbani, et al.
	Filename        : draft-ietf-sip-domain-certs-07.txt
	Pages           : 17
	Date            : 2010-05-05

This document describes how to construct and interpret certain
information in a X.509 PKIX-compliant certificate for use in a
Session Initiation Protocol (SIP) over Transport Layer Security (TLS)
connection.  More specifically, this document describes how to encode
and extract the identity of a SIP domain in a certificate and how to
use that identity for SIP domain authentication.  As such, this
document is relevant both to implementors of SIP and to issuers of
certificates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-07.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.

sip-domain-certs-07 submitted

All: After 4 years, 14 revisions, 2 area directors and outliving
the SIP WG, sip-domain-certs can be sent to RFC nirvana (otherwise
known as the RFC Editor's Queue.)

I have just submitted version -07 that includes one minor change
resulting from an OPS area review.  The draft has been through IESG
evaluation and is now ready to be sent to the RFC editor's queue.

The -07 version is at:
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-07.txt,
and the diffs are at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-domain-certs-07

Thank you,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg <at> {alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Protocol Action: 'Domain Certificates in the Session Initiation Protocol (SIP)' to Proposed Standard

The IESG has approved the following document:

- 'Domain Certificates in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-domain-certs-07.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-07.txt

Technical summary.

This document describes how to construct and interpret certain
information in a X.509 PKIX-compliant certificate for use in a Session
Initiation Protocol (SIP) over Transport Layer Security (TLS) connection.
More specifically, this document describes how to encode and extract the
identity of a SIP domain in a certificate and how to use that identity for
SIP domain authentication.  As such, this document is relevant both to
implementors of SIP and to issuers of certificates.
Working group summary.

There is consensus in the working group to publish this document. 

Document Quality

Implementors have found this document helpful. It has been discussed in
SIP and PKIX WG. 

[Technical Errata Reported] RFC3428 (2261)

The following errata report has been submitted for RFC3428,
"Session Initiation Protocol (SIP) Extension for Instant Messaging".

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

--------------------------------------
Type: Technical
Reported by: Brett Tate <brett <at> broadsoft.com>

Section: 10

Original Text
-------------
MESSAGE sip:user2 <at> domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
Max-Forwards: 69
From: sip:user1 <at> domain.com;tag=49394
To: sip:user2 <at> domain.com
Call-ID: asd88asd77a <at> 1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18

Watson, come here.