[Sip-implementors] Dialog matching

Post by isshed
My phone has got an INVITE with the following field
From: <sip:abc at example-1.com>1234
To: <sip:Steffen at example2.com>
then it sends 200-INVITE as follows
From: <sip:abc at example-1.com>123444
To: <sip:Steffen at example2.com>432144

The 200 response is malformed if it was supposed to correlate to the
mentioned INVITE. The From tag changed.

Post by isshed
Then my phone is receiving ACK as
From: <sip:jkallasdf at example-3.com>123444
To: <sip:Steffen at example2.com>432144

The ACK is malformed if it supposed to correspond the mentioned 200
response since the From URI changed.

Post by isshed
should my phone accept it and stop responding 200-INVITE?

--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

isshed

2014-04-23 10:23:35 UTC

Hey Brett,

Tags are all same i made a typo only the URI in the ACK is changed.

The 200 response is malformed if it was supposed to correlate to the
mentioned INVITE. The From tag changed.

Post by isshed
Then my phone is receiving ACK as
From: <sip:jkallasdf at example-3.com>123444
To: <sip:Steffen at example2.com>432144

The ACK is malformed if it supposed to correspond the mentioned 200
response since the From URI changed.

Post by isshed
should my phone accept it and stop responding 200-INVITE?

Maybe. :) Malformed messages can basically be handled however the device
prefers. However, RFC 3261 (section 17.1.3 and section 17.2.3)
transaction matching rules concerning magic cookies is way too lenient in
my opinion since it allows matching ridiculously malformed messages. For
instance, it doesn't even require that the Call-ID header be correct.
The device that sent the malformed 200 response should be fixed to quit
sending the wrong From tag.
The device that sent the malformed ACK should be fixed to quit sending the
wrong From URI. RFC 3261 and RFC 4916 do not provide a mechanism use ACK
to update the From's URI.
--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

Brett Tate

2014-04-23 10:56:56 UTC

Post by isshed
Tags are all same i made a typo only the URI in
the ACK is changed.

isshed

2014-04-23 11:40:02 UTC

Thanks Brett!!

Post by isshed
Tags are all same i made a typo only the URI in
the ACK is changed.

Hi,
My response concerning malformed messages still applies. The ACK is
malformed (from a RFC 3261 and RFC 4916 perspective); thus the device can
basically handle it however it wants. However since it is an ACK, a 400
response obviously cannot be returned.
"The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID."
--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

isshed

2014-04-24 05:30:05 UTC

Hi Brett,

RFC 3261 section 12.2.1.1 also says:

Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.

Does that mean while matching dialog, URIs of FROM and TO tag should
not be considered?

Thanks.

Post by isshed
Thanks Brett!!

Post by isshed
Tags are all same i made a typo only the URI in
the ACK is changed.

Brett Tate

2014-04-24 10:16:39 UTC

Hi,

The basic answer is yes. However if the URI's changed without using the RFC
4916 mechanism, the request (or response) would be malformed. RFC 3261
prepared things for RFC 4916 (and maybe another alternative within the
future). It also ensured that the URI's would not be needed within headers
such as Replaces (RFC 3891).

Excluding the usage of RFC 4916, a lenient device would need to decide how
to behave if accepting the malformed request/response. More specifically,
it would need to decide if better to ignore the To/From URI modification or
accept the modification. For instance if the sender changed the remote
user's identity to something incorrect, should the remote user start using
the incorrect identity within the From of subsequent requests that it sends?
Similarly if the sender changed its identity, should the remote user start
using the changed identity within the To of subsequent requests that it
sends; and if so, should it only allow certain requests to cause the change
(similar to RFC 4916)?

-----Original Message-----
From: isshed [mailto:isshed.sip at gmail.com]
Sent: Thursday, April 24, 2014 1:30 AM
To: Brett Tate
Cc: sip-implementors
Subject: Re: [Sip-implementors] Dialog matching
Hi Brett,
Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.
Does that mean while matching dialog, URIs of FROM and TO tag should
not be considered?
Thanks.

Post by isshed
Thanks Brett!!
On Wed, Apr 23, 2014 at 4:26 PM, Brett Tate <brett at broadsoft.com>

Post by isshed
Tags are all same i made a typo only the URI in
the ACK is changed.

Hi,
My response concerning malformed messages still applies. The ACK is
malformed (from a RFC 3261 and RFC 4916 perspective); thus the

device can

Post by Brett Tate
basically handle it however it wants. However since it is an ACK, a

400

Post by Brett Tate
response obviously cannot be returned.
"The URI in the To field of the request MUST be set to the remote

URI

Post by Brett Tate
from the dialog state. The tag in the To header field of the

request

Post by Brett Tate
MUST be set to the remote tag of the dialog ID. The From URI of

the

Post by Brett Tate
request MUST be set to the local URI from the dialog state. The

tag

Post by Brett Tate
in the From header field of the request MUST be set to the local

tag

Post by Brett Tate
of the dialog ID."
--
This email is intended solely for the person or entity to which it

Post by Brett Tate
addressed and may contain confidential and/or privileged

information. If

Post by Brett Tate
you are not the intended recipient and have received this email in

error,

Post by Brett Tate
please notify BroadSoft, Inc. immediately by replying to this

message, and

Post by Brett Tate
destroy all copies of this message, along with any attachment, prior