Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 4 Apr 2006 15:11:21 +0200

Hi Bob,

The UAS would have to check EVERY Via branch, because the issue I raised
was related to intermediate RFC2543 compliant stateful proxies. 

Regards,

Christer 

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]] 
Sent: 4. huhtikuuta 2006 15:48
To: Christer Holmberg (JO/LMF); Elwell, John; [email-masked]
Subject: Re: [Sip] Connected-identity and changing the To header field
inaresponse

I have not been following this thread that closely. However, if we were
to allow the To to be changed in a response, we could still have
backward compatibility by requiring the UAS check the bottom Via for the
branch-id cookie to determine whether the UAC will use 3261 or 2543
transaction matching rules.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message -----
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Elwell, John" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 04, 2006 8:13 AM
Subject: RE: [Sip] Connected-identity and changing the To header field
inaresponse

Hi Bob,

I was told (see a few mails back) that it had been decided that backward
compability with RFC 2543 does not need to be taken into account.

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 4. huhtikuuta 2006 14:58
To: Elwell, John; [email-masked]
Subject: Re: [Sip] Connected-identity and changing the To header field
inaresponse

The issue with changing the To in a response is backward compatibility
with RFC 2543 which does use the To for transaction matching. RFC 2543
section
1.4.3 says:

   All responses to a request contain the same values in
   the Call-ID, CSeq, To, and From fields (with the possible
   addition of a tag in the To field (section 6.37)).
   This allows responses to be matched with requests.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message -----
From: "Elwell, John" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 04, 2006 2:45 AM
Subject: [Sip] Connected-identity and changing the To header field in
aresponse

> During discussion of draft-elwell-connected-identity in Dallas, 
> somebody put forward the opinion that it would be dangerous to change 
> the To header field URI in a response (i.e., make it different from 
> the From header field URI in the request). My assumption at the time 
> was that it would undermine the transaction concept in SIP, yet 
> reading what RFC3261 has to say about transactions, the value of the 
> To header field URI in a response does not appear to be involved in 
> coupling a response to a request. Therefore I assume the person who 
> indicated the danger (which was not challenged at the
> meeting) has other reasons in mind. I would greatly appreciate 
> opinions on the wisdom or otherwise of allowing the To header field 
> URI to change. It seems that from discussion of connected-identity 
> there is a desire from some parts of the community to include an
> (unauthenticated) identity in a response.
>
> John
>
>

------------------------------------------------------------------------
--------

> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 4 Apr 2006 09:48:06 -0400

Yes, you are correct. It would have to check them all.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Elwell, John" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 04, 2006 9:11 AM
Subject: RE: [Sip] Connected-identity and changing the To header 
fieldinaresponse

Hi Bob,

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 4. huhtikuuta 2006 15:48
To: Christer Holmberg (JO/LMF); Elwell, John; [email-masked]
Subject: Re: [Sip] Connected-identity and changing the To header field
inaresponse

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message -----
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Elwell, John"

Hi Bob,

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 4. huhtikuuta 2006 14:58
To: Elwell, John; [email-masked]
Subject: Re: [Sip] Connected-identity and changing the To header field
inaresponse

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message -----
From: "Elwell, John" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 04, 2006 2:45 AM
Subject: [Sip] Connected-identity and changing the To header field in
aresponse

---

From: "Gary Gan" <[email-masked]>
Date: Tue, 4 Apr 2006 10:07:40 -0400

The SIP conference info package could be very large depending on the size of
the conference. How does it handle the MTU issue?

Gary Gan
Clique Communications, LLC

---

From: "Sean Olson" <[email-masked]>
Date: Tue, 4 Apr 2006 07:14:19 -0700

Partial notifications and/or compression

-----Original Message-----
From: Gary Gan [mailto:[email-masked]]
Sent: Tue 4/4/2006 7:07 AM
To: [email-masked]
Subject: [Sip] draft-ietf-sipping-conference-package : MTU

Gary Gan

---

From: "Gary Gan" <[email-masked]>
Date: Tue, 4 Apr 2006 10:29:23 -0400

According to the draft, the initial SUBSCRIBE always generates a full state
package. Then it receives changes in the partial notifications. Even partial
notifications, we can not guarantee the size will not exceed the MTU. Is
there a mechanism defined in the SUBSCRIBE/NOTIFY, which I don't see it in
the RFC3265, or in this draft to handle MTU?

Gary Gan

-----Original Message-----
From: Gary Gan [mailto:[email-masked]]
Sent: Tue 4/4/2006 7:07 AM
To: [email-masked]
Subject: [Sip] draft-ietf-sipping-conference-package : MTU

Gary Gan

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 04 Apr 2006 11:38:22 -0400

> the conference. How does it handle the MTU issue?

Such a NOTIFY would be sent using TCP.

RFC 3261 section 18:

All SIP elements MUST implement UDP and TCP.  

Section 18.1.1:

If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such as
TCP.

Dale

---

From: "Gary Gan" <[email-masked]>
Date: Tue, 4 Apr 2006 13:49:58 -0400

Does it mean the SIP UA is supposed to check the SIP message size, if it is
too big, it will automatically switch to TCP? Is it a mixed TCP/UDP SIP
messages within a SIP session or it needs to decide UDP or TCP at the
beginning of a session?

How TCP is used in SIP? Is it a connection/disconnect per message like a WEB
request, or connection on each session, or even a connection pool based on
the destinations? I think only the WEB request style makes sense for
SIP/TCP. SIP doesn't define differently for TCP in terms of connect and
disconnect.

Gary Gan

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 11:38 AM
To: Sip
Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU

RFC 3261 section 18:

Section 18.1.1:

Dale

---

From: "Gary Gan" <[email-masked]>
Date: Tue, 4 Apr 2006 15:57:24 -0400

I did a network trace for protocol analysis. For the SIP client I tested,
the TCP connection is created when it first registers, shutdown when it
un-registers.  In between, it uses the same connection for SIP requests and
responses. When a UA registers, it specifies the TCP/UDP or both. But for
large SIP messages like the conference info package, MTU will be an issue.
The sender can not guarantee the path not to exceed the MTU size, and the
sender will not know if all the nodes in the path support TCP. As far as I
know, a lot of SIP clients either support UDP or TCP, but not both at the
same time. A lot of SIP products work better on UDP protocol and shaky on
TCP protocol, both servers and clients.

Gary Gan

===================================================================

Gary Gan

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 11:38 AM
To: Sip
Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU

RFC 3261 section 18:

Section 18.1.1:

Dale

---

From: "Tarun Kapoor" <[email-masked]>
Date: Tue, 4 Apr 2006 16:24:53 -0400

I believe that whether to use a "persistent" TCP connection or a
connect/disconnect TCP model as a HTTP request is not specified anywhere.
It really depends on many factors such as what service is being offered,
what is the architecture, are there any NATs/firewalls to traverse, general
network infrastructure, etc.  In the end it is up to the particular vendor
to decide on what "type" of TCP connection they need.

However, the UA should decide whether it will support TCP or UDP at the
beginning of a session and stick to it until it initiates another session.
It's generally safer to use TCP if you know there is a chance of a SIP
packet > MTU.

-----Original Message-----
From: Gary Gan [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 1:50 PM
To: 'Dale R. Worley'
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU

Gary Gan

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Tuesday, April 04, 2006 11:38 AM
To: Sip
Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU

On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote:
> The SIP conference info package could be very large depending on the 
> size
of

RFC 3261 section 18:

Section 18.1.1:

If a request is within 200 bytes of the path MTU, or if it is larger than
1300 bytes and the path MTU is unknown, the request MUST be sent using an
RFC 2914 [43] congestion controlled transport protocol, such as TCP.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Apr 2006 15:42:13 -0500

Tarun Kapoor wrote:
> connect/disconnect TCP model as a HTTP request is not specified
> anywhere. It really depends on many factors such as what service is
> being offered, what is the architecture, are there any NATs/firewalls
> to traverse, general network infrastructure, etc.  In the end it is
> up to the particular vendor to decide on what "type" of TCP
> connection they need.

It is true that there isn't *one* authoritative document that you
can use to decipher persistent TCP connections.  A few of us did
work on this a while ago, which has since languished (see
http://bgp.potaroo.net/ietf/all-ids/draft-gurbani-sipping-connection-guidelines-01.txt)

Currently, the behavior of persistent TCP connections is straddled
among rfc3261, sip-connect-reuse and sip-outbound drafts.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 5 Apr 2006 15:31:13 -0500

> It's generally safer to use TCP if you know there is a chance of a SIP

I'd like to restate this:

"It's generally safer to use TCP if you know there is a chance of a  
SIP packet."

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Wed, 5 Apr 2006 17:27:05 -0400

My concern is that one side, which knows its packet will exceed MTU, can
stick on TCP, how can it know the other peer also support TCP? Does it mean
all SIP UA must support TCP and must register it to the registrar as a TCP
endpoint in order to receive such SIP sessions?

Gary Gan

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 4:31 PM
To: Tarun Kapoor
Cc: 'Gary Gan'; 'Dale R. Worley'; [email-masked]
Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 05 Apr 2006 18:18:21 -0400

> endpoint in order to receive such SIP sessions?

To repeat: RFC 3261 section 18: "All SIP elements MUST implement UDP and
TCP."

The TCP port does not need to be separately registered.  A URI like
"foo@host" implies that the agent is listening on UDP port 5060 and also
TCP port 5060.  If a port number is added, it is listening on that port
for both UDP and TCP.

Dale

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 05 Apr 2006 18:36:21 -0400

> messages within a SIP session or it needs to decide UDP or TCP at the

As a general rule, how a SIP agent processes a message does not depend
on the transport used to get the message there.  So it is possible for
some messages in a dialog to be transported via TCP and some via UDP.
In addition, different messages in a dialog may (within certain limits)
traverse a different set of proxies.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 5 Apr 2006 17:53:19 -0500

> endpoint in order to receive such SIP sessions?

Pretty much, yes. But we really haven't been willing to say that very  
loudly so far.

RFC 3261  Section 18 P4 says:

    All SIP elements MUST implement UDP and TCP.  SIP elements MAY
    implement other protocols.

So, ALL SIP UA MUST SUPPORT TCP. That's been said fairly loudly.

We've also said, in section 18.1.1 of RFC 3261:

    If a request is within 200 bytes of the path MTU, or if it is larger
    than 1300 bytes and the path MTU is unknown, the request MUST be  
sent
    using an RFC 2914 [43] congestion controlled transport protocol,  
such
    as TCP.

So, a large request MUST NOT BE SENT over UDP.

What we haven't said is that "if a UA does not register a TCP (or  
other congestion controlled transport) as a contact, that UA will not  
receive large requests."

But I think this fairly clearly follows from the above-quoted  
statements in RFC 3261.

I think that this means that TCP (better yet, TLS) should be the  
default transport, and UDP should be used only in very special cases  
that have an explicit awareness of the fact that they aren't going to  
get large messages.

In practice, nobody seems to care, and everybody pumps out large UDP  
messages in fragmented form and just hopes they get there in the  
right order, which usually works.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 5 Apr 2006 19:10:25 -0500

On Apr 5, 2006, at 5:53 PM, Dean Willis wrote:

> Pretty much, yes. But we really haven't been willing to say that  
> very loudly so far.
>
> other congestion controlled transport) as a contact, that UA will  
> not receive large requests."
>

Let me restate this is: "If a UA does not use TCP (or another  
congestion controlled transport negotiated with its proxy), that UA  
will not receive large requests.

--
Dean

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 5 Apr 2006 18:19:06 -0700

One major issue is that 3261 doesn't consider NAT traversal.  For example,
if Alice is behind a NAT and sends a SUBSCRIBE with a UDP contact, Alice
cannot receive large messages even if she supports TCP on the same port,
even if she Registered a separate TCP contact.  Bob can have TCP as the
contact in the NOTIFY, and alice & bob can send TCP or UDP to their
respective proxies, but this doesn't help.

I believe that a Dialog-ICE like mechanism was proposed once for this, which
could work w/ sip-outbound, but it makes more sense to just stop using UDP
if you have to register both anyhow.

> Sent: Wednesday, April 05, 2006 5:10 PM
> To: Dean Willis
> Cc: [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Apr 2006 21:14:51 -0500

Derek MacDonald wrote:

>even if she Registered a separate TCP contact.
>

I think Dean's point was: "don't do that, then."

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Apr 2006 21:20:30 -0500

> I think Dean's point was: "don't do that, then." 

Sorry; I just read more context, and realize that Dean's point was that 
we don't say "don't do that, then" anywhere. *I* think the proper answer 
is saying "don't do that, then" in a document somewhere.

/a

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 5 Apr 2006 19:57:39 -0700

Yeah. It should prob. be added to the NAT best practices draft(Full
disclosure, haven't read it yet).  However, everything boils down to "don't
use UDP".  I'm was just re-enforcing the message.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 7:21 PM
> To: Adam Roach
> Cc: Derek MacDonald; [email-masked]; 'Dean Willis'

---

From: "Gary Gan" <[email-masked]>
Date: Thu, 6 Apr 2006 11:00:57 -0400

> right order, which usually works.

The SIP doesn't define ways to reassemble the fragmented UDP messages. There
is no size information in the SIP header to help reassemble. The receiver
side usually just declares them as malformed messages and drops them on the
floor. 

If we have to implement TCP, not only implement it but must load it at
runtime, why do we need UDP at all? One may say that UDP has advantage for
firewall traversal, they can utilize the STUN, ICE. One can also argue that
UDP is more efficient since SIP handles the handshakes without the TCP's
overhead. But if we MUST load TCP, where are the advantages? How do we deal
with the drafts/FRCs made around UDP protocols only?

Gary Gan

---

From: Adam Roach <[email-masked]>
Date: Thu, 06 Apr 2006 11:18:46 -0500

Gary Gan wrote:

>The SIP doesn't define ways to reassemble the fragmented UDP messages.
>

You're right. That procedure is described in RFC 815. Read pages 8 and 9 
of RFC 791 for context.

/a

---

From: Dean Willis <[email-masked]>
Date: Thu, 6 Apr 2006 13:56:07 -0500

> with the drafts/FRCs made around UDP protocols only?

Just say "no"?

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Thu, 6 Apr 2006 15:11:03 -0400

I doubt the procedure is included in most TCP/IP stack.

Gary Gan

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 12:19 PM
To: Gary Gan
Cc: 'Dean Willis'; [email-masked]
Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 6 Apr 2006 14:28:52 -0500

>I doubt the procedure is included in most TCP/IP stack.

I may be confused... are you saying that most TCP/IP stacks don't perform 
IP-level fragmentation and reassembly?

Spencer

---

From: Dean Willis <[email-masked]>
Date: Thu, 6 Apr 2006 17:42:13 -0500

>> with the drafts/FRCs made around UDP protocols only?

Some people thought I might be being flippant.

I meant "just don't use UDP".

Stuff that was built "around UDP only" is not compliant with the core  
SIP specs and we have no commitment to reverse compatibility for  
things that badly out of compliance.

--
Dean