Subject: RE: [Sipping] Update to 3pcc

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Jul 2003 23:32:11 -0400

I agree that this is something that should be fixed with explicit semantics
in future versions of SDP. But I hope that the .invalid approach won't give
rise to serious interoperability concerns. Can any implementers speak to
what would happen if a domain name given in the c= line of SDP could not be
resolved? I imagine that it's unlikely to lead to any media being sent, but
is there a further concern that the SIP session would be terminated
unceremoniously, or something like that?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 9:05 PM
> To: Jonathan Rosenberg; sipping
> Subject: Re: [Sipping] Update to 3pcc
> 
> 
> This is a huge interop issue. Is .invalid to be the
> recommendation going forward or is this a stopgap
> measure? Hopefully SDPng addresses this more directly.
> 
> --- Jonathan Rosenberg <[email-masked]>
> wrote:
> > Folks,
> > 
> > You may have noticed that I posted an update to the
> > 3pcc spec:
> > 
> >
> http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt
> >
> http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt
> > 
> > The update is based on comments received from IESG
> > while reviewing the 
> > draft. In particular, there were problems with the
> > usage of 0.0.0.0 to 
> >   imply that no media nor RTCP should be sent. This
> > IP address is not 
> > meant for that purpose. Rather, the .invalid TLD is
> > much better 
> > suited. So, I changed the draft to make use of
> > .invalid in flows where 
> > the controller doesnt want media to be sent.
> > 
> > Now, there are some concerns with that which folks
> > need to be aware of:
> > 
> > 1. It is at odds with RFC 3264, which actually
> > recommends 0.0.0.0. In 
> > fact, the problem is really with RFC 3264, NOT 3pcc.
> > However, 3264 is 
> > done, and this one isnt. I logged a bug against RFC
> > 3264 on this, and 
> > we'll need to work on a way to transition folks
> > towards using .invalid 
> > and not 0.0.0.0.
> > 
> > 2. One the premises of 3pcc is that it should be
> > compatible with any 
> > UA that is RFC 3261 compliant. If a controller uses
> > .invalid in the 
> > SDP, I am not sure what a SIP endpoint would do. I
> > don't believe 
> > anything in RFC 3264 or in SIP talks about handling
> > the case where 
> > there is an issue with a domain name in the SDP. As
> > such, if you use 
> > .invalid, there could be interop problems. The
> > document mentions this.
> > 
> > Comments or questions welcome.
> > 
> > Thanks,
> > Jonathan R.
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

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

---

From: "Sean Olson" <[email-masked]>
Date: Tue, 8 Jul 2003 21:57:54 -0700

It is likely that the session would be terminated. Badness.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2003 8:32 PM
To: 'Sean Olson'; Jonathan Rosenberg; sipping
Subject: RE: [Sipping] Update to 3pcc

Jon Peterson
NeuStar, Inc.

> This is a huge interop issue. Is .invalid to be the recommendation 
> going forward or is this a stopgap measure? Hopefully SDPng addresses 
> this more directly.
> 
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> 
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2003 05:30:36 -0400

Yes, definitely badness. We already have had a lot of interop issues 
with 3pcc, because lots of folks don't support things like INVITEs w/o 
SDP, even though its mandatory in 3261. This would add another problem 
to the mix.

One could argue that, as a BCP, it is not the place of the 
specification to mandate UA behavior that differs from existing, 
standards track behavior (RFC 3264). The whole premise of 3pcc is that 
it should work with any rfc3261 compliant UA. Now, we are saying that 
  a UA would need to explicitly support this new "3pcc feature" to work.

How about this alternate approach:

1. 3pcc goes back to using 0.0.0.0
2. We write a separate I-D, which updates rfc3264, saying to use 
.invalid. We also add an option tag for it, so we can figure out if 
its understood. That would go through as a standards track document in 
sip, presumably. It would be short, just a few pages.

With (2) in place, 3pcc could make use of .invalid, and couple it with 
Require as necessary to make sure backwards compatibility is addressed.

I don't know whether this approach would be acceptable to IESG. Jon or 
Allison, comments?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Marian Durkovic <[email-masked]>
Date: Wed, 9 Jul 2003 12:19:29 +0200

> SDP, even though its mandatory in 3261. This would add another problem 

In my opinion, the definition for non-existing address should be available 
also for numeric representation, which is prefferably used in SDP.

I don't see any problem with 0.0.0.0, since RFC1700 says this is only valid
as _source_ address, while the c= line denotes where to send media - i.e.
the _destination_ address. Thus seeing 0.0.0.0 as destination address can
be safely considered invalid.

	With kind regards,

		M.

> >>>Comments or questions welcome.

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail: [email-masked]        ----
----                                                                  ----
--------------------------------------------------------------------------

---

From: Sean Olson <[email-masked]>
Date: Wed, 9 Jul 2003 10:32:14 -0700 (PDT)

This sounds like a very sensible approach to me, but 
of course the decision lies with Jon/Allison.

wrote:
> >>Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: Allison Mankin <[email-masked]>
Date: Wed, 09 Jul 2003 11:47:49 -0700

The mistake was in only recommending not to send 0.0.0.0 in RFC 3264,
but not developing the .invalid tld alternative at the time.  Ah, well.  Crashing
sessions is not an option.  Jonathan's proposal sounds like the way to go,
but it should caveat 0.0.0.0 with a brief description of drawbacks of it (such
as RFC 3264 has), and the fact that future work will allow upgrade to an alternative.

Allison

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jul 2003 11:52:39 -0400

I'm way behind in my mail and just discovered this discussion. Earlier I 
had actually discovered the new draft and posted a question on this very 
point without first finding this conversation. I apologize for that.

Could this problem not be dealt with in a backward compatible manner by 
using a domain name that actually exists in the public DNS and resolves 
to the address 0.0.0.0?

I don't see how Jonathan's alternative helps in practice. The .invalid 
address often is needed in an initial offer, so there has as yet been no 
opportunity to exchange option tags. So in this case it would require 
starting with a Require of the option, which will result in the request 
failing, and the need to retry with 0.0.0.0 in that case. So everybody 
needs to support both ways, and for awhile we get lots of extra 
messaging incurred when somebody tries to do the right thing. Anybody in 
their right mind is just going to start out using 0.0.0.0, because it is 
more likely to work on the first try.

	Paul

Jonathan Rosenberg wrote:
> One could argue that, as a BCP, it is not the place of the specification 
> to mandate UA behavior that differs from existing, standards track 
> behavior (RFC 3264). The whole premise of 3pcc is that it should work 
> with any rfc3261 compliant UA. Now, we are saying that  a UA would need 
> to explicitly support this new "3pcc feature" to work.
> 
> .invalid. We also add an option tag for it, so we can figure out if its 
> understood. That would go through as a standards track document in sip, 
> presumably. It would be short, just a few pages.
> 
>> From: Peterson, Jon [mailto:[email-masked]] Sent: Tuesday, 
>> July 08, 2003 8:32 PM
>>>> usage of 0.0.0.0 to  imply that no media nor RTCP should be sent. This
>>>> IP address is not meant for that purpose. Rather, the .invalid TLD is
>>>> much better suited. So, I changed the draft to make use of
>>>> .invalid in flows where the controller doesnt want media to be sent.
>>>>
>>>> However, 3264 is done, and this one isnt. I logged a bug against RFC
>>>> 3264 on this, and we'll need to work on a way to transition folks
>>>> towards using .invalid and not 0.0.0.0.
>>>>
>>>> .invalid in the SDP, I am not sure what a SIP endpoint would do. I
>>>> don't believe anything in RFC 3264 or in SIP talks about handling
>>>> the case where there is an issue with a domain name in the SDP. As
>>>> such, if you use .invalid, there could be interop problems. The
>>>> document mentions this.
>>>>