Subject: [Sipping] RE: RTCP Summary Draft -- M= line issue

From: "Johnston, Alan" <[email-masked]>
Date: Tue, 01 Mar 2005 19:34:05 +0000

I think this is reasonable, but I think it goes beyond this draft.

I have been troubleshooting ICE implementations lately, and it is
incredibly difficult to figure out what happened on a give call and why
it might have failed.

I'd suggest that the result of the ICE tests is part of the session
state and should be reflected somehow in SIP.  For example, perhaps a
re-INVITE after ICE completes to indicate which IP address and port the
media was actually sent to would be incredibly useful.  Other mechanisms
could be fine - we just need to standardize it so everyone does it.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, March 01, 2005 1:29 PM
> To: 'sipping' WG
> Cc: Johnston, Alan; Amy Pendleton; Marc Petit-Huguenin
> Subject: RTCP Summary Draft -- M= line issue
> 
> 
> Marc previously noted:
> 
> -----
> With this version, the c=, m= and a= lines of the SDP are 
> copied in the 
> report event. But as the m= line can list more than one codec, how do 
> we know which one was used?
> 
> Also when used on an endpoint that supports ICE, the IP 
> address in the 
> m= line and the port in the m= line are not used. Does it means that 
> the a=candidate line should also be added in the event 
> report? If it is 
> the case then we have the same problem than above, we do not 
> know which 
> IP address/port was used.
> 
> One solution to this problem could be to insert in the event report a 
> stripped version of the m=, c= and a= lines that contain only 
> what was 
> used for the duration of the event . . .
> ------
> 
> This sounds reasonable to me -- "Report what you actually 
> did, not what 
> you talked about maybe doing."
> 
> Group? Any objections? If not, the authors should note this for 
> inclusion in the post-WGLC doc that will be submitted to IETF.
> 
> --
> Dean
> 
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Mar 2005 11:49:29 -0500

> could be fine - we just need to standardize it so everyone does it.

Doing that comes with fairly high cost. It means that every o/a exchange 
basically requires two INVITEs transactions - one to set it up, and the 
other to report what happened. This cost seems high for signaling 
something that both endpoints already know.

The diagnostic issue with ICE IMHO is just a piece of a much broader 
problem, which is that lots of "what happened" is known only to the 
endpoints anyway. These include:

* RTP statistics (the original purpose of the draft under discussion)
* results of any DNS lookups on hostnames appearing in SDP
* selectoin of codecs when an m-line lists multiple ones
* TCP connection setup attempts and failures for TCP-oriented media
* selection of v4 vs. v6 addresses when ANAT is in use
* results of STUn nat determination algorithms, if used

and the list goes on and on.

I would suggest that, rather than saying we should pile ALL of this 
stuff into a re-INVITE just so that something that happens to be 
sniffing the INVITE can learn about it, we provide proper reporting 
mechanisms that endpoints can implement.

Whether that falls within the scope of the RTCP summary draft is 
certainly debatable, but I would much prefer that kind of approach.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com