Subject: RE: [Simple] New I-D on IM transport

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2001 11:22:52 -0500

Its worth noting that this is an issue for RTP as well; if you are using
some kind of RTP intermediary (perhaps even a TURN server...) you might want
a domain name instead of an IP address for robustness.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 11:20 AM
> To: Paul Kyzivat
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> We ran into similar issues when we were trying to define how 
> to use SDP 
> to describe SIP based message sessions. I suspect that will be the 
> harded part in finishing IMTP, and perhaps the part most in 
> need of our 
> attention.
> 
> Paul Kyzivat wrote:
> 
> > Jonathan - I agreed with most of what you said in this 
> reply, but there
> > was one point I take issue with:
> > 
> > Jonathan Rosenberg wrote:
> > 
> > [snip]
> > 
> > 
> >>When an IMTP relay rewrites the SDP, the c line contains a 
> domain name.
> >>
> > 
> > The latest versions of SDP don't permit FQDNs in the c= line.
> > I never did hear why this change was made. While it often 
> may be wise to
> > avoid FQDNs in sdp, it seems pretty heavy handed to forbid 
> them, since
> > as you point out here there may be cases where they are useful.
> > 
> > 	Paul
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2001 19:32:10 -0500

I think the question is one of how to recover from problems with media
transport. Having an FQDN gives an opportunity to try some recovery
strategy that doesn't involve sip signalling. I think it is possible to
argue both sides convincingly as to whether this is a good thing.

The alternative is that when something goes wrong with the media
transport then perhaps you should use more sip signalling to recover -
by doing a reinvite. This gives the opportunity to exchange new
addresses in order to continue the session. But it also has the problem
of getting the two endpoints to mutually understand what is going on and
what recovery action to take. But I think there is a better chance of
doing this with signalling than without. This may need something like a
reason code (e.g. Reason: header) explaining why a reinvite is being
done, and probably some SDP content that indicates what media session
needs attention. (Just because you have an FQDN doesn't mean you can
start using a different resolution of it at any old time. Once traffic
has begun to flow the endpoint may no longer be prepared to receive on
alternative addresses. This is especially a problem with comedia, where
there has to be connection establishment before traffic can flow.)

I posted about this some time ago, as an offshoot of the comedia
discussions, but that faded away without any resolution. Perhaps it is
time to resurrect it.

	Paul