Hi,
The SDP RFC allows a FQDN, but the sdp-new draft (draft-ietf-mmusic-sdp-new-03.txt) only allows an IP address. I don't think that SIP defines any rule for this separately. Regards, Christer Holmberg Ericsson Finland Bob Penfield wrote: > > Hi Tim, > > Although the SDP RFC allows a FQDN in the c-line, for SIP I believe that > only IP addresses should be used. I'm not sure if that is called out in bis > or some other draft. > > If some of the media streams are acceptable, you could just disable the > unacceptable ones by setting the port number to 0 in accordance with > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-sdp-offer-answer- > 00.txt > Otherwise you should reject the request with a 488 (Unacceptable Here) > response. > > If there are no acceptable streams, a 488 should be returned. > > If the offer is in a 200-OK, you need to send the ACK. But then you would > need to re-INVITE or send a BYE immediately. If you're going to send BYE, > you probably want to set all the port numbers to 0 in the answer SDP in the > ACK so that the far end does not start sending media. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > [EMAIL PROTECTED] > > ----- Original Message ----- > From: "Tim Johnson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 08, 2001 9:45 PM > Subject: [Sip-implementors] SDP with unresolved connection address > > > I have a question about what, if any, SIP behaviour there should be > > if a UA receives SDP with a connection address expressed as a > > domain name and which cannot be resolved. In this case at least one, > > and possibly all, media streams cannot be sent. This is also similar > > to an ARP failure on a LAN but probably much more likely to occur. > > There is also a similarity to receiving an ICMP unreachable > > indication for a media stream in progress. In all cases the media > > cannot be sent yet the signalling channel, especially in the case of > > 3PCC, may be unaffected. > > > > If the SDP was in an INVITE, the response could indicate a DNS > > resolution failure (although no response codes are defined which > > cover this specific case). But the SDP could also be in either a 2xx > > response or in an ACK. In these cases, a re-INVITE could be sent > > following the completion of the INVITE transaction which > > contained the unresolved name. Alternatively, a BYE could be sent > > to terminate the session. Finally, the session could be unaffected and > > corrective actions left to the user which notices a lack of media. > > > > Only the BYE seems deterministic since a response to a re-INVITE > > is likely to contain the same SDP as caused the resolution failure. > > However it would appear to be too drastic if there were other media > > streams in the session which did resolve (i.e. the c= which did not > > resolve was within one of several media descriptions and not at the > > session level). What is the accepted solution here? > > > > Thanks, > > Tim > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
