One issue which I recall being briefly discussed was SIP recovery strategies when the resolution of an FQDN connection address fails. This may be a more common occurance in 3pcc where the signalling and media paths are separate.
There is no standard way for one UA to tell another that it's connection address could not be resolved but that otherwise the media characteristics are ok. Although an additional warning code could indicate this if the connection address in an offer could not be resolved, if that in the answer can't be resolved, I'm not sure what the solution would be. A re-INVITE, although it could remove the media stream which had the failed connection address, would offer the same media and probably result in an answer containing the FQDN which could not be resolved. timm Jonathan Rosenberg wrote: > Colin, > > I could have sworn we once had a conversation about why using domain > names in SDP was a bad idea, and that this was the motivation for its > removal from sdp-new, although I don't remember the reason. Am I > mis-remembering (a definite possibility), or is there some issue with > domain names? > > -Jonathan R. > > Colin Perkins wrote: > >> --> Paul Kyzivat writes: >> >>> It was FQDN in RFC2327. Then, it became just IP4-address or IP6-address >>> in draft-ietf-mmusic-sdp-new-02 and -03, but went back to FQDN in >>> draft-ietf-mmusic-sdp-new-04. >>> I don't know which is preferred for use with SIP. But it would be nice >>> if somebody would make up their mind. >>> >> >> draft-ietf-mmusic-sdp-new is intended to match RFC2327. If it doesn't, >> let >> me know and I'll fix it. >> >> Colin >> >> > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
